In the JS world, tracing was abandoned because it didn't scale to real world code.
JS JITs (the production ones, like JSC's) have no such thing as trace blockers that prevent the surrounding code from being optimized. You might have an operation (like a call to some wacky native function) that is itself not optimized, but that won't have any impact on the JIT's ability to optimize the code surrounding that operation.
Tracing is just too much of a benchmark hack overall IMO. Tracing would only be a good idea in a world where it's too expensive to run a real optimizing JIT. But the JS, Java, and .NET experiences show that a real optimizing JIT - with all of its compile time costs - is exactly what you want because it results in predictable speed-ups
marky1991•20m ago
Pypy's tracing JIT has worked pretty well for years, so that doesn't seem universal. I admit I have fairly low expectations on a JIT succeeding (in any meaningful fashion) in cpython given the constraints that it currently has, but I'm generally a skeptic, so maybe i'm being overly pessimistic.
pizlonator•55m ago
JS JITs (the production ones, like JSC's) have no such thing as trace blockers that prevent the surrounding code from being optimized. You might have an operation (like a call to some wacky native function) that is itself not optimized, but that won't have any impact on the JIT's ability to optimize the code surrounding that operation.
Tracing is just too much of a benchmark hack overall IMO. Tracing would only be a good idea in a world where it's too expensive to run a real optimizing JIT. But the JS, Java, and .NET experiences show that a real optimizing JIT - with all of its compile time costs - is exactly what you want because it results in predictable speed-ups
marky1991•20m ago