11 ms·

The key problems with this approach is not mentioned in the blog post, but is shown in figures 6 and 7 of the paper - https://stefan-marr.de/downloads/acmsac23-

The key problems with this approach is not mentioned in the blog post, but is shown in figures 6 and 7 of the paper - https://stefan-marr.de/downloads/acmsac23-huang-et-al-optimizing-the-order-of-bytecode-handlers-in-interpreters-using-a-genetic-algorithm.pdf https://stefan-marr.de/downloads/acmsac23-huang-et-al-optimi... Basically, the code handler ordering does not generalise well across benchmark nor processor, so to get the speedup they see, you'd need a specialised interpreter for your specific benchmark and processor. That puts this into the "interesting, but not very practical" category.

CmdDot 3y ago
From the post: «In the context of resource-constraint embedded devices, it may make sense to tailor an interpreter to a specific applications to gain best performance.» The «key problems» are also discussed in the introduction of the paper at the top of page 2 - including why it’s practical in their context. Also in the paper, they say speedups based on optimizing a subset of benchmarks generalize to other benchmarks as well, but not across environments. Last I checked, starting with an «optimizing your environment» task, is far from being considered «not very practical»
_a_a_a_ 3y ago
Come on man, they literally say that, and acknowledge hardware may differ in behaviour, that difference too to be subsumed by the training/optimising.