3 ms·
From the article, "2. Speed: It should be fast (should approach C in speed). It should preferably have a highly optimized compiler that can generate architectur
by RodgerTheGreat 16y ago
From the article, "2. Speed: It should be fast (should approach C in speed). It should preferably have a highly optimized compiler that can generate architecture specific binaries — no JIT can be faster than an optimized binary."
This is not, strictly speaking, true. In a best-case scenario, a just-in-time compiler has profiling information available that a static compiler won't have. In the right situations, Java JIT can produce performance on par with or slightly exceeding that of equivalent C code for this very reason.
- stcredzero 16y agoThe best I've heard of is approaching 50% native speed on benchmarks, but losing by a factor of 4 in real-world calculation-intensive apps. Langs on a JIT VM have been matching business app (network & DB bound) performance for over a decade already.
- jrockway 16y agoSeems like your information is well out of date, then. Profiling JITs can produce better code than the best optimizing C compilers.
- stcredzero 16y agoIt could be. It's been 7 years since I was in a company that produced a VM.
- jrockway 16y agoI think the technology is probably that old; it seems to take industry 30 years or so before they are willing to look at relevant research ;) Anyway, the LLVM and JVM are good examples of JIT optimization. Tracemonkey also has some good ideas, and GHC and SBCL's VMs also show how to write static compilers that do better than C. (LLVM is interesting in that it compiles C to run on the VM, and this C does better than gcc's statically-compiled C. When C is faster than C, it kind of calls into question the validity of the "faster than C" criterion ;)
- rlpb 16y agoWhy does it need to be fast anyway? How many programs will this one-language-programmer be writing that needs to be fast? Programs are generally constrained by just one thing: either CPU, network bandwidth, network latency, user latency, disk I/O and so forth. Why focus on the CPU? Is this hypothetical programmer really going to be writing another git or a program to fold protein molecules, or is he more likely to be writing glue, user interface or one-shot data manipulation programs? Similarly, multi-threaded programming is hard. If this hypothetical programmer is only learning one language (and thus, by the admission of the article, not very good), why is this suddenly a requirement?