
Permalink for comment 207770
Member since:

That's the fun thing about "theoretically better" solutions. In practice, you're so often limited by developer resources, that a simple, but well-implemented and highly tuned solution will end up being better than a more sophisticated design that hasn't had the same amount of tuning. Take, for example, GCC's register allocator. It's a theoretically unsophisticated design with an enormously complex (and convoluted) implementation. We're talking about something that wouldn't have been state of the art even 20 years ago. Yet, it creates surprisingly good allocations, because it's had so much tuning. Or, take the x86 code generator in Ocaml. It doesn't do any fancy SSA-based optimizations, but it generates very good code.The generated code is very straightforward and small, and it turns out that modern x86's care very much about code size and very little about fancy scheduling.

Now, of course, implementation tuning being equal, a fancy design is almost always going to be better. However, developers rarely have the luxury of unbounded time, and given that constraint, a more sophisticated design often implies a less well-tuned implementation. That's why there is no alternative to experimentation when writing performance-sensitive code. You'll be surprised just how often theoretical arguments fail to fully model all the relevant details.

Reply Parent Score: 2