PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Macht wer mit bei der Intel Multi-Core Competition @TopCoder?


Senior Sanchez
2006-04-23, 21:46:15
Hi,

http://www.topcoder.com/longcontest/?module=Static&d1=intel_overview
Geht darum, Probleme zu lösen und natürlich Multi-Threading zu nutzen ;)

Aber ist das nicht eigentlich unfair der Vergleich? Ich meine, die nutzen war 4 (Paxville) Dual-Core Xeons, aber Java ist ja doch shcon von natur aus langsamer als C++ und da wäre doch ein Vergleich eventuell etwas hinkend, oder?

mfg

Neomi
2006-04-23, 22:06:41
Aber ist das nicht eigentlich unfair der Vergleich? Ich meine, die nutzen war 4 (Paxville) Dual-Core Xeons, aber Java ist ja doch shcon von natur aus langsamer als C++ und da wäre doch ein Vergleich eventuell etwas hinkend, oder?

Die absolute Dauer einer Berechnung ist nur ein mögliches Bewertungskriterium, das natürlich für den Vergleich unterschiedlicher Sprachen nicht unbedingt geeignet ist. Man kann aber auch die Effizienz messen, indem man die Dauer in Relation setzt zu der Dauer, die das Programm auf einem einzelnen Core benötigt. Oder man orientiert sich an der Auslastung der einzelnen Cores. Da gibt es schon genug Möglichkeiten für faire Vergleiche.

Senior Sanchez
2006-04-23, 22:10:25
Die absolute Dauer einer Berechnung ist nur ein mögliches Bewertungskriterium, das natürlich für den Vergleich unterschiedlicher Sprachen nicht unbedingt geeignet ist. Man kann aber auch die Effizienz messen, indem man die Dauer in Relation setzt zu der Dauer, die das Programm auf einem einzelnen Core benötigt. Oder man orientiert sich an der Auslastung der einzelnen Cores. Da gibt es schon genug Möglichkeiten für faire Vergleiche.

Machen die das dort so?
Ich meine, man muss ja nicht zwingend multithreaden, aber es ist sicherlich empfehlenswert.

Es gibt aber zum Teil auch Algorithmen die schlecht zu parallelisieren sind und somit wohl nur auf einem Core gut laufen würden bzw. auf mehreren nur mit viel sync-Overhead. Das könnte ja insofern zur Folge haben, dass ein guter Algo auf einem Core relativ schnell ist, aber von mehreren Cores nicht profitiert.
Ein anderer Algo ist dagegen auf Single-Core nicht berauschend, skaliert dafür aber wieder auf mehreren Cores richtig gut.
Im Endeffekt könnten beide dieselbe Laufzeit haben, nur welcher wäre dann besser?

Scheinbar gibts kein ultimatives Kriterium.

zeckensack
2006-04-23, 22:45:23
Die absolute Dauer einer Berechnung ist nur ein mögliches Bewertungskriterium, das natürlich für den Vergleich unterschiedlicher Sprachen nicht unbedingt geeignet ist. Man kann aber auch die Effizienz messen, indem man die Dauer in Relation setzt zu der Dauer, die das Programm auf einem einzelnen Core benötigt. Oder man orientiert sich an der Auslastung der einzelnen Cores. Da gibt es schon genug Möglichkeiten für faire Vergleiche.:|
void __cdecl
waste_time(void* trash)
{
while (1) {}
}

int
main()
{
//Achtfach-SMP-System schön auslasten ...
for (int i=0;i<7;++i) _beginthread(waste_time,0,NULL);

mach_sachen_single_threaded();
return(0);
}

Coda
2006-04-23, 22:54:02
Sie können den Source-Code ja einsehen ;)

Aber im Prinzip hast du natürlich recht, das beurteilen ist echt schwierig.

Senior Sanchez
2006-04-23, 23:04:04
Sie können den Source-Code ja einsehen ;)

