3 ms·

I read it, but I don't see the counter-argument. It seems to say that people who want a C extension for Ruby, for performance reasons over native Ruby, can use

by dalke 12y ago

I read it, but I don't see the counter-argument. It seems to say that people who want a C extension for Ruby, for performance reasons over native Ruby, can use a system which dynamically compiles the C extension code. While this proposal seems to be that fewer and fewer programmers know how to optimize against the machine.

mike_hearn 12y ago
So optimising compilers are becoming more important, not less, then. Edit: to clarify, the interesting thing about that blog is not the cross language interop magic, though that is pretty cool, it's that a smart compiler that can compile C and ruby together simultaneously can delete vast swathes of abstraction and overhead to produce radical speedups, just through better optimisation. So whilst things might not be moving very fast in the world of more traditional compilers, research compilers with a focus on dynamic languages are still showing big speedups. It's a bit early to proclaim the death of optimising compilers just yet, though perhaps I've just misunderstood the abstract. I'm not sure the latest hanging fruit for compiler developers is using more and more exotic machine instructions
- dalke 12y ago
  I view it as two different things. There are many optimizations which work on a simple machine model that hasn't changed much since the VAX. There's memory with constant time lookup, some registers, and assembly code. Real hardware changed long ago. As a simple example, on traditional hardware it's best to save and re-use intermediate values, but on modern hardware RAM lookup is so slow that it can be faster to recompute rather than doing a random lookup. An optimizing compiler isn't going to do much if the code wasn't designed to match the hardware, or expects a different hardware model. While lowering the impedance mismatch between two systems, whether it be two different languages as in your example, or serialization/deserialization, or call thunking, belongs to an old and well-understood set of optimizations which are nearly insensitive to the machine model. RAM lookup, and cache performance, and cache lines, are important for high performance code. Though as the abstract says, most people only work with "freezingly cold" code, so aren't aware of the limitations in the conceptual machine model vs. the actual machine. Fixing this almost always requires deep changes to the code, which an optimizing compiler can't do.

by dalke 12y ago

mike_hearn 12y ago

So optimising compilers are becoming more important, not less, then. Edit: to clarify, the interesting thing about that blog is not the cross language interop magic, though that is pretty cool, it's that a smart compiler that can compile C and ruby together simultaneously can delete vast swathes of abstraction and overhead to produce radical speedups, just through better optimisation. So whilst things might not be moving very fast in the world of more traditional compilers, research compilers with a focus on dynamic languages are still showing big speedups. It's a bit early to proclaim the death of optimising compilers just yet, though perhaps I've just misunderstood the abstract. I'm not sure the latest hanging fruit for compiler developers is using more and more exotic machine instructions

dalke 12y ago
I view it as two different things. There are many optimizations which work on a simple machine model that hasn't changed much since the VAX. There's memory with constant time lookup, some registers, and assembly code. Real hardware changed long ago. As a simple example, on traditional hardware it's best to save and re-use intermediate values, but on modern hardware RAM lookup is so slow that it can be faster to recompute rather than doing a random lookup. An optimizing compiler isn't going to do much if the code wasn't designed to match the hardware, or expects a different hardware model. While lowering the impedance mismatch between two systems, whether it be two different languages as in your example, or serialization/deserialization, or call thunking, belongs to an old and well-understood set of optimizations which are nearly insensitive to the machine model. RAM lookup, and cache performance, and cache lines, are important for high performance code. Though as the abstract says, most people only work with "freezingly cold" code, so aren't aware of the limitations in the conceptual machine model vs. the actual machine. Fixing this almost always requires deep changes to the code, which an optimizing compiler can't do.