3 ms·

One thing I would like to see is speculative execution. I have an 8 core machine. When the JIT compiler runs there is no reason why it can't generate 7 altern

One thing I would like to see is speculative execution. I have an 8 core machine. When the JIT compiler runs there is no reason why it can't generate 7 alternatives to any particular code sequence, run them all in parallel and keep whichever was the fastest. Or run both sides of an if statement simultaneously. This helps solve the problem that compiler writers often have multiple alternatives they can generate, but have to make hard decisions as to which to pick. I'm not saying that implementing this will be easy, but then again all of the easy things have already been done.

wmf 15y ago
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.
- rogerbinns 15y ago
  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.
  - maxs 15y ago
    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.
    - rogerbinns 15y ago
      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.

wmf 15y ago

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.

rogerbinns 15y ago
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.
- maxs 15y ago
  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.
  - rogerbinns 15y ago
    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.