News for hackers. Stuff that matters.
Re:Squeezing a Little More Performance Out of Bytecode Inter... by runehol on Sunday June 18, 2023 @04:20AM (#36378302)
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-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.

Re:Squeezing a Little More Performance Out of Bytecode Inter... by CmdDot on Sunday June 18, 2023 @05:33AM (#36378644)
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»

Re:Squeezing a Little More Performance Out of Bytecode Inter... by _a_a_a_ on Sunday June 18, 2023 @09:07AM (#36379952)
Come on man, they literally say that, and acknowledge hardware may differ in behaviour, that difference too to be subsumed by the training/optimising.