Wann wird die Software- endlich zur der Hardwareentwicklung aufschliessen können?

[klumy]

Wann wird die Software- endlich zur der Hardwareentwicklung aufschliessen können?

SSE2, 64Bit und nun Dualcore.
Im Alltagsbetrieb werden nicht mal die erstgenannteren gut durch Software unterstützt. Jetzt geht die INdustrie schon über zu DualCore. Macht das überhaupt Sinn?

[HellHorse]

Nein Dualcore macht auf dem Desktop keinen Sinn. Aber das will niemand hören.

[Gast]

HellHorse[/POST]']Nein Dualcore macht auf dem Desktop keinen Sinn. Aber das will niemand hören.

Aha, und wieso?

[eXistence]

Ich weiß zwar nicht inwiefern das auch für andere Entwickler gilt, aber zumindest id software hat kürzlich 6 Artikel veröffentlicht, die recht detailiert auf die Nutzung von SSE bei der D3-engine eingehen:

http://www.intel.com/cd/ids/developer/asmo-na/eng/dc/games/293451.htm


64bit bringt für Spiele AFAIK nicht wirklich viel, der Hauptvorteil ist die größere Speichermenge, die man nutzen könnte. Dass man so viel Speicher wirklich braucht war bislang nicht der Fall, das kommt erst jetzt so langsam...


HellHorse sagte es schon, DualCore ist auf dem Desktop bei weitem nicht so der Bringer, wie viele gerne glauben. Davon abgesehn gibts DC noch nicht so lange, also immer mit der Ruhe :)

[Gast]

eXistence[/POST]']HellHorse sagte es schon, DualCore ist auf dem Desktop bei weitem nicht so der Bringer, wie viele gerne glauben. Davon abgesehn gibts DC noch nicht so lange, also immer mit der Ruhe :)

Gibt es dafür auch mal eine Begründung?

[Silent3sniper]

HellHorse[/POST]']Nein Dualcore macht auf dem Desktop keinen Sinn. Aber das will niemand hören.

Für den 0815 User bestimmt nicht...aber das interessiert mich doch nicht! - Ich hab dadurch nur Vorteile...

[rpm8200]

DC bringt derzeit im Heimbereich noch nicht soooo viel, weil eben die Software nicht entsprechend weit ist (meine Meinung).

Das Kernproblem der Sache ist wohl folgendes: Generell wird die Software erst folgen, wenn Kompatibilität zum vorhandenen Markt gegeben ist. Das bedeutet: Solange der Markt z.B. ein 32 bit Betriebssystem benutzt, wird auch z.B. für 64 bit nichts entwickelt. Die Voraussetzungen, dass man mal auf 64bit OS umsteigen kann, muss technisch schon viel früher geschaffen werden. Viele AMD Nutzer sind derzeit technisch in der Lage, ein 64bit OS zu betreiben, bei Intel (deutlich größerer Marktanteil) sieht es da aber nicht so toll aus. Man darf auch nicht die ganzen Office PCs vergessen, die ebenfalls viel Software benötigen und einen großen Markt darstellen. Diese Gruppe wird noch viel länger auf den Sprung warten, da ein Umrüsten nur mit Kosten verbunden ist und solange alles läuft.... wird da nix gemacht. der Sprung von 32 auf 64 Bit muss leider sehr radikal vollzogen werden (entweder/ oder). Auch in einer größeren Firmenstruktur wird das wohl problematisch sein, da es nicht sehr sinnvoll ist (vielleicht auch mit Problemen behaftet, auf die ich jetzt nicht komme), nur einige Rechner auf 64 bit umzustellen und andere wieder nicht. Wenn, dann würde man wohl alle auf einmal umrüsten müssen. In einer Firma mit 2000 Rechnern möchte ich das nicht machen müssen...

