Hacker News Reader

Describing this as not easy is a bit of an understatement; there has been a lot of research into speculative threading and communication overhead between cores almost always kills it.

View on HN

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.

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