Wie viele CPUs erforderlich sind, bevor Erlang ist schneller als single-threaded Java

Question

Ich bin derzeit mit Java, ich habe viel über Erlang auf dem Netz lesen, und ich habe 2 große Fragen:

1. Wie viel langsamer (wenn überhaupt) wird Erlang über einfaches Java sein?
   Ich gehe davon aus, dass hier Java geht schneller sein von den shootout benchmarks auf dem Netz (Erlang tut nicht so gut). Also, wie viele CPUs brauche ich, um Erlang über single-threaded Java (in meiner speziellen Situation, unten angegeben) glänzen zu lassen?

2. Nachdem ich eine Weile über Erlang gelesen habe, habe ich eine Reihe von Kommentaren gelesen, die sagen, dass die meisten großen Erlang-Systeme eine gute Menge an C/C++ enthalten.
   Ist das aus Geschwindigkeitsgründen (meine Annahme) oder etwas anderes? Warum ist das erforderlich?

Ich habe über die Anzahl der Prozessoren in den meisten Maschinen lese nach oben und Modellen Einfädeln hart zu sein (ich stimme), aber ich bin auf der Suche, um herauszufinden, wenn die „Linie“ überquert werden soll, so dass ich kann ändere Sprache/Paradigma zur richtigen Zeit.

Ein bisschen Hintergrund/Kontext:
Ich arbeite serverseitige Java auf Dienste, die sehr CPU-gebunden sind und leicht gemacht parallel. Dies liegt typischerweise an einer einzigen eingehenden Aktualisierung (über TCP), die eine Änderung an mehreren (100s von) Ausgängen auslöst.

Die Berechnungen sind in der Regel recht einfach (paar Schleifen, nur viel Arithmetik) und die Eingänge in ziemlich schnell (100/s) kommen.

Gegenwärtig laufen wir auf 4 CPU-Rechnern und führen mehrere Dienste auf jedem aus (daher ist Multithreading ziemlich sinnlos und Java scheint schneller zu laufen, ohne dass die Synchronisationsblöcke usw. erforderlich sind, um es multi-threaded zu machen). Es gibt jetzt einen starken Drang nach Geschwindigkeit und wir haben jetzt Zugriff auf 24 Prozessor-Maschinen (pro Prozess, falls erforderlich), also frage ich mich, wie es am besten weitergeht - massiv Multithreading-Java oder etwas einfacher zu programmieren wie Erlang.

Answer 1

da dies eine arithmetische hohe Arbeitsbelastung und Sie haben bereits die Arbeit der Aufspaltung aus dem Code in separate Service-Prozesse getan, würden Sie nicht viel von Erlang gewinnen. Ihre Aufgabe scheint Java zu entsprechen. Erlang ist gut bei kleinen Transaktionen - wie zum Beispiel das Wechseln von Nachrichten oder das Bereitstellen von statischen oder einfach-dynamischen Webseiten. Nicht - bei der Zahlenverarbeitung oder der Datenbankauslastung.

Sie können jedoch auf externen numerischen Bibliotheken und Datenbanken aufzubauen und Erlang als Schalter MSG verwenden: D das ist, was Couch-DB wird: P

- bearbeiten -

1. Wenn Sie Verschieben Sie Ihre arithmetischen Operationen in einen Erlang Async-IO-Treiber. Erlang wird genauso gut sein wie das Sprach-Shoot-Out-Zeug - aber mit 24 CPUs ist es vielleicht nicht so wichtig; Die Erlang-Datenbank ist prozedural und daher ziemlich schnell - dies kann in Ihrer Anwendung ausgenutzt werden, indem 100 Entitäten bei jeder Transaktion aktualisiert werden.

2. Das Erlang-Laufzeitsystem muss eine Mischung aus C und C++ sein, weil (a) der Erlang-Emulator in C/C++ geschrieben ist (Sie müssen irgendwo anfangen), (b) müssen Sie mit dem Kernel sprechen Machen Sie Async-Datei io und Netzwerk io, und (c) bestimmte Teile des Systems müssen blendend schnell sein - zB das Backend des Datenbanksystems (Amnesie).

- Diskussion -

mit 24 CPUs in einer 6-Kern * 4 CPU-Topologie eines Shared-Memory-Bus mit - Sie 4 NUMA Entitäten (die CPUs) und einen zentralen Speicher. Sie müssen über das Paradigma weise sein, der Shared-Nothing-Multi-Prozess-Ansatz könnte Ihren Speicherbus zerstören.

Um dies zu umgehen, müssen Sie 4 Prozesse mit 6 Verarbeitungsthreads erstellen und jeden Verarbeitungsthread den entsprechenden Kern in der entsprechenden CPU binden. Diese 6 Threads müssen kollaboratives Multithreading durchführen - Erlang und Lua haben das von Haus aus - Erlang macht es auf eine harte Kern-Art, da es einen vollwertigen Scheduler als Teil seiner Laufzeit hat, den es verwenden kann, um so viele zu erstellen Prozesse wie Sie wollen.

Wenn Sie nun Ihre Aufgaben auf die 4 Prozesse verteilen (1 pro CPU), wären Sie ein glücklicher Mann, aber Sie haben 4 Java VMs ausgeführt (vermutlich) ernsthafte Arbeit (yuck, aus vielen Gründen). Das Problem muss mit einer besseren Fähigkeit gelöst werden, das Problem zu lösen.