Die großen Vorteile von 64bit OS wären die Adressierbarkeit der (viel größeren) Adressräume und geringe Zugewinne bei der Performance. Der Anreiz bzw. der Druck, auf 64bit zu switchen ist aktuell nur gering (und wohl deutlich niedriger als die Angst vor der Umstellung).

Bei SSE ist es imo anders, da SSE 2 Befehle, die ggf. nicht ausgeführt werden können (falls nicht HW-mäßig implementiert, soweit mir bekannt) "automatisch" durch (mehrere gleichwertige) SSE 1 Befehle ersetzt werden können. Warum das sooo lange dauert weiss ich nicht. Wahrscheinlich baut man auf vorhandene Module auf (Wiederverwendbarkeit bei Software ist ein großes Thema) oder auf Wissen und Erfahrung mit SSE und sieht den Nutzen darin nicht, auf SSE2 zu wechseln.

Bei DC denke ich steckt wohl dahinter, dass die Firmen "keinen Bock" haben, übermäßig Energie (=Geld) in DC Unterstützung zu stecken, da es derzeit auch immer noch single threaded geht. Anwendungen die extrem stark profitieren sind ja auch teilweise schon für DC optimiert (hier hat es sich scheinbar schon gelohnt). Multi-threaded Code benötigt aber auch Leute, die fähig sind, parallel zu denken (hört sich blöd an, ich weiss). Bisher war es eben alles streng sequentiell. Auch wenn man im PC mehrere Progs "gleichzeitig" ausgeführt hat, so war das doch nur geschickt vorgegaukelt seitens des Betriebssystems, welches dann jede Anwendung zeitscheibengesteuert und/ oder priorisiert zum Zuge kommen liess. Tatsächlich parallel lief aber eigentlich nichts. Und jetzt soll plötzlich alles parallel gemacht werden... das geht nicht so schnell.

[PatkIllA]

Ich sag nur smooth. Das hat vor 5 Jahren schon deutlich mehr Spass gemacht mit 2 Prozessoren. Wer immer nur eine Sache gleichzeitig am laufen hat, dem kann das oft aber egal sein.

Bei 64Bit bremst halt, dass man ein neues Betriebssystem und angepasste Treiber haben muss.
SSE2 wäre eigentlich wirklich nicht so schwer.
Für Dualcore muss man halt in die Entwicklung doch noch einiges an Hirnschmalz reinwerfen, um die Anwendungen so zu entwickeln. Das wird aber auch zwangsweise in Zukunft eine immer größere Rolle spielen. Einige wenige Anwendungen sind ja auch schon länger Multithreaded. Rendern, teilweise Videocodierung, alles was im Serverbereich läuft. Bei vielen Sachen lohnt es halt auch kaum. Z.B. bei einer Textverarbeitung ist die CPU bei 95% der Dokumente 99% der Zeit am warten.

[Toolman]

Ich finde die Software Herrsteller sollten endlich mal das ganze Potenzial ausschöpfen und die Programmierung der Berechnungen nicht nur auf zwei Lines einschränken ! Die sind nur zu Faul (ist nicht böse gemaint) !

[PatkIllA]

@Toolman
bei komplexer Software ist man schon froh, wenn alles halbwegs so läuft, wie es geplant war. Mit der Komplexität steigt exponentiell die Wahrscheinlichkeit, dass es eben nicht läuft.
Und grade bei Nebenläufigkeit handelt man sich schnell Fehler ein, die deutlicher schwerer zu entdecken sind.

[Gast]

rpm8200[/POST]']
Bei DC denke ich steckt wohl dahinter, dass die Firmen "keinen Bock" haben, übermäßig Energie (=Geld) in DC Unterstützung zu stecken, da es derzeit auch immer noch single threaded geht.


Viele Anwendungen sind multithreaded in irgend einer Art und Weise. Viele Leute hier sehen immer nur Spiele, da mag das durchaus der Fall sein. Aber dann kann man das nicht pauschal mit Desktop-Markt abtun.


