Ich habe vor einiger Zeit einen Blog-Post gelesen, in dem behauptet wird, dass eine Java-Anwendung besser lief, als eine einzelne CPU in einem Multicore-Rechner verwendet werden durfte: Ссылка
Welche Gründe könnte es für eine Java-Anwendung geben, die auf Multicore-Rechnern läuft, die viel langsamer laufen als auf einem einzelnen Kernrechner?
Wenn es unter den freigegebenen Ressourcen in den verschiedenen Threads zu erheblichen Konflikten kommt, könnte das Sperren und Entsperren von Objekten eine große Menge von IPI (Interprozessor-Interrupts) und die Prozessoren verbringen möglicherweise mehr Zeit damit, ihre L1- und L2-Caches zu verwerfen und Daten von anderen CPUs erneut abzurufen, als sie tatsächlich damit verbringen, Fortschritte bei der Lösung des Problems zu machen.
Dies kann ein Problem sein, wenn die Anwendung zu zu fein abgestuftes Sperren verfügt. (Ich habe es einmal summiert "es hat keinen Sinn, mehr als eine Sperre pro CPU-Cache-Zeile zu haben", was definitiv stimmt, und vielleicht noch zu feinkörnig.)
Javas "jedes Objekt ist ein Mutex" könnte dazu führen, dass zu viele Sperren im laufenden System vorhanden sind, wenn zu viele live sind und umstritten sind.
Ich habe keinen Zweifel, dass jemand absichtlich eine solche Anwendung schreiben könnte, aber es ist wahrscheinlich nicht sehr häufig. Die meisten Entwickler würden ihre Anwendungen schreiben, um Ressourcenkonflikte dort zu reduzieren, wo sie können.
Ich bezweifle den "Much" -Teil.
Meine Vermutung wäre, dass die Kosten für das Verschieben des Zustands von einer CPU in eine andere hoch genug sind, um bemerkbar zu sein. Im Allgemeinen möchten Sie, dass Jobs auf der gleichen CPU bleiben, so dass ihre Daten so oft wie möglich lokal zwischengespeichert werden.
Dies ist reine Spekulation ohne den fraglichen Artikel / die fraglichen Daten, aber es gibt einige Arten von Programmen, die nicht gut für die Parallelisierung geeignet sind - vielleicht ist die Anwendung niemals CPU-gebunden (dh die CPU ist nicht der Flaschenhals, vielleicht eine Sorte) von I / O ist).
Allerdings ist diese Frage / Konversation ohne weitere Details ziemlich unbegründet.
Es gibt keinen Java-spezifischen Grund dafür, aber das Verschieben des Status von Core zu Core oder sogar von CPU zu CPU braucht Zeit. Diese Zeit kann besser genutzt werden, wenn der Prozess auf einem einzelnen Kern bleibt. Auch das Caching kann in solchen Fällen verbessert werden.
Dies ist jedoch nur relevant, wenn das Programm nicht mehrere Threads verwendet und somit seine Arbeit effektiv auf mehrere Cores / CPUs verteilen kann.
Die Anwendung könnte blockierende Inter-Thread-Kommunikation sehr schlecht nutzen. Dies liegt jedoch ausschließlich an der Tatsache, dass die Anwendung außergewöhnlich schlecht programmiert ist.
Es gibt keinen Grund, warum selbst mittelmäßig programmierte Multi-Core-Anwendungen mit einer leicht parallelisierbaren Arbeitslast auf mehreren Kernen langsamer laufen sollten.
Aus einer reinen Performance-Perspektive besteht die Herausforderung oft im Speicher-Subsystem. Während also mehr CPUs oft gut sind, sind CPUs, die nicht in der Nähe des Speichers sind, in dem die Java-Objekte sitzen, sehr, sehr teuer. Es ist sehr maschinenspezifisch und hängt stark vom genauen Pfad zwischen jeder CPU und dem Speicher ab. Sowohl Intel als auch AMD haben hier verschiedene Formen / Geschwindigkeiten und die Ergebnisse sind sehr unterschiedlich.
Siehe NUMA aus Gründen, warum Multi-Core dies behindern könnte.
Wir haben Leistungsdeltas im Bereich von 30% oder mehr gesehen, abhängig davon, wie JVMs an Prozessoren angeheftet sind. SPECjbb2005 wird jetzt meistens im "Multi-JVM" -Modus ausgeführt, wobei jede JVM aus diesem Grund einer bestimmten CPU / Speicher zugeordnet ist.
Das JIT wird keine Speicherbarrieren enthalten, wenn es denkt, es läuft in einem einzigen Kern. Ich vermute, dass das in dem referenzierten Artikel passiert.
Hier ist eine sehr kurze Erklärung von Speicherbarrieren, es bietet auch eine saubere Technik, den JIT'd-Code zu sehen: Ссылка
Das soll nicht heißen, dass alle Anwendungen davon profitieren würden, auf einem einzelnen Kern platziert zu werden.
Dies hängt von der Anzahl der Threads ab, die die Anwendung hervorbringt. Wenn Sie etwa vier Worker-Threads spawnen, die viel Zahlen verarbeiten, ist die App auf einem Quad-Core-Rechner fast viermal schneller, je nachdem, wie viel Buchhaltung und Zusammenführung Sie machen müssen.
CPU haben oft eine Grenze, wie viel Wärme sie produzieren können. Dies bedeutet, dass ein Chip mit weniger Kern mit einer hohen Frequenz laufen kann, was dazu führen kann, dass ein Programm schneller läuft, wenn es den zusätzlichen Kern nicht effektiv verwendet. Heute liegt der Unterschied zwischen 4, 6 und 8 Kern, wo mehr Kerne einzeln langsamer sind. Ich kenne keine einzelnen Kernsysteme, die schneller sind als das schnellste 4-Kern-System.
Tags und Links java performance jvm multicore