In dem Erlang OTP-System, das für redundante, robuste vernetzte Systeme entworfen wurde, bewegt es sich jetzt hin zu NUMA-ähnlichen CPUs der gleichen Maschine. Es hat bereits einen Kick-Ass SMP-Emulator, und es wird bald auch NUMA bewusst sein. Mit diesem Paradigma der Programmierung haben Sie eine viel bessere Chance, Ihre leistungsfähigen Server zu sättigen, ohne Ihren Bus zu töten.

Vielleicht war diese Diskussion theoretisch; Wenn Sie jedoch eine 8x8- oder 16x8-Topologie erhalten, sind Sie auch dafür bereit. Also meine Antwort ist, wenn Sie mehr als 2 - moderne - physische CPUs auf Ihrem Mainboard haben, sollten Sie wahrscheinlich ein besseres Programmierparadigma in Betracht ziehen.

Als Beispiel für ein wichtiges Produkt im Anschluss an die Diskussion hier: Microsoft's SQL Server is CPU-Level NUMA-aware in the SQL-OS layer, auf dem die Datenbank-Engine gebaut wird.

Answer 2

Haben Sie die Kosten für neue Hardware im Vergleich zu den Kosten der Umschulung Mitarbeiter in Erlang und Wieder Architecting Ihre Software in einer neuen Sprache verglichen?

Ich würde die Kosten der Umschulung selbst (oder andere) und die Kosten für die Einstellung von Mitarbeitern bewandert in Erlang nicht unterschätzen (der ein viel härter sein werden zu finden, als Java Personen). Server kosten offensichtlich ihre Speicherkosten/Strom/Wartung etc., aber sie sind immer noch viel billiger als qualifiziertes Personal. Wenn Sie Fortschritte machen können und skalierbar bleiben, während Sie Ihre aktuellen Fähigkeiten einsetzen, dann ist dies meines Erachtens der pragmatischste Ansatz.

Answer 3

Wenn Sie 100 pro Sekunde bekommen, aber sie nehmen jeweils 100s wie kann es mithalten? Vielleicht irre ich diesen Teil, aber außer es sind Tausende oder Millionen von Anfragen pro Sekunde sollte der Synchronisationscode nicht lange dauern. Wenn dies der Fall ist, tun Sie etwas falsch, möglicherweise sperren Sie, während Sie den gesamten Job oder etwas ausführen.

Bei Multithread-Code ist es wahrscheinlich ein Fehler, zu einer höheren Ebene zu wechseln. Selbst wenn Sie den Anwendungsteil in erlang schreiben oder was auch immer das Multithreading in Java sein sollte, oder nach C++ wechseln, wenn die Performance wirklich zum Problem wird.

Answer 4

Die Frage der Geschwindigkeit, wenn es um Programmiersprachen geht, ist so komplex, wie eine Frage bekommen kann. Java-Befürworter können auf viele Bereiche verweisen und behaupten, sie seien am schnellsten und sie wären zu 100% korrekt. Ruby/Python-Befürworter verweisen auf einen anderen Satz von Parametern und behaupten, schneller zu sein, und sie wären auch korrekt. Erlangs Befürworter weisen dann auf gleichzeitige Verbindungen hin und behaupten, dass sie am schnellsten sind, wenn sie mit Hunderten oder Tausenden von gleichzeitigen Verbindungen oder Berechnungen arbeiten, und das wäre auch nicht falsch.

Betrachtet man die grundlegende Beschreibung des fraglichen Projekts, scheint mir, dass Erlang perfekt zu Ihren Bedürfnissen passt. Ohne die Details zu kennen, würde ich sagen, dass dies ein ziemlich verflixtes einfaches Erlang-Programm wäre und in sehr kurzer Zeit erledigt werden könnte.

Answer 5

Es hängt von mehreren Faktoren ab. Die schnelle Antwort ist, dass Sie jedes unterschiedliche Programm benchmarken müssen, um zu verstehen, wo dieses Ruhewasserzeichen ist.

Hier sind einige der relevanten Aspekte, die dieses Nutzen-Verhältnis auswirken könnten:

1) Computational Abhängigkeiten: wenn der logische Fluss viele Abhängigkeiten zu externen Ressourcen (DBMS, Festplattenzugriff, Vernetzung) hat. Je höher die Menge an Rechenabhängigkeiten ist, die bei der gleichzeitigen Verarbeitung teilbar sind, desto höher ist der Vorteil der Verwendung einer verteilten Berechnungsplattform wie Erlang.

2) Logische Flussatomizität: Wenn Ihr Programm eine große Menge an Rechenzeit für eine einzelne sequentielle synchrone Flusssteuerung ausgeben muss und diese nicht in kleinere logische Codeabschnitte zerlegt werden kann. Je größer die Atomizität Ihres Codes ist, desto weniger kann er in CPU-Streuungsflüsse aufgeteilt werden.

3) Statusfreigabe Overhead: Je größer die Menge an Daten ist, die über verschiedene Funktionen verteilt werden muss, desto höher ist der Aufwand, den das Framework benötigt, um den Status einfach zu übertragen und zu empfangen. Mit anderen Worten, wenn Sie große Datenmengen wiederholt ohne einen gemeinsamen gemeinsamen Cache-Bereich senden, werden die Vorteile abnehmen, obwohl dies abhängig von den verwendeten Programmiermustern unterschiedliche Ansätze hat.

Daher ist es angesichts der großen Möglichkeiten und Variationen, die auf Kriterien wie dem oben genannten basieren, nicht möglich, eine gemeinsame Schätzung zu haben, die für alle Szenarien akzeptabel ist.