5

Seems like NUMA is promising for parallel programming, and if I am not wrong the current latest cpus have built-in support for it, like the i7.

Do you anticipate the CLR to adapt NUMA soon?

EDIT: By this I mean having support for it, and taking advantage of it.

Joan Venge
  • 315,713
  • 212
  • 479
  • 689

4 Answers4

2

NUMA is a hardware architecture, not necessarily something that needs adoption in the CLR directly. For details, see the NUMA FAQ.

That being said, there are advantages to making software aware of it's architecture. The folks on the CLR team do seem to be aware of issues with cache coherency, etc, so I would bet that there are some optimizations for this. Also, the design of the scheduler in the task parallel library in C# 4 seems to be promising for taking better advantages of NUMA architectures.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • Do you have any references for "do seem to be aware of issues with cache coherency" and "design of the scheduler... promising..."? I would love to read more. – Eric J. Feb 25 '12 at 01:29
  • FYI: "Cache coherency" is not a software problem. That has been solved by Intel and AMD, because mainstream NUMAs are all ccNUMAs (cache coherent NUMAs). What software has to solve however is where to allocate memory, for which thread / process, depending on which cores / cpu(s) it runs on (affinity). – Evgeniy Berezovsky May 26 '15 at 02:35
1

In a sense, NUMA is orthogonal to the CLR's memory model. In other words, the hardware/OS has its method of access, the CLR has its memory model demands, and it is up to the CLR implementer to make the to play nice together. In practice, this is difficult, and there are flaws in the current implementation. But as the CLR already runs on hardware supporting NUMA, I'm not really sure what you mean by "adapt NUMA soon.?

Craig Stuntz
  • 125,891
  • 12
  • 252
  • 273
  • 1
    As far as I know, CLR uses the same first-touch memory allocation strategy that the underlying OS uses. The first thread to touch a virtual page gets it mapped (by the OS I think, not the CLR) into the NUMA node corresponding to the CPU the thread happens to be on. Chances are very good that a thread on a different CPU will use that same memory (which is now on a bad NUMA node) later during the lifetime of the app. – Eric J. Feb 25 '12 at 01:31
1

All the answers here so far are correct in highlighting NUMA as a hardware architecture. An interesting read would be this article by Joe Duffy on concurrency and the CLR.

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
1

With NUMA basically you have per processor memory controller. You have that with Intel QuickPath and with AMD HyperTransport. The thing is, as far as I know, currently there are no motherboards neither for i7, nor for Phenom, that would support more than one CPU.

Anyway, this is very low level, that has nothing to do with CLR. It's up to operating system to take advantage of it.

vartec
  • 131,205
  • 36
  • 218
  • 244
  • 1
    That's not true. It's up to the heap manager (or in this case CLR memory manager) to be NUMA aware, or not. The OS will probably never have enough information to make better decisions than the current first-touch strategy that Windows and Linux use. See http://stackoverflow.com/questions/9439402/array-memory-management – Eric J. Feb 25 '12 at 01:32