Isn't it the case that GCC uses pthreads threads as implemented by MinGW? Maybe 
I don't understand the architecture but it seems GCC doesn't have Windows 
specific thread creating functions. It just uses pthreads  and MinGW project 
have Windows specific implementation of specific routines. For example:

int
pthread_create (pthread_t *th, const pthread_attr_t *attr, void *(* func)(void 
*), void *arg)

is in mingw-w64-libraries\winpthreads\src\thread.c

and as long as it uses _beginthreadex it will never be able to use thread on 
another CPU.

Similarly as long as there is this in thread.c in MinGW:

int
pthread_num_processors_np(void) 
{
  int r = 0;
  DWORD_PTR ProcessAffinityMask, SystemAffinityMask;

  if (GetProcessAffinityMask(GetCurrentProcess(), &ProcessAffinityMask, 
&SystemAffinityMask))
    {
      for(; ProcessAffinityMask != 0; ProcessAffinityMask >>= 1)
        r += (ProcessAffinityMask & 1) != 0;
    }
  /* assume at least 1 */
  return r ? r : 1;
}

GCC itself can't do much about finding more CPUs.
GCC implementation of OpenMP is able to use more than 64 logical CPUs just not 
on Windows.

I am new to this. If I could understand the architecture better I might try 
fixing it.


On Sat, Jun 16, 2018, at 9:44 AM, Liu Hao wrote:
> 在 2018/6/16 15:38, [email protected] 写道:
> > Counting CPUs is only one problems. You also need to take into account CPU 
> > groups when creating threads. The linked docs suggest using 
> > CreateRemoteThreadEx instead _beginthreadex. Handling affinity settings 
> > becomes more difficult as well (there is scatter, bind etc.). I've seen 
> > some code for it in Clang OpenMP source, for example:
> >   __kmp_affinity_bind_thread(int proc)
> > 
> > It seems Clang also uses system_affinity (_kmp_get_system_affinity) which 
> > contains affinities for all CPU groups.
> > Unfortunately I am not competent enough to understand how to do it 
> > correctly nor suggest a patch. I have nearly 0 experience in Windows 
> > specific programming.
> > 
> >
> 
> OpenMP is implemented by GCC and consequently out of our control. This 
> change will have to be done in GCC code and submitted to GCC developers. 
> Hopefully someone will be interested in it.
> 
> 
> -- 
> Best regards,
> LH_Mouse
> 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to