10

Just out of curiosity I would like to know how many processor cores the .NET task scheduler supports.

Windows Server 2012 supports up to 640 cores. Was (is) .NET limited to 64 or would it use all available cores?

svick
  • 236,525
  • 50
  • 385
  • 514
Peter Meinl
  • 2,566
  • 25
  • 39

3 Answers3

10

.NET does support all cores. Answer from Stehphen Toub in the MSDN Parallel Extensions Forum:

The default TPL TaskScheduler targets the .NET ThreadPool. By default, the pool is restricted to a single processor group, and thus to 64 cores. However, in .NET 4.5 you can set the <Thread_UseAllCpuGroups enabled="true"/> flag. When your computer has multiple CPU groups, enabling this element causes the runtime to distribute managed threads across all CPU groups rather than being limited to just one, and thus the default scheduler can target whatever the OS supports. (GCCpuGroup must also be enabled for this setting to take effect.)

svick
  • 236,525
  • 50
  • 385
  • 514
Peter Meinl
  • 2,566
  • 25
  • 39
  • 1
    `` does not work for us on a 2s/16c/32T machine with .net 4.6.2 on Server 2016. (yes, we did the whole setup: ``) – mbx May 05 '17 at 08:29
3

By Eric Lippert (source)

For Beta 1 of CLR 4.0, the default scheduler for TPL will be the CLR thread pool

This roughly means that the work comes into a FIFO queue and each core dequeues a workload item. In other words, now there is no fixed upper boundary for the number of cores that CLR threadpool supports. This upper boundary is enforced by other parties - OS, hardware and CPU platform.

The default number of threads in a pool (per this answer)

  • 1023 in Framework 4.0 (32-bit environment)
  • 32768 in Framework 4.0 (64-bit environment)
  • 250 per core in Framework 3.5
  • 25 per core in Framework 2.0

Which technically allows that many parallel executions on dedicated cores.

Note it doesn't mean, that at any given moment of time, there are that many threads in a pool. CLR and OS generally try to slowly decrease the number of threads in a pool to release the resources which are not used.

Community
  • 1
  • 1
oleksii
  • 35,458
  • 16
  • 93
  • 163
2

According to CLR via C#, 3rd ed., chapter 25 Thread Basics:

Today, the CLR […] can only use up to 64 cores when running on 64-bit Windows. [… M]anaged applications can use up to 32 cores when running on a 32-bit version of Windows.

The book was written in 2010, so it contains information relevant to .Net 4.0 and Windows Server 2008 R2, but I don't think .Net 4.5 changed anything in this regard. EDIT: It seems .Net 4.5 did actually change this, see Peter Meinl's answer quoting Stephen Toub.

svick
  • 236,525
  • 50
  • 385
  • 514
  • I asked my question after reading the book you mention wondering if things might have changed with .NET 4.5. It looks strange to me that an important framework like .NET does not allow to use the full number of cores the OS supports. – Peter Meinl Sep 17 '12 at 10:22
  • I think that servers with more than 64 cores are still very rare and if you have one, you probably care about performance a lot, so you're not likely to use .Net. Because of that, I think supporting more cores wasn't a priority. – svick Sep 17 '12 at 10:44
  • A mainboard with 32 cores and 32 GB costs less than 2500€. Maybe there is a rationale behind not supporting more than 64 cores in .NET that I am not aware of. I just started playing with TPL and try to get a feeling for things. – Peter Meinl Sep 17 '12 at 21:49
  • Stephen Toub writes in "Paterns of parallel Programming": Starting with Windows 7 and Windows Server 2008 R2, the Windows operating system supports greater than 64 logical processors, and by default (largely for legacy application reasons), access to these cores is exposed to applications through a new concept known as “processor groups.” The .NET Framework does not provide managed access to the processor group APIs, and thus Environment.ProcessorCount will return a value capped at 64 (the maximum size of a processor group), even if the machine has a larger number of processors. – Peter Meinl Sep 18 '12 at 05:27
  • @PeterMeinl Yeah, that's pretty much what the parts I left out from my quote say. I thought it wasn't relevant here, so I didn't include them. – svick Sep 18 '12 at 08:43