Hacker News Reader

The main hurdle is getting a block of execution large enough to make it worthwhile trying alternatives and absorbing the cost of setup and finish. I suspect some form of STM would help a lot since you could then run multiple threads of code and only "commit" the winner. That allows a larger execution block.

I also think software people still have a innate fear of "wasting" CPU/memory/disk which is hard to overcome.

View on HN

One example of where this is used in practice is the fftw library (fastest Fourier Transform in the west). At runtime you can run a trial of FFT algorithms for your data size and architecture, and it will pick the fastest.

It is a pain with FFTW since they expose all this in the API, let you save/load the details etc. A better example is MongoDB. When you make a query they try multiple query plans concurrently, note which is fastest and use that in the future with continued performance monitoring. Once diverging from expectations they run the contest again.

Compare with other databases that put an inordinate amount of effort and tuning into coming up with the one true query plan per query.

Reply on news.ycombinator.com