3 ms·
I 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 c
by berntb 17y ago
I 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.)