Timeline for Can we make general statements about the performance of interpreted code vs compiled code?
Current License: CC BY-SA 3.0
49 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 24, 2017 at 20:46 | review | Close votes | |||
| Mar 1, 2017 at 3:04 | |||||
| Jan 15, 2017 at 6:58 | history | tweeted | twitter.com/StackSoftEng/status/820525587433455616 | ||
| Jan 14, 2017 at 8:26 | answer | added | SystematicFrank | timeline score: 0 | |
| Jan 13, 2017 at 12:52 | comment | added | maple_shaft♦ | Please avoid extended discussions in comments. If you would like to discuss the question further then please visit our chat room. Thank you. | |
| Jan 13, 2017 at 8:57 | comment | added | Justin Time - Reinstate Monica | Hmm... I can think of at least one generalisation that can be made, but it's not actually helpful. Specifically, that it's easier for interpreted code to run slowly than it is for compiled code to run slowly, simply because the interpreter's overhead could divert resources from the interpreted code. This says nothing of actual value, as a good interpreter can easily outperform a bad compiler. It all comes down to the quality of the interpreter vs. the quality of the compiler, the only thing that's different is that the deck is stacked in one's favour more than the other's. | |
| Jan 13, 2017 at 8:53 | answer | added | rghome | timeline score: 5 | |
| S Jan 12, 2017 at 15:25 | history | suggested | Paul D. Waite | CC BY-SA 3.0 | Fixed grammar typo. |
| Jan 12, 2017 at 14:12 | review | Suggested edits | |||
| S Jan 12, 2017 at 15:25 | |||||
| Jan 12, 2017 at 14:01 | answer | added | RedSonja | timeline score: 0 | |
| Jan 12, 2017 at 11:03 | answer | added | NoDataDumpNoContribution | timeline score: -3 | |
| Jan 11, 2017 at 21:21 | comment | added | Robert Harvey | softwareengineering.stackexchange.com/q/340008 | |
| Jan 11, 2017 at 12:48 | history | protected | gnat | ||
| Jan 11, 2017 at 12:16 | answer | added | Radu Murzea | timeline score: 12 | |
| Jan 11, 2017 at 10:11 | answer | added | KjMag | timeline score: 1 | |
| Jan 11, 2017 at 9:52 | comment | added | Doc Brown | @EpicSam: that sounds good. And don't get me wrong, when picking a new technology, it can be important to invest some thoughts into performance. I just would ask such a question in a form like "do we know that none of those two technologies performs so badly that it can be ruled out immediately" or "will both be fast enough for our purposes". And if the answer is "yes", discussing a question like "which one is faster" is often obsolete. | |
| Jan 11, 2017 at 9:21 | comment | added | EpicSam | @Doc Performance was not the primary reason I argued for either technology in my report. The main reason why I re commanded the one I did was based on testability and maintainability. The performance part of the report was however the part that was rejected by the reviewer. And after reading all the comments and answers here I believe the reviewer was correct to do so. | |
| Jan 11, 2017 at 9:14 | comment | added | Luaan | @paxdiablo You could argue that the CPU interprets the compiled code... but that's probably pushing it :P On the other hand, the newest Intels are so good at branch prediction that the overhead from the extra indirection in interpreted code is almost non-existent (for different scenarios, they measured a speed-up of between 5 and 20 times). And code that isn't compiled for a specific computer can be much slower anyway - most C++ 32-bit compilers still target 80s era CPUs for compatibility by default. And then you have dynamic code, which can be much cheaper interpreted... and... | |
| Jan 11, 2017 at 8:38 | comment | added | Doc Brown | ... I guess this is often just a manifestation of the Dunning-Kruger effect. Performance is used as a wrong measure by software engineers because it is a technical aspect of a technology which seems to be measurable, and they had learned a lot about in during their CS course etc. Thus soft factors like the organizational aspects of a technology are overlooked, despite the fact they are often much more important . | |
| Jan 11, 2017 at 8:31 | answer | added | Basile Starynkevitch | timeline score: 10 | |
| Jan 11, 2017 at 8:21 | comment | added | Doc Brown | @hobbs: sure, but I don't see any indication in the question that the comparison and the fact the OP wants to use performance as a primary factor is caused by such a reason. However, I have too often seen people trying to use performance for such comparisons because of some superstitious, wrong believe it might become relevant for them in the future. That gives me a big warning sign whenever a person tries to make a technological "A or B" decision that way. | |
| Jan 11, 2017 at 8:19 | comment | added | user10776 | I'd hazard to suggest that the only blanket statement you can reliably make about compiled and interpreted code is that the former is compiled and the latter is interpreted. But, to be honest, I'm not even 100% certain on that :-) | |
| Jan 11, 2017 at 8:09 | answer | added | Maja Piechotka | timeline score: 5 | |
| Jan 11, 2017 at 7:58 | comment | added | hobbs | @DocBrown for some throughput-oriented things, "performance" is the inverse of "cost". Make something use X% less CPU; handle the same traffic with X% fewer VM instances; get billed X% less :) | |
| Jan 10, 2017 at 22:53 | comment | added | Ixrec | afaik, the most general statement you can get away with is that compiled languages tend to provide more consistent memory usage/execution times/etc and offer more control over the memory usage/execution time/etc when you need it. Interpreted languages these days often can compete with the "raw performance" of compiled languages, but it's the consistency of and control over that performance that makes certain compiled languages so dominant in embedded systems, scientific computing, 3D game engines and so on. | |
| Jan 10, 2017 at 22:33 | comment | added | Doc Brown | Honestly, why the heck do you want to give a company-relevant recommendation for one of two technologies based first and foremost on performance? In special cases (like 3D high speed games programming), performance can be a relevant criterion, but for most real-world business programs, it should be the last thing you compare, not the first. | |
| Jan 10, 2017 at 19:44 | answer | added | loneboat | timeline score: 80 | |
| Jan 10, 2017 at 19:42 | comment | added | loneboat | You seem to be contradicting yourself. On the one hand, you want to make a general statement about interpreted vs compiled languages. But on the other hand, you want to apply that general statement to a concrete scenario. But once you apply it to a concrete scenario, it's not generalized anymore. So even if you can make the case that interpreted languages are slower in general, your reviewer doesn't care about that. You're doing an analysis of two very specific technologies. That's literally the opposite of generalizing. | |
| Jan 10, 2017 at 19:03 | comment | added | Ed Plunkett | Randomly pick an interpreted language and a compiled one, and bet a dollar that the compiled one is faster. Repeat enough times and you'll eventually come out far enough ahead to buy lunch at Subway. However, there are faster and more interesting ways for a competent programmer to make that much money. And Subway's not all that great anyhow. | |
| Jan 10, 2017 at 17:22 | history | edited | Robert Harvey | CC BY-SA 3.0 | deleted 350 characters in body |
| S Jan 10, 2017 at 16:04 | history | suggested | Quentin | CC BY-SA 3.0 | Fixed typo in the title |
| Jan 10, 2017 at 15:44 | review | Suggested edits | |||
| S Jan 10, 2017 at 16:04 | |||||
| Jan 10, 2017 at 14:54 | comment | added | JeffO | If they're that worried about it, why not test both languages in a way that is comparable to how they'll be used specifically in this project? | |
| Jan 10, 2017 at 14:45 | vote | accept | EpicSam | ||
| Jan 10, 2017 at 14:35 | history | edited | EpicSam | CC BY-SA 3.0 | added 350 characters in body |
| Jan 10, 2017 at 14:07 | comment | added | Jörg W Mittag | @JacquesB: IronRuby was originally purely compiled. They later added an interpreter for performance. XRuby was a purely compiled implementation of Ruby on the Java platform. Its performance doesn't even come close to JRuby's, which is a mixed-mode implementation. PicoScheme is an AST-interpreted implementation of Scheme that competes very well with bytecode-interpreted, bytecode-JITted, and AOT-compiled implementations. | |
| Jan 10, 2017 at 13:52 | answer | added | amon | timeline score: 37 | |
| Jan 10, 2017 at 13:41 | comment | added | Ivan | @EpicSam -- You wrote "If we can say compiled is generally faster then interpreted". I would be nervous advocating this in a professional setting. Basically, the more people have reused other people's work the more likely it is that the "reusable work" will be better and lead to a faster execution time. For example, Java's earlier (1995ish) JVMs ran far slower than today's JVMs (2017). The impact of this maturity cannot be ignored. Well used interpreted languages will eventually get high speed JIT compilation..once that happens all bets about compiled vs. interpreted are off. | |
| Jan 10, 2017 at 13:38 | answer | added | Mike Dunlavey | timeline score: 7 | |
| Jan 10, 2017 at 13:34 | comment | added | JacquesB | It is compiled/interpreted implementations of the same language or two different languages? For the same language it is reasonable to expect a compiled implementation is faster. For two different languages, you can't say anything. | |
| Jan 10, 2017 at 13:33 | comment | added | Bryan Oakley | The question asks about generalities, but it seems your real problem is with the specifics of Technology A and B. While I think in general interpreted languages may be slower as a whole, that fact likely has absolutely no bearing on your specific technologies. It's quite possible that your specific interpreted B is faster than your compiled A regardless of the general trend. | |
| Jan 10, 2017 at 13:31 | comment | added | 5gon12eder | Since this seems to be a practical problem and not an academic exercise, it might be advisable to not even attempt giving a general answer but actually evaluate technologies A and B. While a general answer probably cannot be given, it is certainly possible to evaluate the performance characteristics of two specific technologies, pointing out their relevance for the kind of applications your organization is interested in. | |
| Jan 10, 2017 at 13:07 | answer | added | Jörg W Mittag | timeline score: 108 | |
| Jan 10, 2017 at 13:04 | answer | added | Walfrat | timeline score: 3 | |
| Jan 10, 2017 at 13:02 | comment | added | EpicSam | @gnat While these links do not directly answer my question, including information from their answers to create a more detailed argument in my report might be just what I need to convince my reviewer. | |
| Jan 10, 2017 at 13:02 | answer | added | jhbh | timeline score: 18 | |
| Jan 10, 2017 at 12:59 | review | Close votes | |||
| Jan 15, 2017 at 3:01 | |||||
| Jan 10, 2017 at 12:44 | comment | added | gnat | see also Understanding the differences: traditional interpreter, JIT compiler, JIT interpreter and AOT compiler | |
| Jan 10, 2017 at 12:43 | comment | added | gnat | Possible duplicate of When an interpreter executes code: Is there a "chain of interpretations" down to the lowest level? | |
| Jan 10, 2017 at 12:34 | history | asked | EpicSam | CC BY-SA 3.0 |