Java-Stream-API: warum die Unterscheidung zwischen sequenzieller und paralleler Ausführung-Modus?
Aus der Stream javadoc:
Stream-Pipeline ausführen können entweder sequentiell oder parallel. Dieser Ausführungsmodus ist eine Eigenschaft des Streams. Streams erstellt werden, mit einer anfänglichen Wahl der sequentielle oder parallele Ausführung.
Meine Annahmen:
- Es gibt keinen funktionalen Unterschied zwischen einer sequentiellen/parallelen streams. Ausgang ist nie betroffen Ausführungsmodus.
- Ein paralleler stream ist immer vorzuziehen, da entsprechende Anzahl von Kernen und problem-Größe rechtfertigen den Aufwand, aufgrund der performance-Gewinne.
- Wir wollen den code einmal schreiben und überall ausführen, ohne sich um die hardware (das ist Java, nachdem alle).
Wenn diese Annahmen gültig sind (nichts falsch mit ein wenig meta-Annahme), was ist der Wert, mit den Ausführungs-Modus ausgesetzt, die in der api?
Es scheint, wie Sie sollte einfach in der Lage sein, zu erklären Stream
, und die Wahl der sequentielle/parallele Ausführung behandelt werden sollten, automatisch in einer Ebene unterhalb, entweder durch den Bibliotheks-code oder der JVM selbst als eine Funktion der verfügbaren Kerne zur Laufzeit die Größe des Problems, etc.
Sicher, unter der Annahme paralleler streams funktionieren auch auf einem single-core-Maschine, vielleicht auch nur immer mit einem parallelen stream erreicht dies. Aber das ist wirklich hässlich - warum haben explizite Verweise auf parallele streams in meinem code, wenn es die Standard-option?
Selbst wenn es ein Szenario, wo würden Sie wollen bewusst zu codieren, die Verwendung von eine fortlaufende stream - warum gibt es nicht einfach eine sub-Schnittstelle SequentialStream
für diesen Zweck, anstatt umweltschädliche Stream
mit einem execution-wächtermodus?
- Was ist, wenn Ihr den code nicht thread-safe?
- Hmm, guter Punkt - aber ist das nicht eher die Ausnahme als den Allgemeinen Fall? Wenn Sie die Programmierung funktional Ihr code sollte thread-sicher. Wenn Sie nicht sind, warum sind Sie mit streams und lambdas in den ersten Platz?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Die Realität ist, dass a) die streams sind eine Bibliothek, und haben keine Besondere JVM-Magie, und b) kann man nicht wirklich design eine Bibliothek intelligent genug, um automatisch herauszufinden, was die richtige Entscheidung ist in diesem speziellen Fall. Es gibt keine vernünftige Art und Weise zu schätzen, wie teuer eine bestimmte Funktion, ohne es auszuführen-selbst, wenn Sie könnten, überprüft deren Umsetzung, die Sie nicht können -- und jetzt Sie sind die Einführung einer benchmark in jedem stream, operation, versuchen, herauszufinden, ob die Parallelisierung wird es sich lohnen, die Kosten der Parallelität overhead. Das ist einfach nicht praktikabel, vor allem da Sie nicht im Voraus wissen, wie schlimm die Parallelität Aufwand ist, entweder.
Nicht immer in der Praxis. Einige Aufgaben sind einfach so klein, dass Sie sich nicht lohnt, zu parallelisieren, und Parallelität bedeutet immer ein gewisser Aufwand. (Und ehrlich gesagt, die meisten Programmierer überschätzen den nutzen von Parallelität, klatscht es überall, wenn es wirklich verletzen Leistung.)
Grundsätzlich, es ist schwer genug problem, dass Sie im Grunde haben um es zu schieben aus auf die Programmierer.
Gibt es einen interessanten Fall in diese Frage zeigen, dass teilweise parallel streamen könnte langsamer sein in Größenordnungen. In diesem spezifischen Beispiel parallele version läuft für zehn Minuten, während sequentielle dauert mehrere Sekunden.
Gibt es einen Unterschied zwischen sequentiellen/parallelen streams Ausführung.
In den untenstehenden code
TEST_2
Ergebnisse zeigt, dass die parallele Ausführung des Threads ist sehr viel schneller als die sequentielle Art und Weise.Nicht wirklich. wenn die Aufgabe nicht würdig(simple tasks), die parallel ausgeführt werden threads, dann ist es ganz einfach wir sind das hinzufügen overhead, um unseren code.
TEST_1
Ergebnisse zeigt dies. Beachten Sie auch, dass, wenn alle worker-threads sind damit beschäftigt, auf einer parallele Ausführung von tasks; dann andere parallele stream-Betrieb an anderer Stelle in Ihrem code auf diese zu warten.Da nur der Programmierer weiß, ist es würdig, diese Aufgabe auszuführen, parallel/sequentiell unabhängig von der CPU. Also java-API ausgesetzt, die sowohl die option für die Entwickler.
Hinzufügen zu den bereits gegebenen Antworten:
Das ist eine ziemlich gewagte Annahme. Stellen Sie sich die Simulation einer board-Spiel für die Ausbildung irgendeine form von KI, ist Recht einfach zu parallelisieren, die die Ausführung von unterschiedlichen playthroughs - einfach eine neue Instanz erstellen, und lassen Sie es laufen, auf seinen eigenen thread. Als es nicht teilen, jeder Staat mit einem anderen durchspielen, die Sie gar nicht haben, zu überlegen, multi-threading Probleme in Ihrem Spiel-Logik. Wenn Sie auf der anderen Seite parallelisieren, die Spiel-Logik selbst bekommen Sie alle Arten von multi-threading Probleme und die meisten wahrscheinlich zahlen einen hohen Preis für die Komplexität und auch die Leistung.
Durch die Kontrolle über das Verhalten der Bäche gibt, die Sie (entsprechend begrenzt) Flexibilität, die in und von sich selbst ist ein zentrales Merkmal für gute Bibliothek entwerfen.