Multi-threaded Code benötigt aber auch Leute, die fähig sind, parallel zu denken (hört sich blöd an, ich weiss). Bisher war es eben alles streng sequentiell.


Wer das nicht kann, sollte gar nicht erst programmieren anfangen. Klar sind die Qualitäten einer hoch parallelisierten 3D Engine etwas vollkommen anderes. Wobei man das natürlich jetzt hier aber auch nicht so hochglorifizieren sollte. Es gibt auch eine Menge anderer Gebiete, auch bei gewöhnlicher Standardsoftware wie z.B. Office, die sehr anspruchsvoll sind.
Multithreading ist aber nun wirklich nichts neues und wird wohl in vielen existierenden Programmen in irgend einer Form stecken, sei es auch nur irgend eine asynchrone Netzwerk Methode.


Auch wenn man im PC mehrere Progs "gleichzeitig" ausgeführt hat, so war das doch nur geschickt vorgegaukelt seitens des Betriebssystems, welches dann jede Anwendung zeitscheibengesteuert und/ oder priorisiert zum Zuge kommen liess. Tatsächlich parallel lief aber eigentlich nichts. Und jetzt soll plötzlich alles parallel gemacht werden... das geht nicht so schnell.

Auf Betriebssystemebene hat sich absolut nichts gändert. Es können eben nur mehrere Threads, je nach Anzahl der Kerne/Prozessoren, tatsächlich simultan ausgeführt werden. Trotzdem laufen auf einem Standardrechner in der Summe wahrscheinlich zig Threads, so dass es immer Wechsel zwischen verschiedenen Threads gibt. Auch mit einem Multicore ist es nicht so, dass eine Anwendung 100% einen Core für sich alleine hat.

[Coda]

SSE2 ist eigentlich uninteressant, da es eigentlich kaum Apps gibt die 64-bit Floating-Point verwenden.

Gast[/POST]']Wer das nicht kann, sollte gar nicht erst programmieren anfangen. Klar sind die Qualitäten einer hoch parallelisierten 3D Engine etwas vollkommen anderes. Wobei man das natürlich jetzt hier aber auch nicht so hochglorifizieren sollte. Es gibt auch eine Menge anderer Gebiete, auch bei gewöhnlicher Standardsoftware wie z.B. Office, die sehr anspruchsvoll sind.
Ist das jetzt Nachplapperei oder Erfahrung?

[Gast]

Coda[/POST]']
Ist das jetzt Nachplapperei oder Erfahrung?

Erfahrung

[BlackBirdSR]

Coda[/POST]']SSE2 ist eigentlich uninteressant, da es eigentlich kaum Apps gibt die 64-bit Floating-Point verwenden.


Ist das jetzt Nachplapperei oder Erfahrung?

SSE2 ist ja nicht nur double precision.
Du kannst ja auch sp-FP operationen damit ausführen und SSE2-Integer-Operationen ausführen.

Aber so (anscheinend) viel Arbeit wie bei D3 scheint wohl kaum einer in betracht zu ziehen.

[Coda]

BlackBirdSR[/POST]']Du kannst ja auch sp-FP operationen damit ausführen
Was kam da dazu ggü. SSE?

BlackBirdSR[/POST]']und SSE2-Integer-Operationen ausführen.
Ja. MMX auf 128-bit Register halt...

[BlackBirdSR]

Coda[/POST]']Was kam da dazu ggü. SSE?



Keine Ahnung ob gegenüber SSE Befehle für single precision packed Operationen hinzukamen. Aber mit dem SSE2 Befehlssatz kannst du halt auch die kompletten SSE Befehle übernehmen. Was SSE an sich eigentlich überflüssig machen sollte.
Wird natürlich noch gerne genommen, um die AthonXP nicht abzuschießen.

[Coda]

