Alle bereit für Multicore?

[slashCAM]

Alle bereit für Multicore? von rudi - 15 Sep 2006 10:20:00
>Nachdem die Webseite Anadtech gezeigt hat, dass die neuen Mac Pro Modelle auch schon zum Oktal-System taugen, kommt eine neue Herausforderung an die Softwareproduzenten zu.
zum ganzen Artikel

[Alpinist]

Alle bereit für Multicore?

Alles andere als das :(
Die meisten Programme kommen leider nicht mal mit Dualcore klar...

Grüße

--
http://www.alpinisten.info/
http://www.gipfelsammler.de/

[Dj Dino]

Ja das alles ist nicht so einfach.Schon die jetzigen Athlon 64 X2 und Pentium D-Prozessoren,etc. haben hier Probleme und so gibt es ja schon jetzt bereits einen inoffiziellen "DualCore-Patch" für WindowsXP-SP2 :

http://support.microsoft.com/kb/896256/de
Download : http://download.gameswelt.de/detail/nfs ... 86-ENU.exe

Das der Patch mitlerweile schon 3mal überarbeitet wurde b.z.w. schon in der 3ten Version vorliegt (KB896256-v3) beweist wie stark sich MS der Problematik in Wahrheit durchaus bewusst ist und daran rumdokert.Öffentlich war & ist kaum etwas davon zu hören, wohl aber weniger wegen fehlendem Bedarf da eine zu geringen Betroffenheit mancher User sondern wohl mehr weil MS wohl ein Problem damit hat so einen Fehler einzugestehen wo es doch immer hies WindowsXP sei u.a. auch ein vollwertiges Multiprozessorsystem.

Es ist also schon jetzt mit DualCore möglicherweise problematisch.

Wenn ein Code-Thread zwischen 2 Prozessorkernen wechselt und dieser sich aber möglicherweise gerade im falschen Energiezustand befindet weil die P-States (Taktfrequenz-Abstufungen) aufeinmal noch wärend der Codeausführung aggieren...somit laufen - wenn auch nur extrem kurzzeitig - Anwendungen auf Kernen mit leicht unterschiedlicher Taktfrequenz.Merkt man besonders bei Computerspielen was sich dann in "Rucklern" äussert.Auch der Read Time Time Stamp Counter (RDTSC) (wenn Anwendungen auf unterschiedliche WindowsTimer-APIs oder System-Timer zugreifen) kann Probleme machen, bedingt wiederum durch unterschiedliche Kernauslastung kann es dann asynchron werden.Klar kann man als einfache Abhilfe einfach die Stromspar-Funktionen der CPU im BIOS abschalten (Cool and Quiet bei AMD oder EIST bei Intel) oder im BIOS bei PowerManagment "Dauerbetrieb" wählt - aber wer will schon darauf verzichten (leiserer CPU-Lüfter und weniger Stromverbrauch)
Zum Glück gibt es da diesen Patch welcher aber nicht zu 100% eine Lösung der Probleme darstellt (beispielsweise laufen nicht alle Computerspiele danach perfekt) denn der Patch macht im Prinzip nur in der boot.ini den Eintrag ""/usepmtimer" womit der ACPI-Timer anstatt Timestamp-Counter(TSC) verwendet wird, deswegen wird dann auch gleich die Halmacpi.dll aktuallisiert (aha, arbeitet anscheinend sonst auch nicht wirklich astrein...) und sogar kernelspezifische Datein (ntkr*.*. u.s.w) - zu deutsch : Eine tiefgreifendes rumflicken an einem OS welches aber wohl an sich das Problem ist ;-(

Da kann auch der DualCore-Patch (AMD Dual-Core Optimizer ) seitens AMD nichts helfen :
http://www.amd.com/us-en/Processors/Tec ... 06,00.html
(niemals beide Patches von MS und AMD gleichzeitig verwenden!)

So wie es aussieht : Eine wirkliche Lösung kommt (bei MS) erst mit dem auf Dual/Multi-Core so richtig optimierten WindowsVista welcher disbezüglich vorallem einen besseren Multiprozessorkernel samt natürlich verbesserten Scheduler (u.a. für Corezuweisungen verantwortlich) mitbringt und auch sonst drumherum ganz auf Dual und Multicore eingeschossen ist, jener von WindowsXP ist nicht gerade sonderlich intelligent.Es liegt also nicht nur an der Anpassung der Software sondern auch jener des OS, Linux und OSX ist da schon seit jeher weiter wie ja auch im Artikel steht.Ist das OS aber eine wirklich solide und ausgereifte MultiCore-Basis sind auch MultiCore-Anwendungen sicher nicht mehr so das Problem, man muss ja immer bedenken das bisherige MultiCore-Anwendungen für bei MS für ein OS geschrieben werden welches ansich für sowas schon mal nicht wirklich das gelbe vom Ei ist.XP benutzt bezüglich MultiCore-Unterstützung nochimmer jenen "mitgeschleppten", uralten Support von WindowsNT/2000 und damals gab es nur "echte" Multiprozessorsysteme, also mit physikalisch getrennten CPUs (auf Serverboards vorallem) nicht aber mehrere Kerne in einer CPU.Allein von daher ist und wurde XP auch nie wirklich für MultiCore auf einer CPU ausgelegt, zwar betrifft das auch einige andere Betriebssysteme mit MultiCore-Support aber bei Windows ist dieser einfach uralt.Mit Vista wird da alles besser.

[PowerMac]

Gerade Final Cut Pro, Motion, DVD Studio Pro, Shake, Maya oder Cinema 4D würden da ziemlich gut drauf laufen. Ich plane bereits nächstes Jahr einen 8x Core PowerMac als Hauptrechner einzusetzen. Zusätzliche kaufe ich fünf Mac mini mit insgesamt 10 Kernen, die via Gigabit Ethernet total einfach mitrendern. Für um die 10.000 Euro hätte man dann die zehnfache Rechenleistung heutiger Rechner!

[Gast]

@Power Mac:

Können denn die Apple-Programme wie Motion oder FCP auf den Minis verteilt rechnen? Bliebt da nicht die Performance im Netzwerk stecken?
Hast du das schon mal ausprobiert?

[Christian Schmitt]

Die Renderfarm dürfte er wohl hauptsächlich für die 3D Programme und vl Shake brauchen...
Und mit Gigabit Lan bleibt da auch nix stecken.
Längere komplexere 3D Szenen oder Compositings würden auf einem einzelnem System viel zu lange rendern und den kostbaren Arbeitsplatz blockieren...

[mdb]

Alle bereit für Multicore? von rudi - 15 Sep 2006 10:20:00
>Nachdem die Webseite Anadtech gezeigt hat, dass die neuen Mac Pro Modelle auch schon zum Oktal-System taugen, kommt eine neue Herausforderung an die Softwareproduzenten zu.
zum ganzen Artikel

Und ich hab geglaubt, wir reden von Kabel. Bei Kameras ist Triax in.

[Markus]

Und ich hab geglaubt, wir reden von Kabel.

Du bist da draußen nicht allein. ;-)

Siehe hier:
Alle bereit für Multicore? (Kabel)