libmacchina
                                
                                 libmacchina copied to clipboard
                                
                                    libmacchina copied to clipboard
                            
                            
                            
                        Windows: Implement `cpu_physical_cores` and `cpu_cores`
Hello, I'm a contributor to https://github.com/lptstr/winfetch (you've talked to the maintainer in #112), and would like to start applying some of the experience I gained there to this project.
- cpu_physical_cores- Uses the implementation in https://github.com/seanmonstar/num_cpus/blob/master/src/lib.rs#L129
- Calls GetLogicalProcessorInformationand uses the returned buffer to get the computer's number of CPU cores
 
- cpu_cores- Gets HKLM\HARDWARE\DESCRIPTION\System\CentralProcessorand counts the number of subkeys
 
- Gets 
You may get physical cores and logical cores ( threads ) at the same time with GetLogicalProcessorInformationEx(RelationAll)
https://github.com/LinusDierheimer/fastfetch/blob/b3da6b0e89c0decb9ea648e1d98a75fa6ac40225/src/detection/cpu/cpu_windows.c#L17
Because this method requires copying more data from the kernel, I'm not sure whether it's faster than your implementation. Just another idea.
I added several alternative implementations
Implementation Speeds:
- Command used: hyperfine --warmup 20 --prepare "cmd" --min-runs 200 ".\macchina.exe --show processor"- Compiled in release mode
 
Plugged in:
- GetLogicalProcessorInformation- 13.6 ms
 
- Environment Variable
- 13.7 ms
 
- Registry
- 13.7 ms
 
- GetNativeSystemInfo- 14.0 ms
 
- Physical Cores (also GetLogicalProcessorInformation)- 14.0 ms
 
On Battery life:
- GetLogicalProcessorInformation- 30.8 ms
 
- Environment Variable
- 31.2 ms
 
- Registry
- 31.1 ms
 
- GetNativeSystemInfo- 30.7 ms
 
- Physical Cores (also GetLogicalProcessorInformation)- 31.1 ms
 
When heavily throttled (used power plans to downclock CPU to 1.06 GHz to simulate a slow computer)
- GetLogicalProcessorInformation- 55 ms
 
- Environment Variable
- 53.5 ms
 
- Registry
- 54.6 ms
 
- GetNativeSystemInfo- 54.3 ms
 
- Physical Cores (also GetLogicalProcessorInformation)- 54.7 ms
 
There's virtually no difference between some of the implementations and those of num_cpus, why not call those two functions directly?
According to stackoverflow, WMI, registry and GetLogicalProcessorInformationEx are only reliable ways to get the number of cpu logical cores (threads)
According to stackoverflow, WMI, registry and GetLogicalProcessorInformationEx are only reliable ways to get the number of cpu logical cores (threads)
That does seem to be the case. I've made a commit that addresses it. cpu_cores now uses GetLogicalProcessorInformationEx to get the number of cores, and has Registry and WMI based implementations as backups. cpu_physical_cores now uses GetLogicalProcessorInformationEx as well.
I used the implementation here as the basis of my implementation of GetLogicalProcessorInformationEx.
Hi, I'm making a tool that can benefit from this. Any way we can get this merged?
I've got a Windows VM lying around but I'm a bit busy at the moment. If this works correctly, I don't have a problem accepting the PR. I would appreciate @uttarayan21's input on the state of this PR because he's much more knowledgeable on Windows than I am.