Tuesday, March 31st 2026
Intel Binary Optimization Tool Changes Code Execution with Heavy Vectorization
The Intel Binary Optimization Tool (BOT) has been launched alongside the "Arrow Lake Refresh" series of processors, which includes the Core Ultra 5 250K Plus and Core Ultra 7 270K Plus models. While the tool is beneficial for gamers looking to extract a few extra frames from their setups, it may be a nightmare for makers of benchmarking tools like Geekbench by Primate Labs. Recently, Primate Labs testing found that BOT changes the way .exe applications run and concluded that Geekbench runs will now flag these BOT-enhanced runs. However, in deeper testing, Primate Labs discovered that Intel's BOT may deliver significant boosts in some applications like Object Remover and HDR, increasing performance by up to 30%. This is thanks to the deep vectorization that the BOT performs behind the scenes to optimize performance.
For example, Primate Labs used Intel's own Software Development Emulator (SDE) to measure how many instructions were executed and which types of instructions the program executed. Without BOT, Geekbench 6 required a total of 1.26 trillion instructions to finish, while a BOT-enhanced run completed with 1.08 trillion instructions. This is an impressive 14% reduction. However, when examining the execution by type, we see that BOT makes heavy use of vector instructions like SSE2 and AVX2. The number of scalar instructions needed to execute a program fell from 220 billion to 84.6 billion, while the number of vector instructions increased from 1.25 billion to 18.3 billion, a 13.7x increase. This means that Intel BOT finds a way to turn inefficient scalar code into vectorized instructions that are processed much more efficiently inside Intel CPUs. These techniques indicate a very complex behind-the-scenes process than was originally believed. The Geekbench v6.7 update will include a flag for BOT, allowing future Geekbench results to be easily distinguished as BOT-enhanced or not.
We only have a high-level understanding of how the Binary Optimization Tool actually works, but here's the essence as covered in our review of "Arrow Lake Refresh." It builds on Intel's APO technology and profiles a workload at the microarchitectural level to identify where compiled code is not fully utilizing IPC. This process occurs in Intel's labs, not on your machine. If a binary isn't achieving peak efficiency, Intel applies post-link optimization to produce restructured machine code with better instruction density, without altering the source code, decompiling, or involving developers. The original binary on disk remains untouched. Instead, when you enable a profile and reboot, a user-mode service monitors the relevant binaries and silently redirects execution to the optimized paths, similar to how GPU drivers swap in optimized shaders for supported games at runtime. To be clear, the workload still performs all the same tasks, and nothing is skipped or approximated. It's simply reorganized to make better use of the hardware's available execution units.
Source:
Geekbench Blog
For example, Primate Labs used Intel's own Software Development Emulator (SDE) to measure how many instructions were executed and which types of instructions the program executed. Without BOT, Geekbench 6 required a total of 1.26 trillion instructions to finish, while a BOT-enhanced run completed with 1.08 trillion instructions. This is an impressive 14% reduction. However, when examining the execution by type, we see that BOT makes heavy use of vector instructions like SSE2 and AVX2. The number of scalar instructions needed to execute a program fell from 220 billion to 84.6 billion, while the number of vector instructions increased from 1.25 billion to 18.3 billion, a 13.7x increase. This means that Intel BOT finds a way to turn inefficient scalar code into vectorized instructions that are processed much more efficiently inside Intel CPUs. These techniques indicate a very complex behind-the-scenes process than was originally believed. The Geekbench v6.7 update will include a flag for BOT, allowing future Geekbench results to be easily distinguished as BOT-enhanced or not.
29 Comments on Intel Binary Optimization Tool Changes Code Execution with Heavy Vectorization
The better approach is to just make a good CPU architecture that work and provide tools so that devs can optimize their games for your CPU should they want to go the extra step.
In order to get Intel's help on optimizing your own code, you essentially have to be on the scale of AWS or Cloudflare for it to be worth it to optimize. If you're a game or app developer, there's absolutely no reason to have a team of hundreds of software engineers pouring over Intel's documentation to try and make your app run 15% faster on one specific architecture that probably represents ~5% of your install base.
Since Intel is the only one with the knowledge to do this, it's good that they're doing this. It's much better to have hundreds of Intel engineers making a program that can optimize most software for a specific platform, instead of every software company having to pay hundreds of engineers to optimize their own software for a specific Intel platform.
Vectorisation is relatively simple in principle. All modern compilers can even do it automatically.
Going through the instructions to manually do it is probably time consuming tho.
- Intel just optimized x86.A binary code for x86.B hardware
-> then with extra effort, one could also go beyond mere virtualization, and optimize Arm.X binary code for the same x86.B
-=> thinking that even further: if this optimization matches or outweighs the benefit of sticking with the same CPU architecture - why have any architecture-specific code in the first place, instead of generic Intermediate representations like LLVM or JVM.
EDIT: Do you mean the CPU vendor, or software vendor? It changes the meaning a bit.
Devs don't need to know how the CPU works on a low level in order to optimize for it, x86 has well established best coding practices.Poorly worded, I meant per CPU architecture optimizations from the CPU vendor specifically like the GPU market.
web.archive.org/web/20120105060810/http://developer.amd.com/documentation/articles/pages/4292005119.aspx
"
Tags:Processors, Processor Architecture, Compilers
[td]
The range of features and functions in an "industry standard" x86 processor can be bewildering. So, how do optimizing compilers know what to optimize for, and how do binaries understand their processor's capabilities? Steve Westfield investigates this curious mystery. And no, the butler didn't do it.
[RIGHT][td]
4/29/2005 [/RIGHT]
The x86 instruction set is an industry standard, and is found in chips like Intel's Pentium, Celeron and Xeon processors, as well as in AMD's Opteron, Athlon, Sempron, and Turion processors, and even in chips from other manufacturers, like VIA Technology's C3 processor family.
While the hardware specifications and interfaces of those x86-compatible chips vary, along with power consumption and performance characteristics, they all conform to the core x86 instruction-set standards. Many also offer extensions to that x86 architecture, and many of those extensions have been implemented by several vendors. This means binary portability. Compilers written for one x86 processor should create object code and binaries that run on any contemporary x86 processors with those same extensions. The use of standards provides economy of scale, gives customers choices, and fosters innovation on implementation of those standards.
There are many extensions to the x86 architecture, such as the original MMX multimedia extensions, which were then enhanced by SSE (Streaming SIMD Extensions), then SSE2 and, more recently, SSE3. Those are all found on processors made by Intel and by other companies, including AMD.
Another popular extension adds 64-bit capabilities to the 32-bit x86 processor. These extensions, which contain both new instructions and new registers, were initially developed by AMD as part of its AMD64 architecture, but were also implemented in Intel's newest Xeon processors with Extended Memory 64-bit Technology (Intel EM64T).
It's good that AMD and Intel, the two microprocessor giants, as well as smaller companies like VIA, use the same core instruction-set standard. This allows the companies to innovate and compete on implementation, while we developers and end users can be assured that compiled code will run on any x86-based system with the right instruction-set extensions.
As you probably know, there are many excellent native compilers available for x86 processors, and most of these compilers can handle most (or all) extension-set extensions targeting Linux, Unix, and Windows. Developers can choose a wide range of compilers to use, including the open-source GNU compiler collection, and outstanding offerings from PathScale, Portland Group, Intel, Sun and Microsoft.
Unfortunately, there are sometimes a few glitches. Intel's compilers, for example, don't always compile to run on non-Intel chips. But for the most part, all of those compilers target the x86 instructions, perform extension-set optimizations, and generate binaries that generally work fine on all x86 chips.
Of course, when you write an application, there's no way for your toolchain to know what type of runtime system you're targeting. So, by default, the compiler targets the widest possible installed base, by generating binaries for an x86 processor with few or no extensions. If you want to optimize your code to take advantage of specific processor hardware extensions—Ssuch as the SSE2 or SSE3 floating-point instructions or registers, or the 64-bit x86 extensions that AMD calls AMD64 and Intel calls Intel EM64T, you use compiler switches.
For example, the Intel 8.1 C/C++ compiler uses the flag -xN (for Linux) or -QxN (for Windows) to take advantage of the SSE2 extensions. For SSE3, the compiler switch is -xP (for Linux) and -QxP (for Windows). This instructs the compiler to use the new extensions and registers. However, code that uses those registers and instructions would crash and burn if run on a processor that doesn't have the extra bits of hardware needed to support those extensions.
So the optimizing compiler also adds a bit of runtime code that actually checks to see if the processor has the right extensions, and then gently fails the app if it runs on a non-supported processor. In the case of the Intel compiler, it fails with the message, "Fatal Error: This program is not built to run on the processor in your system."
So far, so good. But how does that little bit of runtime code see if the processor is compatible? It doesn't actually try executing the extensions. Instead, it uses the CPUID instruction to ask the processor to explain its specific capabilities.
Check the Badge
The CPUID (central processing unit identification) instruction lets operating systems and applications determine if they are compatible with the hardware platform, as well as choose the proper execution paths or runtime libraries to leverage specific processor features.
Depending on the input parameter specified in the EAX register, CPUID can return two different sets of information. If the EAX register contains a 0, CPUID stores the processor vendor string in the EBX, ECX, and EDX registers. If EAX contains 1, then CPUID puts a list of feature capability flags into those three registers.
The processor vendor string is easy to analyze, but isn't hugely valuable to most developers. If CPUID is run on an Intel processor, the string returned is "GenuineIntel." If it's an AMD processor, it's "AuthenticAMD." (I don't have a system with a VIA processor, so I can't check the string.) Normally, the processor vendor string isn't important except for trivia. Windows, for example, will tell you the manufacturer of the processor from the My Computer -> Properties dialog.
Far more important to an operating system and its applications—and in particular, apps optimized for specific processor extensions—are the feature flags returned by calling CPUID with EAX=1. This loads the EBX, ECX, and EDX registers with bits indicating the specific capabilities of the microprocessor, including which x86 extensions it supports. Intel and AMD use these bits in a consistent way.
For example, bit 23 in the EDX register indicates whether the processor supports the original 64-bit MMX instructions. Bit 25 indicates SSE and bit 26 is for SSE2. Bit 0 in the ECX register indicates support for the SSE3 instructions.
Many current Intel and AMD processor models (and future VIA processors expected to be released this year) support MMX, SSE, and SSE2, and return the proper bits from CPUID. The latest Intel Xeon processors, and revision E (or later) of the AMD Opteron processor, set the SSE3 bit to 1; for earlier processors, it's set to 0.
(Detailed information about CPUID is in the AMD64 Architecture Programmer's Manual, Volume 3. In the February 2005 edition of this manual, the CPUID instruction is covered beginning on page 117. These flags are documented in tables 3-4 and 3-5, beginning on page 123.
The expected behavior for an application compiled to use the SSE2 or SSE3 extensions is that the compiler would insert a library that can analyze processor capabilities. On application launch, that library would call CPUID with EAX containing a 1, and then check the appropriate bits to make sure the required extensions are supported. Only then would it allow execution to continue. That's the behavior for most compilers when using those types of optimizations.
You should know, by the way, that this isn't what the Intel compiler's little bit of runtime code does. With the -xN/-QxN and -xP/-QxP flags set, it checks the processor vendor string—and if it's not "GenuineIntel," it stops execution without even checking the feature flags. Ouch!
Fortunately, there are workarounds. There are other compiler switches that you can use to tell the Intel compiler to use hardware extensions without checking the processor vendor string. However, it's unclear if those other switches perform the same level of optimization.
But that's what you have to do if you want to optimize code for processor extensions using the Intel compiler, and you want your code to run on non-Intel hardware. Those switches are, for example, -axN/-QaxN for SSE2 and -axP/-QaxP for SSE3.
The bad news is that the -axN/-QaxN and axP/-QaxP tell the compiler to generate multiple code paths. The optimized SSE2 or SSE3 code paths are still vendor-checked; the difference is that there will be a generic (less optimized) fallback. The application will run—you won't get the dreaded "Fatal Error." But the best possible code path won't run on a non-Intel processor. Your app runs... but it's not fully optimized. Still, it's better than not running at all.
What Can You Do?
Currently, developers cannot create optimized applications using the Intel compilers that will run on non-Intel processors. The only way to achieve runtime portability is to disable optimizations that might cause the binaries to fail on non-Intel processors. This reduces the value of an expensive optimizing compiler.
How can this be addressed? Developers could request that Intel change the behavior of its compilers, and use the industry-standard feature flags, not the proprietary processor vendor string, to determine when a processor is compatible with specific compiler optimizations and instruction set instructions.
In the meantime, the best bet is to switch to a different family of compilers. As mentioned above, there are plenty of options available, from PathScale to Portland Group, from Microsoft to Sun, as well as open-source compilers from GNU. If you're trying to develop for an industry-standard architecture, you can't use tools that won't respect those standards.
Steve Westfield is a C/C++ programmer, consultant and video game addict who lives outside of Chicago.
[RIGHT][/RIGHT]
[/td]
[/td]
"
TLDR Intel in 2005 had slower CPU's but found that if their compiler (commonly used at the time) didn't allow certain instruction paths on "other" competing CPU hardware the got a speed boost and looked faster. Now it appears they are doing it again....
gnu gentoo linux and the amd64 handbook and the gcc manual teaches a few things.that topic just verifies what i write quite often
- p*ssmark or benchmarks are not valid (when geekbench is a fail than pissmark will be also a fail in this regards. i do not care that i thought passmark is usebenchmark)
- windows software is hardly optimised (w11 pro runs on intel 3rd generation ivybridge cpus. a indicatior that cpu instructions are not used)
- higher instructions are hardly used in windows 11 pro (w10 etc I consider eol, regardless of special licenses)
- look up certain fps numbers / benchmark numbers / seconds used for certain software in certain operating systems when you are choosing hardware. e.g newbie strike 2 players will look up for newbie strike 2 benchmarks.
- my code will not execute on most / some intel processors.
- when avx512 does not exists in intel processors software can hardly be proper optimised. avx512 will be hardly be in use because most intel processors can not do it. intel dodged it also by altering their avx512 insturciton set to a weaker worse newer renamed avx512 "vector" instruction set.
when a cpu has cpu flags (linux terminology see /proc/cpuinfo) or certain instructions than the code can be run. taht is not an intel thing. intel does usually support less instructions = cpu flags as amd processors.that topic should be pinned and pulled out when people think benchmarks are worth it or do not understand instructions in windows 11 pro.
note: should there be errors inside I want to ask you to read gcc first or the over 500 pages ore more several pdf files from intel or amd. these are the only valid references. and things sometimes change silently without a lot of news on tech pages.
as i suspected year 2010 instrtuctins are not used. and year 2013 instructions. well i assume the mediocre low quality wikipedia has this correct
see en.wikipedia.org/wiki/SSE2
note: small 4 digit numbers are the year the simd instruction was introduced. xop - amd dropped, therefore amd processors are not fully downwards compatible. amd bulldozer code will not execute on zen4 and zen5.why? just why?
a dissassembler is not allowed in my region. what most likely intel does
i compile since 2006 most binaries in my gnu gentoo linux. why should i need it with the linux kernel?
when you download a binary, you download crap. with all the issues, hidden backdoors, optimised for i686 or worse, etc. just compile it from source.
those games see the not being allowed to use dissassemblers.
skype was a binary in the past / steam was a binary. else i can hardly remember anything else which was a binary. yes teamspeak 3 around 15 years ago.
most gentoo discussions lead to people claiming, those optimisations may improve performance around -5 to +5%.
-- afaik arm9a which most smartphone arm chips do not have introduce similar avx512 cpu instructions. they were in my point of view added because some arm smartphone chips are used in desktop like computers. arm renamed the instruction in a different way and changed it like intel a bit.gcc manual or see /etc/porage/make.conf previous /etc/make.conf - the march line of gcc.
and also the gcc changes which i was not aware of, suse and someone else introduced some bigger cpu instruction sets which include certain processor generations.
Do you understand what that means?
Trivia time: Until Intel switched to LLVM, AMD used the Intel compiler for their own driver development because it produced better output even on AMD CPUs. Weird huh?
In addition to losing a valuable collaboration from AMD, it will increasingly give to ARM and RISC-V CPU makers a greater chance to gain more market share.