just::thread Support Forum

General Category => General Discussion about just::thread => Topic started by: Kenneth Carter on November 19, 2008, 09:39:58 PM

Title: thread::hardware_concurrency static Member Function
Post by: Kenneth Carter on November 19, 2008, 09:39:58 PM

based on the documentation you mentioned that this should return the number of processors.

so I was expecting it to return '2'. I was surprised to recieve the number '2036182'.

which leads to the question of how that number was picked and why?

Kenneth

Title: Re: thread::hardware_concurrency static Member Function
Post by: Anthony Williams on November 19, 2008, 09:47:45 PM

Quote from: Kenneth Carter on November 19, 2008, 09:39:58 PM

based on the documentation you mentioned that this should return the number of processors.

so I was expecting it to return '2'. I was surprised to recieve the number '2036182'.

which leads to the question of how that number was picked and why?

Wow, you've got a lot of processors in your system ;-)

This function uses the

Code: [Select]

GetSystemInfo Windows API call, which supposedly cannot fail. On my dual-core machines it returns "2". What system are you running on?

Title: Re: thread::hardware_concurrency static Member Function
Post by: Kenneth Carter on November 19, 2008, 10:44:34 PM

amd x2 processor with 4 GB of memory running on vista ultimate x64

the below code I have found is far more accurate on my system. it uses the GetNativeSystemInfo found in the kernel32.dll  and returns 2 for the dwNumberOfProcessors everytime. to be honest based on the code below I have never ran GetSystemInfo on my computer because GetNativeSystemInfo has been successfull every time I have ran this code.


typedef void (WINAPI *PGNSI)(LPSYSTEM_INFO);



ZeroMemory( &SysInfo, sizeof( SYSTEM_INFO ) );
           
PGNSI pGNSI;
           
pGNSI = (PGNSI)GetProcAddress(GetModuleHandle(TEXT("kernel32.dll")), "GetNativeSystemInfo");
           
if( pGNSI != NULL )
{
     pGNSI( &SysInfo );
} else GetSystemInfo( &SysInfo );

Title: Re: thread::hardware_concurrency static Member Function
Post by: Anthony Williams on November 19, 2008, 10:55:59 PM

Quote from: Kenneth Carter on November 19, 2008, 10:44:34 PM

amd x2 processor with 4 GB of memory running on vista ultimate x64

the below code I have found is far more accurate on my system. it uses the GetNativeSystemInfo found in the kernel32.dll  and returns 2 for the dwNumberOfProcessors everytime. to be honest based on the code below I have never ran GetSystemInfo on my computer because GetNativeSystemInfo has been successfull every time I have ran this code.

Aha. GetSystemInfo is documented to return incorrect information under WOW64, which you get with a 32-bit app on a 64-bit OS.

I bet that's the problem with the deadlock check stack tracing too --- WOW64 is messing up the stack tracer. I'll see what I can do.

Thanks.

Title: Re: thread::hardware_concurrency static Member Function
Post by: Kenneth Carter on November 21, 2008, 09:07:14 PM

Anthony,

I just installed .4 beta and this situation has not been resolved yet. I would suggest the GetNativeSystemInfo function found in the kernel32.dll. when I use this in place of hardware_concurrency I am getting accurate count of processor cores.

Kenneth

Title: Re: thread::hardware_concurrency static Member Function
Post by: Anthony Williams on November 21, 2008, 10:45:06 PM

Quote from: Kenneth Carter on November 21, 2008, 09:07:14 PM

I just installed .4 beta and this situation has not been resolved yet. I would suggest the GetNativeSystemInfo function found in the kernel32.dll. when I use this in place of hardware_concurrency I am getting accurate count of processor cores.

Hmm. 0.4 beta is supposed to use that. It returns the correct answer on my XP x64 installation. Thanks for the heads up. I'll investigate next week.

Title: Re: thread::hardware_concurrency static Member Function
Post by: Kenneth Carter on November 28, 2008, 07:02:05 PM

issue resolved in build 0.5 v

Kenneth