3 ms·
It's straightforward because talk is cheap. Maybe jrockway could write some near-C speed Python or JavaScript code to enlighten us. And by near-C speed I don't
by blub 17y ago
It's straightforward because talk is cheap. Maybe jrockway could write some near-C speed Python or JavaScript code to enlighten us. And by near-C speed I don't mean 20% slower...
- berntb 17y agoI assume he was thinking of an area like web programming, where a DB mostly is the practical limiting factor for speed. (Or rewriting the (often small) speed critical parts in C, after benchmarking.)
- jrockway 17y agoNo, I wasn't. I was talking about the speed-critical tight loops. Once you let GHC or TraceMonkey or PyPy or ... know what the machine types of your data is, they will generate very fast code; often the same instructions that the C compiler would generate. C is fast because the programmer explicitly names the machine types to be used. Other languages are slow because their operations can't always be expressed in terms of operations the machine can do. (Consider Perl and "2 + 2". This is "slow" because 2 is a "SV", and that means before anything can happen, the integer 2 has to be unboxed from the SV, the runtime has to decide which "+" to use, and then the result has to be boxed in a "SV". This is much slower than running the "ADD" instruction. But if you can somehow specify, "this is not a special boxed value, just treat it as a machine integer and don't worry about overflow or anything special", then you are doing the same thing as C. Modern VMs (and static compilers) can guess this for you and generate the right code.)