Aber im Prinzip hast du natürlich recht, das beurteilen ist echt schwierig.

Können sie ;)
Aber es wird ja automatisch getestet und ich weiß nicht ob sie bei ich weiß nicht wieviel Submittern dann jeden Source anschauen.

Es scheint aber wirklich die Laufzeit gemessen zu werden.

Neomi
2006-04-23, 23:06:07
:|

<Quellcode>

Das würde ich mal als groben Cheat betrachten, dank Sourceneinsicht fällt das auch sofort auf. Wenn man aber die Cores mit tatsächlicher Arbeit füttert und nicht mit Pseudoarbeit, dann ist die Auslastung schon ein recht guter Anhaltspunkt für die Effizienz.

Aber es wird ja automatisch getestet und ich weiß nicht ob sie bei ich weiß nicht wieviel Submittern dann jeden Source anschauen.

Zumindest bei den potentiellen Siegern werden sie das bestimmt tun.

zeckensack
2006-04-23, 23:08:32
Sie können den Source-Code ja einsehen ;)

Aber im Prinzip hast du natürlich recht, das beurteilen ist echt schwierig.Das Beispiel ist übertrieben, aber du kannst auch recht leicht durch Thread-Synchronisation mehr Zeit verschwenden als du jemals durch die Parallelität wieder hereinfahren kannst. Insbesondere wenn du auf Windows mit den eingebauten Sync-Primitives arbytest, passieren solche Unfälle sehr schnell.

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=124022&highlight=semaphore
1,6µs um eine Semaphore hochzuzählen (2GHz K8).

Ich wollte damit auch nur verdeutlichen dass Auslastung niemals ein Kriterium sein darf um die Multithreading-Effizienz zu beurteilen. Verschleiß am Kernel ist auch Auslastung.

Neomi
2006-04-23, 23:37:17
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=124022&highlight=semaphore
1,6µs um eine Semaphore hochzuzählen (2GHz K8).

Holy Sh... :eek:

Na wenn das so ist, dann ziehe ich die Auslastung als Kriterium zurück. Bisher ist mir nie aufgefallen, daß Semaphoren so lahm sind (viel Arbeit zwischen den Synchronisationen). Wenn ich irgendwann mal meine Routinen dafür überarbeite und erweitere, werde ich hier bestimmt einige Fragen stellen. Kann ja immer mal sein, daß man irgendwas vergißt, was z.B. bei Systemen mit mehreren CPUs und getrennten Caches zu Problemen führen kann...

HellHorse
2006-04-23, 23:51:22
Aber ist das nicht eigentlich unfair der Vergleich? Ich meine, die nutzen war 4 (Paxville) Dual-Core Xeons, aber Java ist ja doch shcon von natur aus langsamer als C++ und da wäre doch ein Vergleich eventuell etwas hinkend, oder?
Doug Lea meint wenn man nebenläufigen Java Code hat, der 10 mal schneller ist als nebenläufiger C Code, dann man noch nicht mit optimieren begonnen, des Java Codes.
Ob man's glaubt ist natürlich jedem selbst überlassen, aber gerade in den aktuellen 1.6 betas sind ja einige nette Sachen drin:

jit optimiert lock je nach dem wie lange es gehalten wird (für sehr kurze Wartezeiten sollen spinlocks wirklich schneller sein als thread suspension)
lock coarsening
lock elimination

und es gibt natürlich all die bekannten Helferchen von java.util.concurrent. Trotzdem glaube ich solche Sachen erst wenn ich sie mit eigenen Augen sehe.

micki
2006-04-24, 00:05:50
ich hab mich bei dem zeug angemeldet, aber bisher bei keinen der competitions mitgemacht, die sind irgendwie nicht sonderlich herausfordernd. zZ gibt es zwei vectoren, beiden sind n-dimensionale vectoren und man soll nun zu jedem n-vector aus Vector A den nachesten zu vector B finden.

