Programme mit Multicore Unterstützung

volkard

Gerne auch konkreter:

Welche Compiler schreiben meinen Algorithmus automatisch so um, daß er parallel arbeitet? Keine.

gcc mit openMP

g++  bla.c -fopenmp

und in den Sourcen z B mit

#pragma omp parallel ...

festlegen, welche Schleifen parallelisiert werden sollen

Die Frage ist wohl zu schwierig für das C/C++ Forum.

DaRe

Ich finde die ursprüngliche Frage auch nicht wirklich eindeutig.

aufzählung schrieb:

Welche Programme unterstützen mittlerweile mehrere Cores?

* Compiler

Sollen wir hier jetzt alles aufzählen, was selbst auf Multicore effektiver läuft?

So wie ich es gelesen habe, läuft generell alles auf mehreren Kernen. Wenn der eine Kern zu warm wird, gibt das Betriebssystem an, den anderen mal zu benutzen etc.

Welche Programme aber in sich schon eine Verteilung mit Thread und co implementieren, um performanter zu laufen, weiß ich auch nicht.

quasi jede gui anwendung wird wohl mittlerweile mindestens 2 threads benutzen: einen zum zeichnen der gui und einen für die programmlogik. bei nur einem thread blockiert dieser den event dispatcher, so dass die anwendung nicht mehr auf aktionen des benutzers reagiert. fenster wird z.b. nicht mehr neu gezeichnet, wenn man es verschiebt.

im prinzip ist die frage aber eh irrelevant, da jedes aktuelle betriebssystem schon direkt von den kernen profitiert.

lolhehe schrieb:

quasi jede gui anwendung wird wohl mittlerweile mindestens 2 threads benutzen

Das halt ich für eine sehr optimistische Behauptung...

Btw. die Endlosschleife lässt sich perfekt parallelisieren...

hustbaer

aufzählung schrieb:

Welche Programme unterstützen mittlerweile mehrere Cores?

* Compiler

* Video-Encoder
* Video-Decoder
* 3D Programme (3D Studio, Maya, ...)
* Archivprogramme/Packer (zip, rar, ...)
* Viele Programme die Batch-Processing machen (nur ein Beispiel: MediaMonkey kann "on the fly" Format-Konvertierung für portable Player, und bearbeitet da dann mehrere Files parallel)
* Browser (mehrere Tabs, in jedem 10 Flash Videos und Java-Script das dauernd lästig im DOM rumfummelt)

Habt ihr eigentlich das Gefühl, dass die CPUs mit mehreren Kernen viel bringen? Irgendwie kommt es mir so vor, als ob die PCs dadurch nicht viel schneller geworden sind. Als früher noch die Taktfrequenz deutlich zunahm, hatte ich das Gefühl, dass das mehr bringt.

otze

unbekannter schrieb:

Habt ihr eigentlich das Gefühl, dass die CPUs mit mehreren Kernen viel bringen?

Ja, ich könnte mir jeden Tag in den Arsch beißen, dass ich auf den Mann im Computerladen gehört hat, der mir nur einen Dualcore angedreht hat. Quadcore ist einfach sooooo viel praktischer zum programmieren.

Irgendwie kommt es mir so vor, als ob die PCs dadurch nicht viel schneller geworden sind. Als früher noch die Taktfrequenz deutlich zunahm, hatte ich das Gefühl, dass das mehr bringt.

Placebo-Effekt.

hustbaer

Naja, also es gibt schon viele Dinge wo man die Leistungssteigerung eines Cores stark merkt, aber sich nix (oder fast nix) tut wenn man die Core-Anzahl verdoppelt.
Starte mal Visual Studio 2010 Pro (alle Features installiert) auf nem alten Core 2 Quad mit 4x 2,4 GHz, und dann nochmal auf Core i3 mit 2x 3,3 GHz.

otze schrieb:

unbekannter schrieb:

Habt ihr eigentlich das Gefühl, dass die CPUs mit mehreren Kernen viel bringen?

Ja, ich könnte mir jeden Tag in den Arsch beißen, dass ich auf den Mann im Computerladen gehört hat, der mir nur einen Dualcore angedreht hat. Quadcore ist einfach sooooo viel praktischer zum programmieren.

Irgendwie kommt es mir so vor, als ob die PCs dadurch nicht viel schneller geworden sind. Als früher noch die Taktfrequenz deutlich zunahm, hatte ich das Gefühl, dass das mehr bringt.

Placebo-Effekt.

Wenn du jetzt einen Quadcore hättest, könntest du vielleicht doppelt so schnell compilieren. Jetzt müsste man auch mal testen können, wieviel schneller man heute compilieren könnte, wenn die Taktfrequenz weiterhin so stark angestiegen wäre wie früher.