BlackBirdSR[/POST]']Aber mit dem SSE2 Befehlssatz kannst du halt auch die kompletten SSE Befehle übernehmen. Was SSE an sich eigentlich überflüssig machen sollte.
Ha? Wie meinen? Das ist doch Quatsch. SSE und SSE2 verwenden die gleichen Register, warum sollte man da Ops doppeln?

[BlackBirdSR]

Coda[/POST]']Ha? Wie meinen? Das ist doch Quatsch. SSE und SSE2 verwenden die gleichen Register, warum sollte man da Ops doppeln?

Warum sollte SSE2 kein superset von SSE sein?
Am Ende hast du zig Erweiterungen aus denen du auswählen musst.
So kannst du mit SSE2 alle Operationen erledigen, die du früher mit SSE und MMX und der x87 erledigt hast. Ist halt weniger chaotisch.

[rpm8200]

Gast[/POST]']Viele Anwendungen sind multithreaded in irgend einer Art und Weise. Viele Leute hier sehen immer nur Spiele, da mag das durchaus der Fall sein. Aber dann kann man das nicht pauschal mit Desktop-Markt abtun.Lies mein Post und Du wirst sehen dass ich nichts anderes behauptet habe (meine Behauptung war relativiert!).

Gast[/POST]']Wer das nicht kann, sollte gar nicht erst programmieren anfangen. Klar sind die Qualitäten einer hoch parallelisierten 3D Engine etwas vollkommen anderes. Wobei man das natürlich jetzt hier aber auch nicht so hochglorifizieren sollte. Es gibt auch eine Menge anderer Gebiete, auch bei gewöhnlicher Standardsoftware wie z.B. Office, die sehr anspruchsvoll sind.
Multithreading ist aber nun wirklich nichts neues und wird wohl in vielen existierenden Programmen in irgend einer Form stecken, sei es auch nur irgend eine asynchrone Netzwerk Methode.Entschuldige, aber was ist das für ein Gebrabbel? Ich programmiere selbst (beruflich) und es ist nicht so einfach multithreaded zu programmieren, dass es Sinn macht und läuft. Die Erfahrung mit Multithreading sind vielerorts noch gar nicht gemacht und diese zu machen kostet die Unternehmen Geld. Also wird es (wie alles was Geld kostet) seitens der Unternehmen erst mal hinaus geschoben, solange der Druck nicht steigt/ es unumgänglich wird. Ein bestehendes Konzept von Single Threaded auf Multi Threaded umzustellen (und zwar so dass es Sinn macht und läuft) ist nicht einfach.

Gast[/POST]']Auf Betriebssystemebene hat sich absolut nichts gändert. Es können eben nur mehrere Threads, je nach Anzahl der Kerne/Prozessoren, tatsächlich simultan ausgeführt werden. Trotzdem laufen auf einem Standardrechner in der Summe wahrscheinlich zig Threads, so dass es immer Wechsel zwischen verschiedenen Threads gibt. Auch mit einem Multicore ist es nicht so, dass eine Anwendung 100% einen Core für sich alleine hat.Du willst wohl mit Gewalt alle Aussagen fehldeuten? Ich wollte damit lediglich darauf hinweisen, dass bisher alles sequentiell gelaufen ist, auch wenn es für den Anwender parallel aussieht. Ich habe nirgends behauptet, dass sich für ein OS jetzt drastisch was ändert (zumindest DC ist wohl für aktuelle OS kein großes Problem).

[Gast]

rpm8200[/POST]']
Entschuldige, aber was ist das für ein Gebrabbel? Ich programmiere selbst (beruflich) und es ist nicht so einfach multithreaded zu programmieren, dass es Sinn macht und läuft.

Die Erfahrung mit Multithreading sind vielerorts noch gar nicht gemacht und diese zu machen kostet die Unternehmen Geld.

