fb18.de
/ Off-Topic
/ Allgemeines
Was bringt DualCore?
Bin am überlegen, ob ich mir demnächst ein DualCore-System zulegen soll. Hab zu dem Zweck mal ein kleines Java-Programm geschrieben, welches den Performance-Boost ermittelt. Könnte jemand mit DualCore-CPU und Java6 so lieb sein, das einmal für mich durchzutesten?
zum DownloadMein Ergebnis:
F:\>java -jar dualcore.jar
sorting 7500000 elements using quicksort
one thread: 734 ms
two threads: 769 ms
performance boost using two threads: -5%
System: SONY VGN-FE11h (CoreDuo T2300 [1,66Ghz])
(
http://vaio.sony-europe.com/view/View.action?section=Products_ITE&productcategory=%2FComputing%2FVAIO+Notebooks%2FVN+Previous+Models%2FPM+FE+Series
&productmodel=%2FComputing%2FVAIO+Notebooks%2FVN+Previous+Models%2FPM+FE+Series%2FVGN-FE11H
&productsku=VGNFE11H.G4&site=ite_de_DE&page=ProductTechnicalFeatures)
[edit fal: http://tinyurl.com/yjpp2s – besser tiny als zerschossenes Layout :)]P:\>java -jar dualcore.jar
sorting 7500000 elements using quicksort
one thread: 610 ms
two threads: 637 ms
performance boost using two threads: -5%
P:\>java -jar dualcore.jar
sorting 7500000 elements using quicksort
one thread: 615 ms
two threads: 632 ms
performance boost using two threads: -3%
P:\>java -jar dualcore.jar
sorting 7500000 elements using quicksort
one thread: 609 ms
two threads: 639 ms
performance boost using two threads: -5%
Hm, das ist ja merkwürdig. Streng genommen lief das Programm sogar mit drei Threads (der Hauptthread hat zwei weitere Threads erstellt und dann auf deren Terminierung gewartet), vielleicht liegt's ja daran?
Hab das Programm mal so modifiziert, dass nur ein weiterer Thread gestartet wird und der Hauptthread selber aktiv rechnet. Ändert das was an der Situation? Oder verstehe ich irgendwas was an DualCore nicht?
F:\>java -jar dualcore1326.jar
sorting 7500000 elements using quicksort
one thread: 782 ms
two threads: 816 ms
performance boost using two threads: -5%
Aufpassen, die .jar Datei heisst jetzt anders.Ach so, und Du hast nicht zufällig im Hintergrund noch andere Java-Applikationen laufen? Azureus oder so? [img]
http://www.fb18.de/gfx/23.gif[/img]
Und prober auch mal die Server VM, vielleicht bringt das ja was:
F:\>java -server -Xms128m -Xmx128m -jar dualcore1326.jar
Y:\>java -jar dualcore1326.jar
sorting 7500000 elements using quicksort
one thread: 351 ms
two threads: 366 ms
performance boost using two threads: -5%
mit core2duo 6600.
kann ich mir den sourcecode mal ansehen? würde mich mal interessieren wie du das gemacht hast. ausserdem wäre vielleicht eine noch längere sortierung ganz gut…. dann könnte ich mir die cpu auslastung während des laufes mal ansehen (also so laufzeit 30sec oder mehr)
Meine Erfahrung sagt, dass Dual-Core-Prozessoren vor allem bei Multitasking schneller sind. Inzwischen gibt es aber auch genügend Software, die zwei Kerne ausnutzen kann, beispielsweise Videocodecs wie x264, die man auf threaded stellen kann. Bei Java bin ich mir da nicht so sicher, ob das überhaupt so gut mit mehreren Kernen funktioniert.
Bei vielen Anwendungen bringen mehrere Kerne auch Nachteile, gerade bei Spielen sind schnelle Singlecores besser.
Meine Erfahrung sagt, dass Dual-Core-Prozessoren vor allem bei Multitasking schneller sind.
ok das ist das einfachste, weil im allgemeinen nur geringe abhängigkeiten zwischen den tasks bestehen.
Inzwischen gibt es aber auch genügend Software, die zwei Kerne ausnutzen kann, beispielsweise Videocodecs wie x264, die man auf threaded stellen kann. Bei Java bin ich mir da nicht so sicher, ob das überhaupt so gut mit mehreren Kernen funktioniert.
java sollte mit 2 kernen etwas anfangen können.
Bei vielen Anwendungen bringen mehrere Kerne auch Nachteile, gerade bei Spielen sind schnelle Singlecores besser.
weil spiele im allgemeinen (bisher) nur mit einem thread laufen. das muss aber nicht so sein. und wird sich sicher in den nächsten jahren ändern
mal ein (sehr sinnloses) testprogramm von mir:
public class MPTest extends Thread
{
public void run()
{
long t = System.currentTimeMillis() + 20000;
int i = 0;
while(System.currentTimeMillis() < t)
{
i++;
}
}
public static void main(String[] args)
{
new MPTest().start();
new MPTest().start();
}
}
das lastet meinen dualcore mit etwa 100% aus.
wenn man einen "new MPTest().start();" auskommentiert, liegt die cpu last ziemlich genau bei 50% - interessanter weise aber nicht eine cpu mit 100% und eine mit 0%; sondern beide cpus mit etwa 50%. das betriebsystem scheint also den thread immer hin-und-her zu schieben…
mit 2 cpus und 1 thread:
[img]
http://tnw.game-host.org/temp/2cpu1thread.png[/img]
Ohne mich an Dieter Nuhr zu halten würde ich mal empfehlen, auch in der single-thread-Version einen zweiten thread zu erzeugen, da AFAIK eben diese thread-Erstellung in Java recht teuer ist.
Ohne mich an Dieter Nuhr zu halten würde ich mal empfehlen, auch in der single-thread-Version einen zweiten thread zu erzeugen, da AFAIK eben diese thread-Erstellung in Java recht teuer ist.
teuer ja aber niemals so teuer. bei einem kleinen test bei mir lag die zeit für einen thread im microsekundenbereich (77 µs/Thread) bei der Erzeugung von 10000 Threads die sich langweilen *g* - inklusive der erzeugung der objekte.
sollte als bei einer messung im millisekundenbereich unter der messbarkeitsgrenze liegen.
public static void main(String[] args)
{
long t = System.nanoTime();
for(int i = 0; i < 10000; i++)
new Thread().start();
long summe = System.nanoTime() - t;
System.out.println(summe); //summe nanosekunden
System.out.println(summe / 10000); //1 thread nanosekunden
System.out.println(summe / 10000 / 1000); //1 thread microsekunden
}
Ich als Nicht-Experte trage mal - auch auf die Gefahr hin, mich lächerlich zu machen - bei, dass ich von dual core erwartet hätte, dass die beiden CPUs auf einer sehr hardwarenahen Ebene verschiedene Aufgaben zugeteilt bekommen und die Ebene, auf der Threads laufen, viel zu high-level ist, als dass ein Thread einen Prozessor erhalten würde…
Ich als Nicht-Experte trage mal - auch auf die Gefahr hin, mich lächerlich zu machen - bei, dass ich von dual core erwartet hätte, dass die beiden CPUs auf einer sehr hardwarenahen Ebene verschiedene Aufgaben zugeteilt bekommen und die Ebene, auf der Threads laufen, viel zu high-level ist, als dass ein Thread einen Prozessor erhalten würde…
Ebenfalls ohne Beachtung des Nuhr-Prinzips moechte ich dem entgegensetzen, dass ich der Meinung bin, zwei Cores seien tatsaechlich auf einem sehr hohen Level unabhaengig; deine Beschreibung wuerde ich eher dem "Hyperthreading" zuordnen. :)
Ich als Nicht-Experte
Ebenfalls ohne Beachtung des Nuhr-Prinzips
Okay, nu mal Butter bei die Fische, ich hab' mich gerade in der
Wikipedia schlau gemacht.
Hyperthreading ist die Slangbezeichnung für die Hyper-Threading Technology (HTT) (tm by Intel) der Pentium 4-Reihe. Diese Prozessoren haben von den Bauteilen, die den Prozessor-state speichern, zwei Ausgaben. Damit können sie so tun, als seien sie zwei Prozessoren, sie benutzen aber immer noch die gleiche ALU etc.
Ist das das, was man auch als Dual Core bezeichnet?
nein nicht ganz, bei Hyperthreading wird ein 2. Prozessor emuliert und kann so nen vorteil bei multitaksing sowie bei appz mit mehreren prozessen sein (nicht threads).
der punkt ist in java werden neu threads immer in der Threadgruppe von dem Main programm gestartet[javadoc:ThreadGroup], d.h. eure eben erstellten Threads haben alle die Gleiche Priotritaet, die Threadsheduler sind in Java noch nicht soo der Hammer, es gibt einige (atm faellt mir nur keiner ein) oss Implementierungen die recht gut sind, muesste ihr mal in den Java3D engine Foren nachguggn da gibs heisse diskussionen darueber ^^
Thread kommunikation ist immer teurer als die KOmmunikation in einem thread bei einzelnen "kleineren" Berechnungen wie ihr sie bisher gemacht hab ist der Aufwand des erzeugens im Verhaeltnis zu dem was ihr bei den Berechnungen einspart fast gleich.
Da die VM die zwischen werte der Berehcnung speichert bzw sieht das in dem punkt 2 threads mit den gleichen berechnungen bestartet werden hat der 2. Thread einen Vorteil in der berechnung, sieht man auch in dem Post von Silverstar, warum der dritte Durchgang wieder den Original wert hat weiss ich auch grade net ^^
Da bei den ganzen Betriebsystemen die Threadverwaltung diesem ueberlassen ist, koennt ihr den Threads nur ne Prio zuweisen udnd adurch die Abarbeitung bneeinflussen, dieses Abstraktionskonzept ist bewusst gewaehlt, je mehr Cores oder Physische Prozessorern in dem System ansich sind, kann das Betriebsystem deinem Jva main ThreadGroup einen Physischen Prozi zuweisen, in dieser ThreadGroup uebrnimmt dann die Jva implementierung die Verwaltung der CPU ressourcen fuer die einzelnen Threads.
Du musst beim Start 2 ThreadGroups erstellen in denen Jeweils ne Eigenen Thread starten und dann wuerde man dei Verwaltung ein wenig beeinflussen, da man dem OS 2 Prozesse direkt anbietet.
Der Untershcied zwischen Hyperthreading und Core2 bzw Multicore Systemen ist der das in echten Multiprozessor Systemen alle Cpus nen eigenen Cache haben, bei Core2 sind es 2 eigenstaendige CPUs die aber auf den gleichen Cache zugreifen, bei Hyperthreading greifen diese beiden Emulierten CPUs nicht nur auf den gleichen Cache zu sondern auch auf die Gleiche ALU, deswegen bringen Hyperthreading CPUs nur etwas wenn 2 seperate Prozesse/Anwendungen ohne grosse mathematische berehcnungen laufen, oder man nutzt das so aus das man einen Thread fuer Berechnungen laufen hat, zb die Logik oder Physik berechnung (in Games zB) und die Grafik in dem anderen Thread (GUI in einen Thread packen ist insofern guter Stil, da sonst evt die Logik auf nen Click mit der Maus warten bzw der User auf ne laengere Berechnung warten muesste)
Die Benutzung von ThreadGroups in Java wuerde ich alelrdings nicht empfehlen da man dann wie gesagt selber fuer die Threadverwaltung zustaendig ist, und da eine Faire Variante zu finden die auch noch Performance boost bringt ist nicht immer leicht.
gruss
Cheek
also zumindest was du zu threadgoups geschrieben ahst ist so quatsch.
http://java.sun.com/docs/books/jls/first_edition/html/javalang.doc19.html :
Thread groups provide a way to manage threads and to impose security boundaries; for example, a thread may always create a new thread within its own thread group, but creating a thread in another thread group requires the approval of the security manager (§20.17), as does the creation of a new thread group.
das ganze hat
nichts mit der aufteilung auf mehrere prozessoren oder der übersetzung von java-threads in betriebsstem-threads oder -prozesse zu tun.
achja und das mit dem cache stimmt auch nicht…
http://de.wikipedia.org/wiki/Intel_Core :
Beim Core Duo sind zwei Yonah-Kerne zusammengeschaltet, der L2-Cache ist aber nur einmal für beide Kerne vorhanden (Shared Cache). Bei Intels ersten Dual-Core-Prozessoren Pentium D war der L2-Cache noch für beide Kerne einzeln vorhanden.
dass die prozessoren auf einem chip sind heisst also nicht zwangsläufig, dass sie einen gemeinsamen cache haben. (L1 cache sowieso nicht)
[offtopic]
Bitte bemüht euch um korrekte (alte, neue oder ganz neue) Rechtschreibung, damit eure Texte für andere besser lesbar sind.
(bzw. für einige vielleicht überhaupt erst verständlich, z. B. für ausländische Studierende) [img]
http://www.fb18.de/gfx/23.gif[/img]
[/offtopic]
mal ein (sehr sinnloses) testprogramm von mir:
public class MPTest extends Thread
{
public void run()
{
long t = System.currentTimeMillis() + 20000;
int i = 0;
while(System.currentTimeMillis() < t)
{
i++;
}
}
public static void main(String[] args)
{
new MPTest().start();
new MPTest().start();
}
}
das lastet meinen dualcore mit etwa 100% aus.
wenn man einen "new MPTest().start();" auskommentiert, liegt die cpu last ziemlich genau bei 50% - interessanter weise aber nicht eine cpu mit 100% und eine mit 0%; sondern beide cpus mit etwa 50%. das betriebsystem scheint also den thread immer hin-und-her zu schieben…
mit 2 cpus und 1 thread:
[img]http://tnw.game-host.org/temp/2cpu1thread.png[/img]
Diese Auslastung beider Kerne zu jeweils ca 50% kommt daher, dass der Prozess zwischen den Kernen hin- und hergeschoben wird.
Das macht Windows ganz gerne und das führte bei Systemen mit 2 Kernen, die mit unterschiedlicher Frequenz laufen (Energie sparen…) auch zu Problemen, weil sich irgendwelche Counter dann nicht so verhalten, wie man das gerne hätte.
http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/65035&words=dual%20Core%20Probleme%20Dual
achja und das mit dem cache stimmt auch nicht…
http://de.wikipedia.org/wiki/Intel_Core :
Beim Core Duo sind zwei Yonah-Kerne zusammengeschaltet, der L2-Cache ist aber nur einmal für beide Kerne vorhanden (Shared Cache). Bei Intels ersten Dual-Core-Prozessoren Pentium D war der L2-Cache noch für beide Kerne einzeln vorhanden.
dass die prozessoren auf einem chip sind heisst also nicht zwangsläufig, dass sie einen gemeinsamen cache haben. (L1 cache sowieso nicht)
Den L1 Cache kann man nicht sharen, das die das nun endlich mitm L2 Cache getan haben, gut, der L3 Cache ist allerdings immer noch geshared, damit ist meine Aussage nicht komplett falsch und ich sagte auch nicht das man mit den ThreadGroups das Verhalten manipulieren kann sondern nur ein wenig beeinflussen, java is un mal ne highlevel Sprache und damit hat man diese low level Features eben nicht mehr.
Allerdings werden dei CPU ressourcen einer ThreadGroup zugeordnet nicht einem Java Thread. Die einzige manipulation dei Java unterstuetzt ist in den neuen Versionen die Priorisierung, und das wird sich auch in Zukunft nicht wirklich aendern, bis auf ein paar exotische Implementierungen.
gruss
cheek
Naja, der L3 wird doch nur aus Kostengründen geshared, schneller wäre sicher ein großer L2 für jeden Kern.
Naja, der L3 wird doch nur aus Kostengründen geshared, schneller wäre sicher ein großer L2 für jeden Kern.
Nein, nicht wenn mehrere Threads auf gleiche Daten zugreifen müssen.
dann sollte man vielleicht gesahrte und ungesharete l2 chaches haben… auf die einen kommt man schnell drauf und bei den anderen bekommt halt auch der andere prozessor was von ab ;)
das könnte ich mir in vielen situationen als sehr sinnvoll vorstellen..
Wenn ich das richtig in Erinnerung habe, muss der L3 ja verteilt werden. Das kostet normalerweise etwas Zeit, dafür spart man Cache ein, denn man braucht ja nicht so viel. Bei zwei großen L2s könnte man ja einfach die Daten doppelt reinschmeißen…
Allerdings werden dei CPU ressourcen einer ThreadGroup zugeordnet nicht einem Java Thread. Die einzige manipulation dei Java unterstuetzt ist in den neuen Versionen die Priorisierung, und das wird sich auch in Zukunft nicht wirklich aendern, bis auf ein paar exotische Implementierungen.
Auch auf die Gefahr hin, dich missverstanden zu haben… ThreadGroups dienen nur der logischen Verwaltung von Threads. Es ist mir völlig schleierhaft warum Rechenzeit deiner Meinung nach einer ThreadGroup zugeordnet sein soll. Pro JVM existiert ein Heap, pro Thread ein Stack. Inwiefern welcher Thread wann und auf welcher CPU zur Ausführung kommt, hängt von der Priorisierung und der programmatischen Synchronisation mal abgesehen nur vom Betriebsystem ab. Eine ThreadGroup garantiert dabei keine deterministische Ausführung ihrer Threads.
genau so habe ich es auch verstanden und so siehts auch in den quellcodes zu den betrefenden klassen aus (zum teil native code…)
ausser einer max priority und eben einer sicherheitsbeschränkung für threads in der group ist da nicht viel drinn..
Ich bitte darum, alles zu ignorieren, was bisher in diesem Thread (no pun intended!) geschrieben wurde, und meine
neue Version zu testen.
C:\>java -jar dualcore2.jar
generating list of 7500000 random integers...
firing up the engines... benchmark starts!
single threaded: 1851 ms
double threaded: 1853 ms
single threaded: 1855 ms
double threaded: 1856 ms
single threaded: 1872 ms
double threaded: 1856 ms
single threaded: 1851 ms
double threaded: 1862 ms
single threaded: 1829 ms
double threaded: 1859 ms
speedup: -0,29%
your cpu seems to be single core :-(
Da ich noch keine DualCore CPU habe, fällt das Ergebnis natürlich (mal wieder) entsprechend aus. Die Ergebnisse auf DualCore CPUs würden mich brennend interessieren. Voraussetzung: Java6
EDIT: Die Assertions müssen für den Benchmark natürlich nicht unbedingt eingeschaltet werden, hab das mal korrigiert.
C:\>java -jar dualcore2.jar
generating list of 7500000 random integers...
firing up the engines... benchmark starts!
single threaded: 2014 ms
double threaded: 1249 ms
single threaded: 2078 ms
double threaded: 1037 ms
single threaded: 2026 ms
double threaded: 1738 ms
single threaded: 2139 ms
double threaded: 1175 ms
single threaded: 2171 ms
double threaded: 1821 ms
speedup: 55,87%
@ Core Duo T2300 (1,66 Ghz)
@ Core Duo T2300 (1,66 Ghz)
^^this was me :)
speedup: 55,87%
Hm, nicht besonders viel. Laufen Prozesse im Hintergrund? Schalte mal so viele wie möglich aus.
speedup: 55,87%
Hm, nicht besonders viel. Laufen Prozesse im Hintergrund? Schalte mal so viele wie möglich aus.
sofort…geht gleich los hier ;)
muss noch zuende rendern erst ;)
Na dann prognostiziere ich mal einen Speedup von ~90%, wenn Du mit Rendern durch bist.
Menno Fred, ich wollt den Beitrag von oben editieren, das geht nu nich mehr so wie ich wollte..du bist doof [img]
http://www.fb18.de/gfx/17.gif[/img]
C:\>java -jar dualcore2.jar
generating list of 7500000 random integers...
firing up the engines... benchmark starts!
single threaded: 1995 ms
double threaded: 1039 ms
single threaded: 1998 ms
double threaded: 1045 ms
single threaded: 1995 ms
double threaded: 1037 ms
single threaded: 1995 ms
double threaded: 1042 ms
single threaded: 1994 ms
double threaded: 1039 ms
speedup: 91,71%
[u]2nd Run:[/u]
speedup: 91,7%
[u]3rd Run:[/u]
speedup: 92,13%Wie gesagt: Core Duo T2300 @ 1,66 Ghz (=^= Nootebook von meinem ersten Post)
Hier mal mein Resultat :
C:\>java -jar dualcore2.jar
generating list of 7500000 random integers...
firing up the engines... benchmark starts!
single threaded: 2042 ms
double threaded: 1060 ms
single threaded: 2037 ms
double threaded: 1063 ms
single threaded: 2040 ms
double threaded: 1056 ms
single threaded: 2040 ms
double threaded: 1060 ms
single threaded: 2035 ms
double threaded: 1057 ms
speedup: 92,4%
Laut CPU-Z hab ich einen Intel Pentium D 830 @ 3 Ghz
C:\Dokumente und Einstellungen\svelin\Desktop>java -jar dualcore2.jar
generating list of 7500000 random integers…
firing up the engines… benchmark starts!
single threaded: 2089 ms
double threaded: 1402 ms
single threaded: 2094 ms
double threaded: 1432 ms
single threaded: 2085 ms
double threaded: 1411 ms
single threaded: 2343 ms
double threaded: 1423 ms
single threaded: 2095 ms
double threaded: 1403 ms
speedup: 51,38%
@Pentium 4 mit 3GHz und Hyperthreading
Nachtrag zum obigen Test:
Laut CPU-Z ein Pentium 4 630 mit 3Ghz und besagten HT
Tzwoenn
Interessant, dass Hyperthreading trotz SingleCore tatsächlich 50% bringt. Danke für die Tests!
Hat jemand nen QuadCore? Dann dürfte die
neue Version interessant sein [img]
http://www.fb18.de/gfx/23.gif[/img]
Ich habe den Benchmark heute komplett überarbeitet. Der Umgang mit den Threads ist jetzt sehr viel dynamischer, die Anzahl zu verwendender Threads ist beliebig skalierbar.
Neue VersionGetestet werden jetzt 1-8 Threads. Bitte vor dem Benchmarken alle rechenintensiven Programme schliessen!
Die Ergebnisse des neuen Benchmarks auf MultiCore Prozessoren interessieren mich sehr, da ich nicht einmal sagen kann, ob mein neues Verfahren überhaupt effektiv ist. Also schonmal danke fürs Testen :)
Gut wäre auch, wenn ihr das ganze einmal mit eingeschalteten Assertions testen könntet.
Der vorherige Benchmark brachte 92% speedup, der neue ist nicht ganz so fix:
multicore benchmark 070217-2230
1 thread : 916 ms
2 threads: 504 ms
3 threads: 504 ms
4 threads: 495 ms
5 threads: 511 ms
6 threads: 510 ms
7 threads: 499 ms
8 threads: 512 ms
1 thread : 909 ms
2 threads: 500 ms
3 threads: 504 ms
4 threads: 505 ms
5 threads: 509 ms
6 threads: 513 ms
7 threads: 503 ms
8 threads: 508 ms
1 thread : 923 ms
2 threads: 494 ms
3 threads: 492 ms
4 threads: 512 ms
5 threads: 508 ms
6 threads: 508 ms
7 threads: 499 ms
8 threads: 498 ms
1 thread : 915 ms
2 threads: 498 ms
3 threads: 505 ms
4 threads: 507 ms
5 threads: 508 ms
6 threads: 507 ms
7 threads: 502 ms
8 threads: 518 ms
1 thread : 920 ms
2 threads: 499 ms
3 threads: 495 ms
4 threads: 511 ms
5 threads: 501 ms
6 threads: 509 ms
7 threads: 500 ms
8 threads: 508 ms
1 thread average: 916 ms
2 threads average: 499 ms
3 threads average: 500 ms
4 threads average: 506 ms
5 threads average: 507 ms
6 threads average: 510 ms
7 threads average: 501 ms
8 threads average: 509 ms
1 thread -> 2 threads: 83,49%
1 thread -> 3 threads: 83,15%
1 thread -> 4 threads: 81,05%
1 thread -> 5 threads: 80,51%
1 thread -> 6 threads: 79,78%
1 thread -> 7 threads: 83,02%
1 thread -> 8 threads: 80,03%
2 threads -> 3 threads: -0,18%
2 threads -> 4 threads: -1,33%
2 threads -> 5 threads: -1,62%
2 threads -> 6 threads: -2,02%
2 threads -> 7 threads: -0,26%
2 threads -> 8 threads: -1,89%
3 threads -> 4 threads: -1,15%
3 threads -> 5 threads: -1,44%
3 threads -> 6 threads: -1,84%
3 threads -> 7 threads: -0,07%
3 threads -> 8 threads: -1,7%
4 threads -> 5 threads: -0,29%
4 threads -> 6 threads: -0,7%
4 threads -> 7 threads: 1,09%
4 threads -> 8 threads: -0,56%
5 threads -> 6 threads: -0,41%
5 threads -> 7 threads: 1,39%
5 threads -> 8 threads: -0,27%
6 threads -> 7 threads: 1,8%
6 threads -> 8 threads: 0,14%
7 threads -> 8 threads: -1,63%
@ dual core 1,66 GHz, Java 6, 2.6.17-11-generic
Der vorherige Benchmark brachte 92% speedup, der neue ist nicht ganz so fix
Wobei ich erwähnen muss, dass die hervorragende Parallelisierung im alten Benchmark nur deswegen möglich war, weil ich ein bischen bei der Wahl des Pivot Elements geschummelt hatte. Anstatt das Element aus der Mitte der Liste zu picken, habe ich den Wert genommen, von dem ich anhand der künstlich erstellen Zufallsliste wusste, dass er nach dem Sortieren in der Mitte landen würde. So waren die resultierenden Teillisten exakt gleich gross.
1 thread -> 2 threads: 83,49%
Das freut mich. Vielen Dank fürs Testen!
Die Ausnutzung von QuadCore-Prozessoren unter Spielen steht wirklich erst vor dem Beginn und dürfte demzufolge ähnlich wie bei DualCore mehr oder weniger zwei Jahre benötigen, um auf einen vergleichbaren Stand zu heute bei DualCore-Prozessoren zu kommen.
Glaube ich ehrlich gesagt nicht. Der Schritt von SingleCore zu DualCore erforderte in der Programmierung ja überhaupt erst die ernsthafte Auseinandersetzung mit mehreren Threads. Ob das jetzt 2 oder 4 sind macht dann aber nicht mehr so den grossen Unterschied in der Denkweise.