Irgendwann hatten wir mal wenige einstellige bis zweistellige MHz und vor ca. 10 Jahren hatten wir den einstelligen GHz Bereich erreicht. Jetzt müsste man mal testen, ob man den Code dann auch 100 oder 1000 mal schneller compilieren könnte (Hat da jemand Zahlen?). Jetzt (als 10 Jarhe später) sind wir immer noch im einstelligen GHz Bereich und haben vielleicht 24 Cores. Also können wir mit den 24 Cores 24 mal schneller compilieren, wie mit der gleichen CPU und einem Core. Wenn der eine Core jetzt 100 oder 1000 mal schneller getaktet wäre, wieviel schneller könnten wir dann compilieren?

nman

Du vergisst bei deiner Milchmädchenrechnung, dass CPUs heutzutage auch wesentlich mehr pro Takt leisten als früher. (Mit Rechenleistung/Watt fangen wir lieber gar nicht an.)

Eigentlich habe ich garnicht berechnet, dass wir X mal schneller wären. Mir ist auch klar, dass man das nicht so einfach ausrechnen kann. Aber wenn wir pro Takt noch mehr machen wären wir ja schon schneller, wenn man schneller takten könnte.

Hat schon mal einer versucht, wie lange ein bestimmter Code auf 386, Pentium, Pentium 4 und aktuellen CPUs compiliert?

SeppJ

Dann mal viel Spaß, den GCC auf einem 386er zum Laufen zu bringen. Theoretisch ist es möglich. Melde dich, wenn du so weit bist.

Ganz interessant vielleicht dies:
http://field.hypermart.net/CPU/cpu.htm

zwutz

Moore's Law gilt weiterhin. Nur kommen heut neue CPUs in immer kürzeren Abständen heraus, was auch die Sprünge kleiner macht

nman

unbekannter schrieb:

Hat schon mal einer versucht, wie lange ein bestimmter Code auf 386, Pentium, Pentium 4 und aktuellen CPUs compiliert?

Auf meinem P200 damals hat bei Suse 6.1 ein Linux-Kernel-Build irgendwas in der Größenordnung von zwei Stunden gedauert. Heutzutage bin ich eher bei zwei Minuten, nur dass ich praktisch keine Kernels mehr selbst kompiliere.

Linux war damals aber um Größenordnungen kleiner und die GCC konnte viel weniger. Kann mich an fette Kernels mit ~400KB erinnern; heutige Kernels wiegen eher so um die 4MB.

Suse 6.1 muss so um 1998 herum gewesen sein.

Mal sehen…

scale=0
2^((2012-1998)/1.5)
512
(4*10^6/2)/(400*10^3/120)
600

Wenn wir also so tun, als würde der alte Moore aussagen, dass Rechner alle 1.5 Jahre doppelt so schnell werden, dann müssten wir seit 1998 ungefähr um einen Faktor 512 schneller geworden sein.

Heutzutage produzieren wir 4MB Kernel in 2 Minuten, 1998 4KB Kernel in 2 Stunden. Da ist also ein Faktor 600 dazwischen. Wenn auch sonst nichts passt an der Rechnung, die Größenordnungen bleiben erhalten.

Die Schmerzen bei all den unzulässigen Vereinfachungen sind zwar böse, aber nicht annähernd so böse wie die dabei, mich mit Uraltrechnern und aktuellen Compilern bzw. Uraltcompilern und aktuellen Rechnern herumschlagen zu müssen. :xmas2:

mein PC von 2003 war 1 x 1.7 GHz
und bootete in 39 s bis zum login

mein jetziger ist von 2010: 4 x 2.6-3.2 GHz

dazwischen liegen 7 Jahre.

Bei einer angenommenen Tempo-Verdoppelung alle 1.5 Jahre müßte mein jetziger das gleiche OS ja in rund anderthalb sekunden booten, oder wie

SeppJ

Das Mooresche Gesetz bezieht sich nicht auf Festplattengeschwindigkeit.

nman

!rr!rr_.: Ich dachte, dass aus dem Kontext klar sei, dass ich mich auf CPUs beziehe.

Linux zu kompilieren war 1998 so derb CPU-bound, dass ich nicht glaube, dass eine Festplatte mit den Leistungsdaten meiner aktuellen SSD damals viel Geschwindigkeitszuwachs gebracht hätte. Insofern ist IO bei so einer Überschlagsrechnung IMO eher zu vernachlässigen als viele andere Faktoren, die aber sehr viel schwerer in Zahlen zu gießen sind.

Und wie gesagt: War nur um ganz grob und ganz naiv die Größenordnungen zu überschlagen. Wer sowas richtig ernst nimmt, ist selbst schuld.

letztendlich zählt, was für den Normalbenutzer an Beschleunigung bei rauskommt. Daß zwischen 1980 und 2000 ein Beschleunigungs-Faktor von 10000 gelegen haben kann, glaube ich gerne.

Es gibt aber nicht nur ein Moore'sches, sondern auch ein Wirth'sches Gesetz.