Programme mit Multicore Unterstützung
-
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...
-
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.
-
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.
-
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?
-
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?
-
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
-
Moore's Law gilt weiterhin. Nur kommen heut neue CPUs in immer kürzeren Abständen heraus, was auch die Sprünge kleiner macht
-
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 loginmein 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
-
Das Mooresche Gesetz bezieht sich nicht auf Festplattengeschwindigkeit.
-
!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.
-
!rr!rr_. schrieb:
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.
Glaub ich eher nicht. Gab da doch diesen "Wie lange dauert es, bis ich gebootet habe und einen kurzen Brief geschrieben habe"-Test, dessen Name mir gerade entfallen ist. Da haben irgendwelche Mitt-Achtziger-Kisten regelmäßig die Nase ziemlich weit vorne gehabt. Klar wird's Anwendungsgebiete gegeben haben, wo plötzlich alles viel viel schneller ging, aber die gibt's heute auch noch en masse.
Mal ganz abgesehen davon, dass manchmal mehr Performance gar nicht so spannend ist wie das Mehr an Features, das dazu beiträgt, die Performance bei neuerer Software trotz immer schnellerer Hardware gleich bleiben zu lassen.
Oder anders: Auch wenn ich auf meinem Rechner heutzutage Doom bestimmt mit 18000FPS spielen kann, sieht Skyrim (noch nicht selbst gespielt) doch einladender aus.
-
!rr!rr_. schrieb:
mein PC von 2003 war 1 x 1.7 GHz
und bootete in 39 s bis zum loginmein 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
könnte hinkommen. mein aktuelles os bootet in 5 sec (mac osx lion). allerdings nutze ich das feature selten. denn starten aus dem ruhezustand dauert 0 sec.
-
was meinst du mit "Ruhezustand" ? suspend-to-RAM ?
suspend-to-disk jedenfalls dauert bei mir umso länger, je mehr RAM in Verwendung ist.
-
OS X verwendet standardmäßig ein Hybrid-Sleep. Also suspend-to-RAM mit Disk-Suspend falls mal der Akku arg knapp wird.
-
Ok - mit Suspend-to-RAM läßt sich das Problem der Bootzeit umgehen, solange der Computer an ist.
nützt mir persönlich aber wenig, weil ich a) den stationären computer nicht ständig am Netz haben kann und b) mein PC statistisch alle 20-30 Tage unter l*n*x beim suspend-to-disk einfriert, sodaß ich dann rebooten muß, ob ich will oder nicht
ich habe gerade mal nachgezählt: bei einer von mir häufig benutzten Bytecode-vm beläuft sich der speedup innerhalb von 11 Jahren (1999: PII/400, 2010: i5/4x2.7-3.2) auf 48 (codes/s) bzw 118 (sends/s), das entspricht einer Verdoppelung rund alle 2 bzw 1.6 Jahre.