Das finde ich sehr verwunderlich. In jedem Programmier-Anfängerbuch steht irgend etwas zur Thread Erstellung. Also wenn noch niemand Workerthreads oder asynchrone Methodenaufrufe benutzt hat, naja... :|
Natürlich braucht man das nicht in jedem Fall, aber irgendwann sollte doch jeder mal darauf stoßen. Im einfachsten Falle dann, wenn man eine Reaktionsfähige GUI braucht.

Du brauchst ja nur mal im Taskmanager oder irgend einem Prozess Explorer nachschauen wieiviele Threads so einige Prozesse haben.

Aber um zum Thema zurückzukommen: Das Kernproblem, was hier wohl anscheinend auch gemeint ist, sind leistungshungrige Anwendungen, man darf hier auch ruhig mal Spiele sagen, bei denen das Threading so gestaltet werden muss, um alle Kerne/Prozessoren bestmöglichst auszulasten. Oder anders, alle Threads sollten ung. die selbe Last erzeugen.
Aber: Die Mehrzahl der Desktopanwendungen, und darum ging es hier, bedarf überhaupt nicht so viel Rechenpower, wie wir heute haben. Insofern gibt es hier auch überhaupt gar kein Problem. Ganz im Gegenteil, diese Mehrkerne/Prozessoren teilen sich dann eben die sowieso schon vorhandenen zig Threads von zig Prozessen. Das einzige relevante Szenario ist das, wenn eine Anwendung die maximalste Prozessorleistung benötigt. Das sind aber ganz sicher keine normalen Desktopanwendungen. Ansonsten denke ich, dass einige Dinge auch auf API Ebene noch multithreaded gemacht werden können, so dass es der normale Anwendungsentwickler gar nicht all zu stark mitbekommt.

[Gast]

HellHorse[/POST]']Nein Dualcore macht auf dem Desktop keinen Sinn. Aber das will niemand hören.

Sorry, aber das hängt ja wohl davon ab, was du auf dem Desktop machst. Man kann auch mehr, als nur ein Programm laufen lassen, das natürlich auch wirklich die CPU beansprucht. Bei mir tritt dieser Fall oft ein.

[svenw]

Die frage sit doch, wo sich multithread lohnt. Doch nur bei Anwendungen die die CPU für längere Zeit voll auslasten.
Was fällt einem da denn so ein: Spiele, klar da muß es erst noch kommen, Multimedia en/decodieren, da ist es schon Standart, und noch programmieren, wo man eigentlich nur das Übersetzen in einen eigenen Thread auslagern kann, und dann läßt es schon rapide nach.

Bei allen anderen Programmen kann man mal die eine oder andere aufwendige Berechnung in einen eigenen Thread legen, was nicht der enorme Aufwand sein sollte, aber ansonsten hat man nichts davon. Und bei den meisten Anwendungen wird der Vorteil weniger in der gesteigerten Geschwindigkeit liegen sondern darin, das man normal weiterarbeiten während einer der Kerne unter Vollast ackert.

Multimedia wird sich mit den neuen HD Kopierschutzmechanismen ziemlich erledigen, programmieren ist ne Minderheit bleiben noch Spiele. Da Spiele die wirklich multithreaded sind erst noch in größerer Zahl kommen, ist der momentane Nutzen eher gering. Ich schätze das so um Weihnachten herrum oder Anfang 2007 Spiele richtig profitieren werden. Momentan umsteigen lohnt nicht denn zu Weihnachten sind die Sachen wieder billiger, wenn man aber umsteigen muß dann sollte man schon 2 Kerne nehmen.

[rpm8200]

Gast[/POST]']Das finde ich sehr verwunderlich. In jedem Programmier-Anfängerbuch steht irgend etwas zur Thread Erstellung. Also wenn noch niemand Workerthreads oder asynchrone Methodenaufrufe benutzt hat, naja... :|
Natürlich braucht man das nicht in jedem Fall, aber irgendwann sollte doch jeder mal darauf stoßen. Im einfachsten Falle dann, wenn man eine Reaktionsfähige GUI braucht.