wenn man die testdaten kennen würde, könnte man es gut optimieren, aber so kann jeder algo je nach inputdaten getrascht werden.

da fand ich den contest den wir hier mal hatten besser ;)



btw. kann man dort immer die wertungsmechanismen ablesen. meist ne verrechnung von zeit und qualität.

Coda
2006-04-24, 00:07:47
Doug Lea meint wenn man nebenläufigen Java Code hat, der 10 mal schneller ist als nebenläufiger C Code, dann man noch nicht mit optimieren begonnen, des Java Codes.
Ob man's glaubt ist natürlich jedem selbst überlassen
Die Behauptung ist zumindest im Allgemeinen kaum zu halten. Aber diese Java-Evangelisten übertreiben ja gerne "etwas".

Senior Sanchez
2006-04-24, 16:58:59
Doug Lea meint wenn man nebenläufigen Java Code hat, der 10 mal schneller ist als nebenläufiger C Code, dann man noch nicht mit optimieren begonnen, des Java Codes.
Ob man's glaubt ist natürlich jedem selbst überlassen, aber gerade in den aktuellen 1.6 betas sind ja einige nette Sachen drin:

jit optimiert lock je nach dem wie lange es gehalten wird (für sehr kurze Wartezeiten sollen spinlocks wirklich schneller sein als thread suspension)
lock coarsening
lock elimination

und es gibt natürlich all die bekannten Helferchen von java.util.concurrent. Trotzdem glaube ich solche Sachen erst wenn ich sie mit eigenen Augen sehe.

Ungetestet glaube ich das auch erstmal so nicht.
Ich mag zwar Java auch und bin öfters euphorisch, aber übertreiben wollen wirs mal nicht ;)
Kannste mal kurz erklären was die einzelne Dinge genau bedeuten und wo es vllt ne kurze, kleine Einführung zu den concurrent-Sachen gibt?

thx

HellHorse
2006-04-24, 21:15:47
Die Behauptung ist zumindest im Allgemeinen kaum zu halten. Aber diese Java-Evangelisten übertreiben ja gerne "etwas".
Ich dachte eigentlich das würde so rüberkommen, aber egal. Doug Lea ist sicher kein b00n, trotzdem glaube ich solche Sachen erst wenn ich sie sehe. Sicher ist es immer möglich C++ Code zu schreiben der effizienter ist als gegebenen Java Code. Die Frage ist wohl eher, ob es ein verfügbarer Programmierer schafft.

@Senior Sanchez
http://www-128.ibm.com/developerworks/java/library/j-jtp10185/

Trap
2006-04-24, 21:29:59
Aber ist das nicht eigentlich unfair der Vergleich? Ich meine, die nutzen war 4 (Paxville) Dual-Core Xeons, aber Java ist ja doch shcon von natur aus langsamer als C++ und da wäre doch ein Vergleich eventuell etwas hinkend, oder?
Ja, der Vergleich ist unfair, aber aus anderen Gründen: Man kann bei C/C++ inline asm und SSE benutzen und damit die innere Schleife handoptimieren, bei Java oder C# zählt nur das was aus dem Compiler rauskommt und das kann man nicht so direkt optimieren und SSE kann man garnicht verwenden.

Solange man normalen Code nimmt ist der Unterschied zwischen C++ und Java/C# in den allermeisten Fällen weniger als Faktor 2, damit landet man halt 5 Plätze weiter hinten oder so.

Die aktuelle Aufgabe ist Mist, die kann man im Zeitlimit optimal lösen und die Bewertung hängt nur von der Lösungsqualität ab...

Kabelsalat
2006-04-24, 22:44:35
Auf c# trifft das nicht ganz zu: Sofern gewollt, lassen sich gerade Array-Operationen durchaus durch "unsafe"-Code optimieren, der dann aber i.d.R. platformspezifisch ausfällt und die Performance durch das weglassen sinnvoller Kontrollmechanismen erreicht (und somit den Code potentiell fehleranfälliger macht).