I do wonder what this "optimize" step actually entails; does it just replace the binary with one that Intel themselves carefully decompiled and then hand-optimised? If it's a general "decompile-analyse-optimise-recompile" (perhaps something similar to what the https://en.wikipedia.org/wiki/Transmeta_Crusoe does), why restrict it?
I'll take the side of Geekbench here. There is no reason for Intel to optimize a benchmark tool except to cheat. The goal of GB is to test how typical applications run, not the maximum performance possible under ideal scenarios.
It doesn’t seem like Intel’s BOT delivers more performance gains, and it is closed source.
[1] https://www.intel.com/content/www/us/en/support/articles/000...
I swore Intel had their own PLO tool, but I can only find https://github.com/clearlinux/distribution/issues/2996.
It was open source, but has since been deprecated.
BOLT could do this, but does not as far as I’m aware.
Most of vectorization like this is also probably better done in a compiler middle end. At least in LLVM, the loop vectorizer and especially the SLP Vectorizer do a decent job of picking up most of the gains.
You might be able to pick up some gains by doing it post-link at the MC level, but writing an IR level SLP Vectorizer is already quite difficult.
Intel built a tool that will only activate for a specific benchmark - but not for real-world software which accomplishes similar things - and then the tool will replace generic bytecode with a (most likely) handcrafted and optimized variant for running this specific benchmark on this specific CPU. That means BOT will only boost the benchmark score, but not help at all with the end-user workflows that the benchmark is trying to emulate. Thereby, Intel's BOT makes the benchmark score misleading, which is why Geekbench is flagging them.
Wait until they hear about branch predictors.
