21–30 of 203 posts
Earlier quoted context omitted.
Have you considered reading the fucking presentation before snarking out on it?
What makes you think I didn't? The author seems to agree with me. He even concludes that we should improve the implementation rather than the language for optimisation.
Question: The author claims to be a compiler author. After some digging I haven't found any information on what compilers he has written or are part of writing. Could someone point me to the compiler(s) Alex is involved with? Thanks.
This is misleading and contains errors like calling C++ "C". Unless you have a great deal of knowledge about these things already, I urge you not to learn from this but read the slides purely for entertainment. Question: The author claims to be a compiler author. After some digging I haven't found any information on what compilers he has written or are part of writing. Could someone point me to the compiler(s) Alex i…
It is almost time that people stop referring to Languages as Fast or Slow. It is an implementation that is fast or slow, not a language.
Meh, MEH. I'm almost never waiting on my python code. I'm waiting on network or disk or database or joe to check in his changes or etc. I'm sure there are people who do wait. But that's why numpy, c extensions, all the pypy, psycho, and similar things exist. Python and more broadly "scripting" languages are for speed of development. Something else can take on speed of execution faster than 90% of people need it to be…
4 years later and they still discuss it, heh.
Kind of a poorly-named deck. It's really about why programs use features of these languages that end up causing poor performance relative to C, rather than why the individual VMs themselves are slow. It's no surprise that trading the byte-precision of C for the convenience of a garbage collector and heap-allocated data structures results in a performance decrease. Dynamically-typed languages are often easier to progr…
I think the idea that GC is what slows down dynamic languages has to be the most prevalent misconception about language performance.
This is misleading and contains errors like calling C++ "C". Unless you have a great deal of knowledge about these things already, I urge you not to learn from this but read the slides purely for entertainment. Question: The author claims to be a compiler author. After some digging I haven't found any information on what compilers he has written or are part of writing. Could someone point me to the compiler(s) Alex i…
Earlier quoted context omitted.
If the deck is to be believed, it's not the garbage collector or the heap that's causing the performance loss, it's that APIs and algorithms they enable are allocation-heavy compared to other "faster" languages. Heap allocations are expensive even in non-GC languages.
The first example is lookup based on name, you can get away from that in python with slots but the common consensus is that it's not worth the performance improvement. That somehow translates into a dogma like, "Never use slots," but sometimes it is worth it.
You can get away from that with a sufficiently smart JIT turning a stable access to a known object into little more than a vtable dispatch. That's close to what V8 does with hidden classes on full cache hits (object map — its "hidden class" — + object "array" property both cached).
point.x
cmp [ebx,],
jne
mov eax,[ebx, ]
Earlier quoted context omitted.
Have you considered reading the fucking presentation before snarking out on it?
What makes you think I didn't? The author seems to agree with me. He even concludes that we should improve the implementation rather than the language for optimisation.