> Our results suggest that it can give large improvements when training for a specific benchmark. > improved the execution speed of the program for which the o

> Our results suggest that it can give large improvements when training for a specific benchmark. > improved the execution speed of the program for which the order was optimized between 0.8% and 23.0% with 7.7% on average. Single-digit speedup is not worth it IMO, and the wide range (<1% - 23%) probably means that you specialize for some tasks at the expense of other types of tasks, which is not for everyone's interpreter. One use I can see for it is to compile multiple inner loops and have the interpreter switch between them (probably manually), if that can get us the yummy 20% speedup. Core primitives and dispatchers are usually not the biggest part of interpreters, after all. Maybe in this scenario the core primitives could also benefit from small semantic changes, like no bounds checking for instance.