LabVIEW
Bug with CPU Information
Not sure if this has been reported, cannot find anything with a quick look, but inspired by this thread to look at my CPU information, there is a bug with the CPU Information VI in 2024Q3. I assume it extends back to previous versions. This CPU Information VI can report erroneous information when you have a mixture of P & E cores.
The P cores in my CPU support 2 threads whereas the E cores support 1 thread. (I have 6 P cores and 8 E cores for 20 "logical processors") The number of logical processors is correctly recorded, but the number of cores cannot be correctly stated because of the thread difference of the CPUs. Version 2019 attached.
The System Configuration VIs gives the correct value.
Interesting, but not surprising. Differing threads/core is a quite new phenomenon, so it'd assume it only asks for Locical CPUs and Threads/core for the 1st core and divides, instead of looping through all to save performance.
Though, can you use all 20 at once? Isn't performance mode 14 and energy saving 6 threads?
Hi Yamaeda,
@Yamaeda wrote:
Though, can you use all 20 at once? Isn't performance mode 14 and energy saving 6 threads?
You can use 20 cores at once.
There are 6 P cores, that allow for hyperthreading, so you get 12 threads.
And 8 E cores without hyperthreading. In total you have 20 threads available…
I see a similar behaviour in LV2021 for my 2P+8E system: 12 logical cores, in 6*2 arrangement (instead of 2*2 + 8*1)…
@Yamaeda wrote:
(How) can you control which thread goes where?
You can use Timed While loop, where you have CPU Input, but I didn't test it on such CPU, because haven't yet in my hands.
@mcduff wrote:
. However, the system configuration vi's are much slower than the CPU Information vi.
Speed is irrelevant here because the information cannot change at runtime. You can just wrap it into a non-reentrant subVIs that caches it on first run and just returns the cached value later. (I am sure CPU info does the same internally!)
When maintaining my benchmarks page, I have struggled for a long time to update the table because I cannot rely on the LabVIEW information output (there are more inconsistencies beyond what you mentioned). I have to manually look up each new CPU from the AMD or Intel sites. It is hard to tell how the workload is really split between P and E cores, but the overall performance is still reasonable. I am sure windows itself is aware of the core blend and contributes some magic.
For example while a 32 core Ryzen 9 has a close to 32x parallel advantage, a 24 core (P&E mix) I9 is actually only 16x faster, (i.e. not 24x)!
@altenbach wrote:
When maintaining my benchmarks page, I have struggled for a long time to update the table because I cannot rely on the LabVIEW information output (there are more inconsistencies beyond what you mentioned). I have to manually look up each new CPU from the AMD or Intel sites. It is hard to tell how the workload is really split between P and E cores, but the overall performance is still reasonable. I am sure windows itself is aware of the core blend and contributes some magic.
The mixing of Efficiency and Performance cores was announced in 2021, with their first commercial release in 2022. So why hasn't NI updated LabVIEW's CPU Information primitive in the last 3-4 years to support getting this information correctly? You maintaining a table of information is the most accurate way to get the this information today, which sounds tedious.
@Hooovahh wrote:
The mixing of Efficiency and Performance cores was announced in 2021, with their first commercial release in 2022. So why hasn't NI updated LabVIEW's CPU Information primitive in the last 3-4 years to support getting this information correctly?
The problem is that it would require changing the connector pane (more parameters!) and it is sort of a moving target. Maybe all outputs should be arrays.
I am not really sure how useful the CPU information is, because there are so many other factors, such as thermal throttling if all cores are active. The number of virtual cores is reasonable to guide the number of parallel instance by default.
I have not played with it, but how is it with the timed loop if we assign it to a processor? Do we even know what kind of core we get?
@altenbach wrote:The problem is that it would require changing the connector pane (more parameters!) and it is sort of a moving target. Maybe all outputs should be arrays.
CPU architecture doesn't change all that frequently, and NI adapting a primitive (or creating a new one) seems like a fairly easy thing to do. I suspect the underlining technology they use, which might be home grown, is the bigger challenge. If NI made their own set of tools for detecting CPU information, and the developer responsible for that left NI a long time ago, then bugs in this primitive could take a long time to understand and fix. Still NI is a big company, and a function like CPU Information, seems like the kind of thing they should make sure works with CPUs from the last 3-4 years.
