Timeline for Can we make general statements about the performance of interpreted code vs compiled code?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 14, 2017 at 19:29 | comment | added | TomTom | @MartinSchröder You may, but one can argue that JIT is some sort of compiler and thus it is not interpreted anymore. | |
| Jan 13, 2017 at 17:08 | comment | added | JDługosz | @ejp where does he get 2–10× : that’s what textbooks have stated for generations now. It might be out of date now that memory is a bottleneck etc. | |
| Jan 12, 2017 at 13:41 | comment | added | Martin Schröder | And then you have an optimizing JIT like for Java and Lua that produces better performance than your typical C-compiler... | |
| Jan 11, 2017 at 20:55 | comment | added | amon | @EJP Dispatch can be very cheap, though it possibly has adverse effects regarding caching & branch prediction. But the interpreter isn't just doing the same work as a compiled program: different semantics and different memory models drag down performance. When every value is passed by pointer, every number and boolean is boxed, and each function call involves a hash table lookup, then 10x is a fairly optimistic estimate – but one that is supported by the data (e.g. see the benchmark links above). The 2x estimate assumes no semantic differences to the host language. | |
| Jan 11, 2017 at 20:21 | comment | added | user207421 | Where on earth did you get 2-10X from? The ratio depends entirely on how long it takes to fetch and dispatch to the handler for each bytecode as against how long each handler takes to execute, and 10x would only be possible if the fetch cycle took 9x as long as the handler, which is wildly improbably. More usually the execution is dominated by the handler. and the fetch cycle can be vanishingly insignificant. | |
| Jan 10, 2017 at 22:12 | comment | added | David Moles | @amon linking the k-nucleotide example in the answer would make it more readable and the note more useful, as would linking the discussions (without reading the entire site, it's not obvious to me what discussions you're talking about). | |
| Jan 10, 2017 at 21:59 | comment | added | igouy | It would be for the convenience of those who read your answer. (I'm just someone who admins the benchmarks game). | |
| Jan 10, 2017 at 20:40 | comment | added | amon | @igouy Thanks for your suggestions. However, I don't think expanding on a footnote would significantly improve my answer and/or make it easier to read. For your convenience, you can look at the k-nucleotide benchmark which is hash-table heavy. The best scores are the usual suspects C, C++, Java, C#, Go, Rust etc.. But PHP comes in at only 6.9x slower than C, which outperforms some solutions in Go, Rust, OCaml, Java, C#, …. | |
| Jan 10, 2017 at 20:03 | comment | added | igouy | If you think "The most important part of the site isn't the benchmark results, but the discussions on how difficult meaningful benchmarks are" then give URLs to those pages. Show; don't just tell. | |
| Jan 10, 2017 at 20:01 | comment | added | igouy | If you think "the Computer Language Benchmarks Game site has a confusing structure" then give a URL to the specific page that supports your point, rather than expecting people to search from the top-level looking for something they might never find ! Show; don't just tell. | |
| Jan 10, 2017 at 14:15 | history | edited | amon | CC BY-SA 3.0 | the benchmark game might be interesting here |
| Jan 10, 2017 at 13:52 | history | answered | amon | CC BY-SA 3.0 |