Wie wichtig ist NUMA-Konzept z.B. für Simulation?

Der Artikel von heise ist deutlich zu kurz und ungenau. Habe mal gegoogelt und ein wenig mehr darüber gefunden .
Die Auswirkungen verschiedener Speichersysteme hängen stark von den Anwendungen ab. Natürlich gilt: Je Speicherintensiver die Applikation, desto größer der Effekt. Über Ketegorieen wie z.B. Office, Simulation lässt sich keine verallgemeinernde Aussage machen. Zu jeder Architektur (UMA, NUMA, cc-NUMA, distributed Memory, ...) gibt es Algorithmen/Implementierungen die gut oder weniger gut geeignet sind.
Ich verstehe nur nicht ganz, warum heise die Schuld auf das OS schiebt.

heise hatte geschrieben, das 10.6 NUMA nicht unterstützt, die aktuelle Hardware dies aber zulassen würde.

Genau da fehlt mir das Verständnis. In wiefern kann das OS NUMA unterstützen?

Die Hardware muss anscheinend entsprechend direkt angesprochen werden.
Ich hoffe, dass sich hier in diesem Thread Spezialisten einschalten.

NUMA heißt vereinfacht ausgedrückt, dass Programme von dem Wissen sinnvoll Gebrauch machen können, dass die einzelnen Prozessorkerne in bestimmten Situationen mit verschiedenen Geschwindigkeiten auf den RAM-Speicher zugreifen. Ein "lokal" dem Speicherbus des aktuellen Prozessors zugeordneter Speicher reagiert schneller als ein "ferner" Speicher, den ein anderer Prozessor gerade in Benutzung hat.

Voraussetzung dafür ist, dass (a) ein Programm irgendwie herauskriegen kann, auf welchem Prozessor sein Thread gerade läuft und (b), dass ein Programm einen Thread auf einem bestimmten Prozessor festhalten darf, also verhindert, dass der Thread in der nächsten Prozessvergabezeitscheibe vom System auf einen anderen Prozessor platziert wird (Das nennt man Prozessoraffinität.)

Beide Funktionen stehen in Mac OS X nicht zur Verfügung, bzw. werden vom Betriebssystemkern sogar absichtlich gesperrt.

Apple steht auf dem Standpunkt, dass ein Programm nicht wissen soll, wie es auf die Prozessoren platziert wird, "da das Betriebssystem das selbst am besten kann". Aufgrund der besonderen Speichertechnik der Nehalem-Prozessoren stimmt das nur leider für den aktuellen Mac Pro und den Xserve nicht.

Wichtig sind solche Techniken allerdings nur für das parallele Programmieren im technisch-wissenschaftlichen Bereich.

Dass Apple das absichtlich (und in meinen Augen unintuitiv) so handhabt, wusste ich nicht.

Das ist doch totaler Unsinn. Einzelne Programme haben damit überhaupt nichts zu tun

NUMA zu berücksichtigen ist Aufgabe des Betriebssystems. Moderne Scheduler berücksichtigen z.B. auch Hyper-Threading. Ohne expliziten Support dafür ist das System halt u.U. etwas langsamer.

Was müsste das OS noch machen? Speicher, den ein thread anfordert, in ein und demselben Speicherbereich reservieren?

Bei NUMA-fähigen Systemen spielen Policies bei der Allokierung von Speicher eine große Rolle. Man kann oft auch für verschiedene Prozesse verschiedene Policies auswählen.

Natürlich gibt es oft auch APIs, mit denen man Applikationen auf NUMA "zuschneiden" kann. Ich habe den Beitrag von Marcel vermutlich anders aufgefasst, als er es meinte. Um NUMA zu berücksichtigen muss das Betriebssystem zwingend darauf vorbereitet sein, das ist keine Sache, die sich ausschließlich in den Programmen abspielt. Vermutlich wollte er das aber gar nicht andeuten, von daher ziehe ich meine Kritik zurück.

Hier noch eine Beschreibung zum Stand des Linux-Kernel bzgl. NUMA, sowie der entsprechenden Tools um z.B. Policies zu setzen: http://www.ice.gelato.org/apr07/pres_pdf/gelato_ICE07apr_numapolicy_schermerhorn_hp.pdf (ist von 2007, aber größtenteils noch aktuell, schätze ich).

Wahrscheinlich sollte es allgemeiner Anweisung oder Prozess heißen statt Programm.