3 ms·

I have to imagine the differing instruction sets means different extensions, not entirely different ISA. I'm not a programmer, but doesn't compiled code often

by ip26 6y ago

I have to imagine the differing instruction sets means different extensions, not entirely different ISA. I'm not a programmer, but doesn't compiled code often offer multiple codepaths, checking flags at runtime? So if your code runs on the big core, it finds avx256 is supported, and uses the avx256 codepath. If it runs on the little core, it finds avx256 is not supported and it takes a legacy floating point codepath instead.

mooman219 6y ago
Tons of asterisks here, but: You'll have to explicitly write the code to do that at runtime if APIs are provided to do so. When you build for a target, say x86, you're usually targeting the lowest common denominator that you're willing to support and the compiler might not output less supported instructions even if the CPU it's compiling on supports them.
- gpderetta 6y ago
  Yes, most programs target the generic x86-64 ISA which means sse2 at most. Still some have accellerated paths that are enabled looking at feature bits. So a simple solution is for the os to mask out some of those bits for processes that intends to potentially migrate to the less featured cores, while potentially giving the option to let the user "pin" a process to the fast cores enabling the all features.
Dylan16807 6y ago
The problem is that you want to be able to migrate processes between cores. It's not the end of the world if a number-crunching process gets stuck on the big core. But if a process detects an instruction that it's only using for convenience purposes, and that causes it to get stuck on the big core or stuck on the little cores, that's not good. In a different scenario, if it was set up so that a process starting on a little core never detected an important instruction, and was stuck in slow mode forever, that would also not be good. It depends a lot on which instructions differ and how the feature flags work, of course. They might have set it up in a way that's fine.

by ip26 6y ago

mooman219 6y ago

Tons of asterisks here, but: You'll have to explicitly write the code to do that at runtime if APIs are provided to do so. When you build for a target, say x86, you're usually targeting the lowest common denominator that you're willing to support and the compiler might not output less supported instructions even if the CPU it's compiling on supports them.

gpderetta 6y ago
Yes, most programs target the generic x86-64 ISA which means sse2 at most. Still some have accellerated paths that are enabled looking at feature bits. So a simple solution is for the os to mask out some of those bits for processes that intends to potentially migrate to the less featured cores, while potentially giving the option to let the user "pin" a process to the fast cores enabling the all features.

Dylan16807 6y ago

The problem is that you want to be able to migrate processes between cores. It's not the end of the world if a number-crunching process gets stuck on the big core. But if a process detects an instruction that it's only using for convenience purposes, and that causes it to get stuck on the big core or stuck on the little cores, that's not good. In a different scenario, if it was set up so that a process starting on a little core never detected an important instruction, and was stuck in slow mode forever, that would also not be good. It depends a lot on which instructions differ and how the feature flags work, of course. They might have set it up in a way that's fine.