Threads & Mehrprozessor/Doppelkern-Systeme

[martin_d]

Ich arbeite gerade an einer Programmieraufgabe für die Uni, eine Simulationsumgebung für eingebettete Systeme. Da bei der Simulation einige Berechnungen anfallen werden, habe ich mir gerade Gedanken gemacht, wie und ob Threads in Java Einfluss auf die Performance haben.

Wenn ich in C programmiere kann ich ja z.B. mit pthreads meine Berechnungen in Threads kapseln und kann...
1. annehmen, dass die auf 2 oder mehr Prozessoren verteilt werden.
2. annehmen, dass durch das Scheduling des OS mehr Prozessorzeit für die Berechnungen spendiert wird, als wenn ich das ganze sequenziell in einem Thread mache.

Aber wie sieht das in Java aus? Da gibt es ja die VM. Sieht das OS die VM als einen Thread oder sind die programmierten Threads innerhalb der VM für das OS transparent?

Gruß, Martin

 

[byte]

Java Threads werden von der VM per Default auf Threads des Betriebssystems gemappt und profitieren somit auch von Mehrprozessorsystemen.

 

[foobar]

BTW Im aktuellen Linux Magazin gibts mehrere Artikel zum Thema Threading und Mulitcores. Ich fands sehr interessant

http://www.linux-magazin.de/

 

[Guest]

Java Threads werden von der VM per Default auf Threads des Betriebssystems gemappt und profitieren somit auch von Mehrprozessorsystemen.

Hast du da zufällig eine Quelle für, würde das gerne belegen können.

 

[Wildcard]

In früheren Versionen von Java wurden reine Java Threads, sogenannte 'Green Threads' verwendet.
Das ist auch heute noch möglich, aus Gründen der Performance wird jedoch per default auf native Threads gemapped.
Zur genauern Lektüre ist SUN selbst die beste Quelle:
http://java.sun.com/docs/hotspot/threads/threads.html

 

[@deprecated]

lol, ich glaube ich arbeite gerade an genau der gleichen simulationsumgebung, und würde die frage gerne erweitern:

meine simulation muss eine bestimmte anzahl nebenläufiger aufgaben abarbeiten, die von der eingabe abhängig ist, sprich: ich habe keinen einfluss auf die anzahl der aufgaben. das einzige was mich interssiert, ist dass alle aufgaben möglichst schnell abgearbeitet werden.
daher meine frage: bewirken threads auch auf ein-kern-prozessoren einen performancegewinn? oder hemmen sie dort die performance eher, da die VM ja sozusagen zwischen ihnen wechseln muss?
etwas allgemeiner gesprochen ist meine frage: bringt es einen performancegewinn, mehr threads zu starten, als prozessoren zur verfügung stehen? oder sollte ich lieber nur so viele threads starten, wie ich prozessoren habe? mich interssiert wie gesagt nur, dass alle threads möglichst schnell beendet werden...

Danke für Antworten im Voraus!

 

[AlArenal]

Wenn man Performance objektiv bewerten möchte, kann man sich die Frage doch ganz einfach selbst beantworten. Wie soll etwas schneller werden, wenn bei gleichen Ressourcen mehr abverlangt wird?

 

[Guest]

ok, du meinst also: am besten nur ein thread pro prozessor, hab ich dich richtig verstanden?

ich dachte, dass vielleicht für jeden thread der existiert, eigene ressourcen zugeteilt werden, so dass die ganze anwendung je mehr threads sie startet umso mehr ressourcen benutzen kann... das war aber nur eine vermutung.

 

[ice-breaker]

Da der Prozessor immer nur einem Prozess gleichzeitig Rechenzeit zusprechen kann, wird es wohl nocht besonders positiv sein, mehr Threads in diesem Prozess zu startet, also Performance kann man da nicht mehr verbessern, aber der Verlust den man bei mehreren Threads hat, ist minimal.

 

[madboy]

Ich würde sagen, das kommt auf die Threads/Prozesse an. Wenn nur die CPU belegt wird, wird es wohl performanter sein, nur einen Thread/Prozess zu haben. So bald aber noch I/O dazukommt, werden mehrere Threads performanter sein.

 

[Ark]

Wenn alle Threads aller Prozesse die gleiche Priorität haben und 50% aller Threads einem einzigen Prozess gehören, dann gehört diesem Prozess auch 50% der CPU-Zeit (einfach gerechnet).

Wenn allerdings die Zahl der Threads wächst, erhöht sich der zur Verwaltung der Threads notwendige Overhead. Außerdem dürfen alle Threads, die an einer Sache arbeiten, sich nicht gegenseitig behindern (Stichwort: synchronized), sonst geht hier der Performancegewinn wieder zurück.

Ark