Feature or enhancement
Proposal:
This provides an alternative design to #133171. I have a branch where all tests (including FT) pass.
Part 1:
For the first and simplest part, we could add a watcher/callback to thread creation. When multiple threads are created, we simply invalidate the executor as _CHECK_VALIDITY fails.
This means single threaded code gets all the benefits of JIT in the future, while multi-threaded code will lose all the benefits. However, both can coexist at the same time in the same build. We will finally get JIT + FT in a limited form. Pending part 2.
Part 2:
If we detect multiple threads are running, we turn off the non-thread safe optimizations, and redo the trace with those optimizations off. If we detect only a single thread, we follow part 1 and run till we get invalidated. This allows single threaded code to run faster, while multi-threaded code will run a little slower. Note that all optimizations I've proposed for the JIT in the past 6 months and in the future are FT safe (in theory. whether they are implemented in practice is different).
Together, part 1 and part 2 get the best of both worlds: for single-threaded code, we get max performance, even recovering some of the perf single-threaded perf lost from FT. In part 2, we get max compatibility with multiple threads.
We need both parts to get the max perf out of the JIT on FT.
Follow-up after this:
- Lock/unlock removal in FT code.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#133171
Linked PRs
Feature or enhancement
Proposal:
This provides an alternative design to #133171. I have a branch where all tests (including FT) pass.
Part 1:
For the first and simplest part, we could add a watcher/callback to thread creation. When multiple threads are created, we simply invalidate the executor as _CHECK_VALIDITY fails.
This means single threaded code gets all the benefits of JIT in the future, while multi-threaded code will lose all the benefits. However, both can coexist at the same time in the same build. We will finally get JIT + FT in a limited form. Pending part 2.
Part 2:
If we detect multiple threads are running, we turn off the non-thread safe optimizations, and redo the trace with those optimizations off. If we detect only a single thread, we follow part 1 and run till we get invalidated. This allows single threaded code to run faster, while multi-threaded code will run a little slower. Note that all optimizations I've proposed for the JIT in the past 6 months and in the future are FT safe (in theory. whether they are implemented in practice is different).
Together, part 1 and part 2 get the best of both worlds: for single-threaded code, we get max performance, even recovering some of the perf single-threaded perf lost from FT. In part 2, we get max compatibility with multiple threads.
We need both parts to get the max perf out of the JIT on FT.
Follow-up after this:
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
#133171
Linked PRs