Heap-Zuweisung und geeignete Hardware

Question

Für eine C# .net 3.5-Anwendung, die unvermeidlich eine Menge Daten auf dem Heap erstellt, in Bezug auf die Hardware was würde ich in Bezug auf Speicher suchen? Wäre es nur die größte Sockelbusbreite? Oder die "Bandbreite" der Memory Sticks? Oder die tatsächliche Frequenz, auf der sie laufen?

Wir haben den Schluss gezogen, dass der Engpass unserer Anwendung nicht vermieden werden kann und wenn wir die Arbeit über mehrere Threads verteilen, scheinen wir "Kollisionen" zu bekommen, weil viele Threads auf den RAM zugreifen.

Das eigentliche Problem bezieht sich auf das Sperren von Elementen und viele Threads, die versuchen, auf diese Elemente zuzugreifen. Es gibt keine Möglichkeit, das Threading-Locking weiter zu optimieren. Da es sich um Threading handelt, war ich nicht sicher, ob ich auch alternative CPU-Optionen untersuchen sollte und auch die QPI-Statistiken genau betrachten sollte. Wir verwenden derzeit die Westmere-Architektur, aber eine langsame Taktrate von 2 GHz.

EDIT: Wurde vorgeschlagen, DMA ist, was uns helfen könnte.

Ich werde dies als C# und Java markieren, weil ich glaube, dass die Antwort nicht C# -spezifisch sein wird.

Vielen Dank im Voraus,

Answer 1

ich die Anwendung auf eine schnellere Maschine testen würde. Von den Geräuschen her ist deine Speicherbandbreite der Flaschenhals, also würde ich einen 4,5 GHz getakteten i7 mit 32 GByte 1600 MHz Speicher oder ähnlichem ausprobieren. Sie können einen für ungefähr $ 1000 kaufen. Sie werden feststellen, dass sich Ihr Flaschenhals mit einem viel schnelleren System bewegt.

BTW: Ich bezweifle, dass die Erstellung von Objekten in C# vermeidbar ist, obwohl es möglicherweise nicht erreichbar ist, da es so klingt, als hätte man nur begrenzte Zeit, um dies zu beheben. In Java habe ich eine Reihe von Hochleistungs-Servern geschrieben, die weniger als einmal pro Tag GCes, aber Sie müssen den gesamten Kern-Code mit Ziel schreiben. Genauso können Sie einen Dienst schreiben, der keine kritischen Abschnitte des Codes sperrt, aber es ist kein Trival, um dies später hinzuzufügen.