Du brauchst ja nur mal im Taskmanager oder irgend einem Prozess Explorer nachschauen wieiviele Threads so einige Prozesse haben.
... .... ....
Ansonsten denke ich, dass einige Dinge auch auf API Ebene noch multithreaded gemacht werden können, so dass es der normale Anwendungsentwickler gar nicht all zu stark mitbekommt.Du hast wohl wirklich Schwierigkeiten das was ich schreibe richtig zu interpretieren. Ich habe nicht gesagt, dass ich noch nie wtwas über ThreadErstellung gelesen/ gelernt habe. Ich schrieb dass es nicht einfach ist, multithreaded so zu programmieren, dass es Sinn macht (=dann, wenn eine CPU alleine die Last nicht bewältigen kann bzw. sich ein enormer Geschwindigkeitsvorteil ergibt wenn zwei Kerne daran arbeiten) und dass es funktioniert (voneinander unabhängige Methoden kann ja auch mein 10jähriger Neffe in verschiedenen threads aufrufen, wenn aber Abhängigkeiten vorhanden sind/ Synchronisation nötig wird, dann kann man eben Probleme damit bekommen, dass das Prog unter bestimmten Umständen sich nicht verhält wie geplant). Und ja... auf API Ebene... also ich weiss nicht, auf was Du da raus willst, aber das Kriterium "Lastet eine CPU über längere Zeit aus und muss deshalb auf zwei Kernen laufen" erfüllt ne API wohl sicher nicht.

[Gast]

rpm8200[/POST]']Ich habe nicht gesagt, dass ich noch nie wtwas über ThreadErstellung gelesen/ gelernt habe.

Ich wüsste nicht, dass ich von dir gesprochen hätte. ...restlicher wenig netter Teil entfernt

[HellHorse]

Gast[/POST]']
Aber: Die Mehrzahl der Desktopanwendungen, und darum ging es hier, bedarf überhaupt nicht so viel Rechenpower, wie wir heute haben. Insofern gibt es hier auch überhaupt gar kein Problem. Ganz im Gegenteil, diese Mehrkerne/Prozessoren teilen sich dann eben die sowieso schon vorhandenen zig Threads von zig Prozessen. Das einzige relevante Szenario ist das, wenn eine Anwendung die maximalste Prozessorleistung benötigt. Das sind aber ganz sicher keine normalen Desktopanwendungen.
Kommt darauf an. Teile der Microsoft Office Suite können ganz doll CPU Last erzeugen. Grosse Word Dokumente, grosse Excel Sheets, ... . Da smätliche JS Engines der Broswer unglaublich ineffizient sind, kann AJAX ebenfalls beträchlich auf die CPU schlagen. Die Liste geht weiter. Wie du siehst sind das Fälle, in denen DualCores auch in acht Jahren nichts bringen werden, weil sich das einfach nicht parallelisieren lässt.
Gast[/POST]']Sorry, aber das hängt ja wohl davon ab, was du auf dem Desktop machst. Man kann auch mehr, als nur ein Programm laufen lassen, das natürlich auch wirklich die CPU beansprucht. Bei mir tritt dieser Fall oft ein.
Ja, wenn man gleichzeitig gamed (t?) und transcodiert, dann bringt HTT, nein sorry Dualcores, echt viel.
Allerdings verhindert ein Schirm weit effektiver, dass es in den Hals regnet.

[Coda]

BlackBirdSR[/POST]']Warum sollte SSE2 kein superset von SSE sein?
Ist es auch. Aber die ganzen Single-Precission Instructions auf 4x32bit sind weiterhin SSE - dafür brauchst kein SSE2.

[King Rollo]

Ist es nicht so, dass Windows selbst Dual-Core / Dual-CPU untertstützt und dann verschiedene Anwendungen, die gleichzeitig laufen, automatisch auf die verfügbaren Kerne/CPUs verteilt?