x86-64 -- und was kommt danach? [Archiv]

turboschlumpf

2006-03-20, 21:08:26

x86-64 -- und was kommt danach?

Man liest ja hin und wieder, dass die x86-ISA überaus alt, oder gar vollkommen veraltet sei. Die Neuerungen des Pentium Pro waren damals, als es schon den Anschein hatte, als dass sich die Performance der x86-Prozessoren nicht mehr nennenswert weiter steigern liese, ein Geniestreich seitens Intel -- wer weiß, wie es sonst heute um x86 stünde. Und was Intel mit Conroe noch an Pro-MHz-Leistung aus der ISA herausholt ist ebenfalls beeindruckend.

Aber immer kann es so nicht weitergehen, irgendwann muss die x86-ISA von einer neuen ISA abgelöst werden. Den ursprünglichen Planungen von Intel -- wie auch immer diese ausgesehen haben mögen (ist es wirklich realistisch, dass Intel vor hatte zwei komplett neue 64-Bit-ISAs zu entwickeln?) -- hat AMD mit ihrer 64-Bit-Erweiterung wohl ganz offensichtlich einen dicken Strich durch die Rechnung gemacht. Aber ob das langfristig gesehen aus Performance- und Ressourcen-Sicht wirklich allzu sinnvoll war?

Wie sieht die Zukunft nach x86-64 aus? Setzen sich AMD und Intel an einen Tisch und entwickeln gemeinsam einen Nachfolger? Unwahrscheinlich! Versucht Intel IA64 doch noch in den Desktop-Markt zu drücken? Oder kochen AMD und Intel jeweils ihr eigenes ISA-Süppchen und es kommt zum Showdown zwischen den beiden Herstellern? Vielleicht wären untereinander inkompatible ISAs aufgrund des vermehrten Einsatzes von JIT-Compilern aber ja auch gar nicht so problematisch, wie man im ersten Moment denken könnte?

Wie wahrscheinlich ist es, dass Intel früher oder später wirklich versucht, EPIC in den Desktop-Markt zu drücken? Eventuell über einen IA32-IA64-Hybdriden? Allzu viele Transistoren benötigt so ein IA64-Core ja gar nicht. Oder arbeitet Intel schon an einer neuen ISA für den Desktop? Und ist es wirklich denkbar, dass mit der vermehrten Verbreitung von JIT-Compilern die Programme nach und nach so plattformunabhängig werden, dass ein Hersteller dies für den Versuch der Implementation einer komplett neuen ISA nutzen könnte?

Also: Wie sieht die Zukunft von x86-64 aus? Und was kommt danach?

Coda

2006-03-20, 21:22:09

Ganon

2006-03-20, 21:25:39

Naja. Die Zukunft liegt zur Zeit wohl eher in immer mehr Kernen und größeren SIMD-Einheiten.

Größere Wechsel nach IA64 oder anderen CPU-Architekturen halte ich erst mal für eher unwahrscheinlich.

OBrian

2006-03-21, 00:51:44

Ich kann mir vorstellen, daß wir mit diesem x86-64 erstmal wieder locker 20 Jahre hinkommen. Natürlich wird es diverse Erweiterungen geben, SSE4, 5, 6 usw., außerdem werden die CPUs innerlich wohl deutlichen Änderungen unterworfen werden (mehr als nur mehrere unterschiedliche Kerne).

Aber man darf nicht vergessen, daß die Abwärtskompatibilität der Hauptgrund schlechthin war, warum sich diese 64bit-Architektur so stark durchsetzt (im Gegensatz zu verschiedenen anderen, die es ja schon viel länger gibt, z.B. im DEC Alpha oder Itanium). Also wird man sich auch weiterhin schwertun, davon irgendwas über Bord zu werfen; ich halte es also nicht für unrealistisch, daß irgendwer im Jahre 2025 ein Konzept namens x86-128 aus der Schublade zieht.

Coda

2006-03-21, 01:20:30

Nach Moores Law brauchen wir 2025 noch lange keine 128 bit.

(del)

2006-03-21, 02:12:13

128 bit ist in sehr sehr weiter Ferne, ich denke x86-64 wird das Silizium-Zeitalter mindestens noch halten. Evtl. wird es in zukünftigen CPUs wirklich einen IA64 Modus geben bei Intel, aber ohne den x86-64 Modus zu streichen.

AMD wird dann womöglich nachziehen müssen. Wobei ich EPIC nun auch nicht für der Weisheits letzten Schluss halte.EPIC hat zu viel gekostet. Das wird Intel nicht einfach so einbuddeln. Wobei ich IA64, nur vom Adressraum her gesehen, nicht als besser/sinnvoller als simples AMD64 ansehe. Ich denke mir eher, Intel wird AMD samt x86-64 nun platt machen wollen. Erstmal spielen sie brav mit. Dann (wenn!) verschwindet x86-64 wie HyperThreading und man wird uns EPIC aufs Auge drücken wollen. Die Investition war und ist einfach zu groß. Alles hängt davon ab, wie AMD das Vista-Zeitalter übersteht. Intel hat einen verdammt langen Atem. Irgendwann müßen aber auch sie wieder Luft holen. Und Mickeysoft "signalisiert" gelegentlich auch mal was. Ich würd EPIC noch nicht begraben, auch wenn ich mich nicht so drauf freue.

@turboschlump
Was soll da noch kommen nach 64bit. Erstmal ne arschlange Zeit nichts. Momentan physisch 40 bit/1TB und virtuell 48 bit/256 TB. Mit dem Speicher kannst Du schon kleinere Holodecks packen ;) Bevor ich mir Gedanken mache was dann noch kommt, hätt ich lieber gefragt, wann denn endlich die 128 bit "Mediaregister" (SSE) so richtig in Fahrt kommen. IMHO kriegen wir eher neue Speichersysteme - nicht diese ulkigen Platinchen mit ICs drauf - als daß die 64 bit alle sind.

betasilie

2006-03-21, 03:26:37

128 bit ist in sehr sehr weiter Ferne, ich denke x86-64 wird das Silizium-Zeitalter mindestens noch halten.
Wie lange hält das denn noch und was kommt danach?

Ich meine bevor man ein Ende des Silziums bei den Chips sieht, muss doch erstmal ein Nachfolger in Sicht sein, und bei photonischen Strukturen kommt man nicht weiter und Quantenrechner werden in 50 Jahren vielleicht mal bei Cern stehen. Biologische Chips sind auch völlig illusorisch und sonst fällt mir jetzt gerde auch nix ein, was Silizium ablösen könnte.

Außerdem haben wir noch das Problem mit der Lichtgeschwindkeit bei immer längeren Leitung innerhalb der Chips. Ich seh schwarz. :biggrin:

BlackBirdSR

2006-03-21, 09:08:03

Wie lange hält das denn noch und was kommt danach?

Ich meine bevor man ein Ende des Silziums bei den Chips sieht, muss doch erstmal ein Nachfolger in Sicht sein, und bei photonischen Strukturen kommt man nicht weiter und Quantenrechner werden in 50 Jahren vielleicht mal bei Cern stehen. Biologische Chips sind auch völlig illusorisch und sonst fällt mir jetzt gerde auch nix ein, was Silizium ablösen könnte.

Außerdem haben wir noch das Problem mit der Lichtgeschwindkeit bei immer längeren Leitung innerhalb der Chips. Ich seh schwarz. :biggrin:

Es gibt Nanotubes, es gibt Carbid, es gibt neben Quanten/Bio- Hybride, und dann natürlich noch Sachen die man bisher nicht ins Auge gefasst hat. Irgendwas kommt schon.

Das mit der Ausbreitungsgeschw. der Signale im Chip ist auch nicht so schlimm. Wenn der Kern schnell genug schrumpft, lässt sich das Problem halbwegs in Grenzen halten.
Momentan gibt es erste Anzeichen, dass sich Asynchrone Chips eventuell etablieren könnten. Erste marktreife Chips sind schon verfügbar.

grandmasterw

2006-03-21, 09:17:00

Immer dieses Geseier von wegen veraltet. "Totgesagte leben länger" sag ich ich da nur. Da lässt sich noch einiges steigern.

Coda

2006-03-21, 12:14:53

EPIC hat zu viel gekostet. Das wird Intel nicht einfach so einbuddeln. Wobei ich IA64, nur vom Adressraum her gesehen, nicht als besser/sinnvoller als simples AMD64 ansehe. Ich denke mir eher, Intel wird AMD samt x86-64 nun platt machen wollen. Erstmal spielen sie brav mit. Dann (wenn!) verschwindet x86-64 wie HyperThreading und man wird uns EPIC aufs Auge drücken wollen. Die Investition war und ist einfach zu groß. Alles hängt davon ab, wie AMD das Vista-Zeitalter übersteht. Intel hat einen verdammt langen Atem. Irgendwann müßen aber auch sie wieder Luft holen. Und Mickeysoft "signalisiert" gelegentlich auch mal was. Ich würd EPIC noch nicht begraben, auch wenn ich mich nicht so drauf freue.Und was genau hindert AMD daran einen EPIC-kompatiblen Prozessor zu entwickeln? :|

Bevor ich mir Gedanken mache was dann noch kommt, hätt ich lieber gefragt, wann denn endlich die 128 bit "Mediaregister" (SSE) so richtig in Fahrt kommen.Wie meinst du das? Unter x64 Windows läuft sämtliches FP-Zeugs über SSE2.

Gast

2006-03-21, 12:34:20

Ich frage mich, wieso es umbedingt was neues sein muss. 32 bit Systeme haben sehr lange durchgehalten und der Umstieg auf 64 bit ist noch nicht mal softwareseitig vollzogen.

Die Performance wird sich trotz 32/64 bit in naher Zukunft um das dutzend oder gar hundertfache steigern lassen. Warum? Multicore!

Man kann entweder die Software oder die Hardware schneller machen oder beides auf einmal.

Beides ist in vollen gange. 64 bit Support ist da und wird langfristig genutzt werden, bringt schonmal einen dicken Bonus.

Dazu kommen Dual, Quad, Octacore Prozessoren (Octa = 6-8x so viel Leistung bei ansonsten gleicher Technik!). Dazu der 64 bit Bonus.

Wenn wir mal zusammenrechnen, wäre kurzfristig eine Steigerung um das 10fache möglich - mit heute schon vorhandener Technik.

Mir ist es lieber, eine Technik die gut funktioniert, zu verbessern anstatt was neues, inkompatibles herauszubringen.

Was mich jedoch interessieren würde: Wieso ging man "nur" auf 64 bit und nicht gleich auf 128, 256 bit, auch wenn es heute noch nichts bringt? Ist es technisch nicht möglich?

Coda

2006-03-21, 12:38:52

Es ist leider nicht so einfach aus Multicores softwareseitig Leistung rauszubekommen wie du anscheinend glaubst.

Was mich jedoch interessieren würde: Wieso ging man "nur" auf 64 bit und nicht gleich auf 128, 256 bit, auch wenn es heute noch nichts bringt? Ist es technisch nicht möglich?Wozu? Reichen dir 2^64 Bytes virtueller Addressraum nicht? Das wird wenn Moores Law besteht auch noch 50 Jahre reichen.

Gast

2006-03-21, 12:45:52

Es ist leider nicht so einfach aus Multicores softwareseitig Leistung rauszubekommen wie du anscheinend glaubst.

Wieso? Also Dual und Quad bringt schon heute viel, wenn unterstützt. Es liegt ausschließlich an den Entwicklern nachzuziehen.

Wozu? Reichen dir 2^64 Bytes virtueller Addressraum nicht? Das wird wenn Moores Law besteht auch noch 50 Jahre reichen.

Das verstehe ich eben nicht. Wieso nur 50 Jahre? Wieso nicht gleich auf 256 bit gehen, damits für 120 Jahre reicht? Damit wäre ein später fälliges (inkompatibles Upgrade) nicht mehr nötig.

Außerdem wird doch immer von mehr Performance gesprochen...

Ganon

2006-03-21, 12:57:57

Das verstehe ich eben nicht. Wieso nur 50 Jahre? Wieso nicht gleich auf 256 bit gehen, damits für 120 Jahre reicht? Damit wäre ein später fälliges (inkompatibles Upgrade) nicht mehr nötig.

Außerdem wird doch immer von mehr Performance gesprochen...

Leider wäre damit genau das Gegenteil der Fall. Bei 256bit-CPUs müssen entsprechend die Speicher-Adressen ja auch 256bit groß sein. Das wird ein heidenspaß wenn sich der Speicherverbrauch der Pointer mal eben vervierfacht ohne großen Nutzen.

BlackBirdSR

2006-03-21, 12:59:01

Das verstehe ich eben nicht. Wieso nur 50 Jahre? Wieso nicht gleich auf 256 bit gehen, damits für 120 Jahre reicht? Damit wäre ein später fälliges (inkompatibles Upgrade) nicht mehr nötig.

Außerdem wird doch immer von mehr Performance gesprochen...

Ich glaube du hast nicht verstanden, für was diese 32/64Bit stehen.
Das hat nichts mit der Angabe zu tun, die man immer bei Speicherbandbreiten oder so liest.
Es geht hier um die Datentypen, Adressräume und die breite der Datenpfade für ALUs.

Bisher hat man mit 32Bit großen Integerwerten gearbeitet.
Es gibt einige Fälle, in denen 64Bit Datentypen handlich sind. Aber das ist fern ab der Regel.
Mit den 64Bit kann man jetzt allerdings weit mehr Speicher ansprechen.
Z.B 2^48 Adressen. Eine ganze Menge.
2^64 ist schon gewaltig viel.
Bisherige Itanium oder Opteron können das noch nichteinmal, so weit entfernt ist das noch.

Warum also keine 128Bit?
Der Schritt auf 64Bit bringt kaum Performance beim Rechnen selbst. Nur in Fällen, wo 64Bit Datentypen durch die ALUs gehen, merkt man etwas. Das ist noch sehr selten, und ich frage mich ob wir darüber überhaupt hinauskommen in den nächsten vielen! jahren.
richtige 128Bit Integer datentypen gibt es gar nicht so wirklich, so weit ich das weiß.

Und wer braucht 128Bit Adressraum? Es erscheint mir etwas unlogisch, jedes Atom in der Galaxie adressieren zu wollen :P

Tiamat

2006-03-21, 13:07:17

Vorallem stell dir mal vor man hätte die Altbackene X86 Architektur noch im Jahre 2126 ? wär doch n Jammer wenn es bis dahin nix fortschritlicheres geben würde..

Gast

2006-03-21, 13:10:20

Das hat nichts mit der Angabe zu tun, die man immer bei Speicherbandbreiten oder so liest.

Das weiß ich.

Das ist noch sehr selten, und ich frage mich ob wir darüber überhaupt hinauskommen in den nächsten vielen! jahren.
richtige 128Bit Integer datentypen gibt es gar nicht so wirklich, so weit ich das weiß.

Das ist genau der Punkt, den ich meinte.
Du weißt es nicht, viele andere wahrscheinlich auch nicht.

Was wäre nun, wenn in 20+ Jahren 128 bit tatsächlich etwas bringen würde? Dann würde man sich in den arsch beißen, das man schon wieder ne neue Technologie einführen muss, damit es weiter geht.

Zu dem Adressraum kann ich nur sagen, das man NIEMALS so denken darf, das ein Wert der hoch erscheint, vorerst ausreichend ist - das ist er nämlich nicht, spätestens in 20-50 Jahren nicht mehr. ;)

btw: Wer braucht 640 KB?

BlackBirdSR

2006-03-21, 13:15:46

Das ist genau der Punkt, den ich meinte.
Du weißt es nicht, viele andere wahrscheinlich auch nicht.

Was wäre nun, wenn in 20+ Jahren 128 bit tatsächlich etwas bringen würde? Dann würde man sich in den arsch beißen, das man schon wieder ne neue Technologie einführen muss, damit es weiter geht.

Es ist kein Problem, die Sache dann zu erweitern, wenn man es braucht.
Es IST ein Problem, die Sache jetzt auszudehnen, bevor es auch nur einen Anflug von Nutzen bringt.
Es würde die Sache sehr verteuern, sogar verlangsamen für NICHTS.

Zu dem Adressraum kann ich nur sagen, das man NIEMALS so denken darf, das ein Wert der hoch erscheint, vorerst ausreichend ist - das ist er nämlich nicht, spätestens in 20-50 Jahren nicht mehr. ;)

Tut man doch auch nicht. Der K8 hat jetzt 40Bit mit der Option auf 52Bit. Ist doch alles in bester! Ordnung.
Wenn es dann nötig wird kann man auf 64Bit steigern. Und falls man dann wirklich höher gehen müsste, kann man das auch bewerkstelligen.
Aber glaubst du, dass es dann noch Opterons gibt?
Der Opteron ist für Alles gerüstet, was in Zukunft in dieser Sicht passieren kann.

btw: Wer braucht 640 KB?

Dass sich manche immernoch auf diesen Publicityspruch einlassen.

Coda

2006-03-21, 13:16:23

Du weißt schon dass die Kapazität mit jedem Bit nicht linear sondern exponetiell steigt? 64 Bit sind völlig ausreichend für mindestens 60 Jahre. Es wäre etwas verfehlt heute dafür schon Transistoren zu opfern vor allem weil eine Erweiterung ja immer noch möglich wäre.

Gast

2006-03-21, 13:21:08

Es ist kein Problem, die Sache dann zu erweitern, wenn man es braucht.

Nur leider ist das dann nicht das gleiche.
Wenn man erweitert, dauerts nochmal Jahre, bis ausreichend Systeme vorhanden sind.
Hätte heute schon jedes System 128 bit inne, könnten die ersten Entwickler sich schonmal damit beschäftigen und der Support wäre in ein paar Jahren überall da... bei der anderen Methode verzögert sich die Einführung nochmal um ein paar Jahre.

Da stelle ich mir auch die Frage, wieso nicht schon mit den ersten P4s 64 bit Support gebracht wurde, obwohls da schon massige andere 64 bit CPUs gab? Hatte das irgendeinen Grund?

Wäre eine 128 bit CPU eigentlich in der Lage, auch heutige 32/64 bit Software auszuführen?

BlackBirdSR

2006-03-21, 13:25:25

Nur leider ist das dann nicht das gleiche.
Wenn man erweitert, dauerts nochmal Jahre, bis ausreichend Systeme vorhanden sind.
Hätte heute schon jedes System 128 bit inne, könnten die ersten Entwickler sich schonmal damit beschäftigen und der Support wäre in ein paar Jahren überall da... bei der anderen Methode verzögert sich die Einführung nochmal um ein paar Jahre.

Warum sollte sich auch nur 1! Entwickler mit etwas beschäftigen, dass in seiner Lebzeit keinerlei! Relevanz hat?

Weder aus Performance, noch Speichersicht?
Die Chancen stehen gut, dass ich tot bin, bevor wir überhaupt so etwas in der Nähe von 128Bit Adressraum bekommen.
Vergleichen mit den Kosten ist es "völlig!" irrelevant, ob es dann nochmal 2 jahre dauert um umzusteigen. Das interessiert momentan niemanden der ein Geschäft oder eine Firma leitet. Weil es wohl keiner erleben wird.

Da stelle ich mir auch die Frage, wieso nicht schon mit den ersten P4s 64 bit Support gebracht wurde, obwohls da schon massige andere 64 bit CPUs gab? Hatte das irgendeinen Grund?

Klar, es war kein 64Bit in den CPUs. Intel wollte IA64 pushen, und sich nicht durch eine 64Bit x86 ISA Konkurrenz machen.

Wäre eine 128 bit CPU eigentlich in der Lage, auch heutige 32/64 bit Software auszuführen?

Wenn es sowas wie x86-128 wäre wahrscheinlich schon.
Aber glaubs uns, der Leistungsverlust und die zusätzlichen Kosten übersteigen den Nutzen. Denn der liegt bei 0!

BH abgemeldet

2006-03-21, 13:28:25

Und was genau hindert AMD daran einen EPIC-kompatiblen Prozessor zu entwickeln? :|Der Rückstand?

BH abgemeldet

2006-03-21, 13:43:23

Was wäre nun, wenn in 20+ Jahren 128 bit tatsächlich etwas bringen würde? Dann würde man sich in den arsch beißen, das man schon wieder ne neue Technologie einführen muss, damit es weiter geht.

Zu dem Adressraum kann ich nur sagen, das man NIEMALS so denken darf, das ein Wert der hoch erscheint, vorerst ausreichend ist - das ist er nämlich nicht, spätestens in 20-50 Jahren nicht mehr. ;)
"in 20-50 Jahren" ist ja "vorerst". Da reicht er auch.

Ja ich muß schon sagen, Du hast nicht nur uns, sondern auch allen die sich damit beruflich befassen, soviel mehr an Weißheit und weiser Voraussicht, daß es mich ebenfalls nur noch wundert, warum man die 64 bit nicht gleich übersprungen hat...

Neomi

2006-03-21, 15:16:30

Hätte heute schon jedes System 128 bit inne, könnten die ersten Entwickler sich schonmal damit beschäftigen und der Support wäre in ein paar Jahren überall da...

In ein paar Jahren? Wenn wir mal DDR2 800 als Referenz nehmen und unrealistischerweise von der theoretischen Maximalbandbreite ausgehen, dann dauert es selbst mit Dual Channel mehr als 45 Jahre, um soviel Speicher vollzuschreiben, wie man mit 64 Bit adressieren kann.

Wenn man nur mit entsprechend großen Zahlen rechnen will, dann ist der Support schon lange da. Man muß bloß eine passende BigNum-Library nutzen, schon kann man auch mit 4096 Bit oder noch größeren Zahlen rechnen.

Ganon

2006-03-21, 15:40:30

Man muß bloß eine passende BigNum-Library nutzen, schon kann man auch mit 4096 Bit oder noch größeren Zahlen rechnen.

Ich glaube in Java, Python, SmallTalk, etc. ist die Grenze der RAM. Siehe auch den 9^(9^9)-Thread von damals. ;)

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=152582

Coda

2006-03-21, 16:15:37

Der Rückstand?Ich meine im Fall, dass Intel IA64 durchdrückt. Derzeit sieht es noch lange nicht danach aus. AMD hätte von den Leuten keinerlei Probleme EPIC zu implementieren, da bin ich sicher.

HOT

2006-03-21, 17:28:30

EPIC könnte sogar deutlich leichter zu implementieren sein als die heutigen x86-RISC Hybriden, weil man die Optimierungen wieder auf die Softwareebene schiebt. Wenn ich mir Itaniums so anschaue, benötigen die allerdings offensichtlich unheimlich viele Transistoren um wirklich leistungsfähig zu sein. Meiner Meinung nach hat sich Intel mit EPIC einfach selbst überschätzt - vielleicht hat man gedacht, mit der neuen Technik der Konkurrenz eins auswischen zu können, weil man selber den besseren Fertigungsprozess hat. Aber das ist Spekulation.
Ich glaube nicht, dass die ISA Zukunft hat, denn Entwickler haben für gewöhnlich keine Zeit, um ihre Software zu optimieren. Vor allem Compiler für IA64 sind sehr komplex, oder?

Zum Thread an sich: Ich frage mich, warum sich dieser "x86 ist veraltet" Mythos so hartnäckig hält. x86 ist eine ISA, nicht mehr aber auch nicht weniger. Man hat diese schon um das erweitert, was man dringend brauchte, man sieht alleine an den Erweiterungen, wie langsam sich dort Änderungen durchsetzen. Eine ISA hat die schöne Eigenschaft, dass sie einfach nur definiert ist. Das heisst, dass man dort anbauen kann, warauf man grad Bock hat, überspitzt formuliert. Man brauchte Vektorrechnung - Zack war SSE(x) da. Man brauchte 64Bit - hui, da kam x86-64.
Und da IA32 zu wenig offene Register bot (der einzige echte Nachteil an x86), hat mit die mal eben verdoppelt und auch gleich mit da reingemixt.
Um als CPU Hersteller wirklich flexibel in seinen Entwicklungen zu sein, benötigt man meiner Meinung nach sowieso eine Kunst-ISA, die in µOps decodiert wird. Denn nur so kann man die interne ISA so anpassen wie man sie grad braucht.

Mike

2006-03-21, 17:29:58

Dürfte AMD es überhaupt implementieren?
Sie haben zwar dieses Lizenzabkommen mit Intel, aber gilt das für IA64?

Shink

2006-03-21, 17:33:25

HOT

2006-03-21, 17:38:51

IVN

2006-03-21, 17:47:05

Was liegt näher, als vorhandenes KnowHow einzusetzen? ;)
Das dürfte auf jedenfall auch die Begründung sein, warum der Core soviel schneller ist als bisherige CPUs. Für Intel wäre es natürlich Ideal, ihr Itanium Knowhow einfach hinter x86Decoder zu schieben.
Wenn man sich aber einen (hypotetischen) getweakten Yonah vorstellt, ist Conroe gar nicht Mal so stark.

-Mit getweakt meine ich einen Yonah mit groesseren Cahce,DC-Speicher (welcher auch hoch getaktet ist) und den entsprechenden FSB.

DavChrFen

2006-03-21, 18:04:45

Ich weiß nicht, aber ich glaube Intel hat die 10GHz-Marke noch nicht ganz aufgegeben(die haben ja schon irgendwo einen 9GHz-CPU gezeigt).
Genauso wenig haben sie die Einführung von IA64 in den Home-Bereich aufgegeben. Und der Itanium hat ja sogar noch einen Bereich auf der DIE, die für x86-Code zuständig ist. Wenn man das effizienter gestaltet, so dass gegenüber "normalen" x86-CPUs kein Nachteil entsteht, dann könnte man sicherlich IA64 im Heimbereich einführen.
Und das mit den vielen Cores sehe ich kritisch: vor allem einfache Schleifen kann man nunmal nicht auf mehrere Cores laufen lassen und deswegen bringt dann irgenwann die Verdoppelung der Cores nur noch minimal mehr Leistung(z.B. von 8 auf 16 cores ist dann der Leistungszuwachs nur noch 20%). Irgendwann ist da auch schluß,und ich glaube schon viel früher als manch einer denkt.

HOT

2006-03-21, 18:09:36

Wenn man sich aber einen (hypotetischen) getweakten Yonah vorstellt, ist Conroe gar nicht Mal so stark.

-Mit getweakt meine ich einen Yonah mit groesseren Cahce,DC-Speicher (welcher auch hoch getaktet ist) und den entsprechenden FSB.

Na ja, wieviel mag das bringen? Der Yonah hat wie der Dothan schon verdammt viel Cache. Ich denke, dass es zwar was bringt, aber keine 30%, sorry.

HOT

2006-03-21, 18:12:05

IVN

2006-03-21, 18:15:33

Na ja, wieviel mag das bringen? Der Yonah hat wie der Dothan schon verdammt viel Cache. Ich denke, dass es zwar was bringt, aber keine 30%, sorry.
Der Conroe hat 2x so viel Cache,und einen fast 2x schnelleren FSB.

Der schnellste Itanium leuft auf "nur"
1.7 Ghz (iirc).Seine Taktrate ist schon Steinzeit wenn man sie mit der von aktuelen PC-CPUs vergleicht,und trotzdem schaft es der Itanium2 unglaubliche "Kraft" zu entwickeln.
p.s. die Verdoppelung beim P4 (von 1 auf 2 MB) brachte nichts weil die Latenz stark gestiegen ist.

Coda

2006-03-21, 18:16:57

Dürfte AMD es überhaupt implementieren?
Sie haben zwar dieses Lizenzabkommen mit Intel, aber gilt das für IA64?Die Kartellwächter würden schon dafür sorgen.

p.s. die Verdoppelung beim P4 (von 1 auf 2 MB) brachte nichts weil die Latenz stark gestiegen ist.Trotzdem Unsinn. Der Unterschied würde trotzdem höchstens 10% betragen.

betasilie

2006-03-21, 18:19:25

Die Kartellwächter würden schon dafür sorgen.
Meinst Du? Wenn diese Aussage pauschal gelten würde, könnte jede Architektur von anderen kopiert werden, was aber nicht der Fall ist.

HOT

2006-03-21, 18:20:42

Meinst Du? Wenn diese Aussage Pauschal gelten würde, könnte jede Architektur von anderen kopiert werden.

Die besondere Marktsituation gibt Coda da wohl recht. AMD dürfte schon lange nicht mehr existieren, wenn es das Kartellrecht nicht gäbe ;)

IVN

2006-03-21, 18:25:54

Die Kartellwächter würden schon dafür sorgen.

Trotzdem Unsinn. Der Unterschied würde trotzdem höchstens 10% betragen.
Der Prescott vieleicht.Da dieser auf eine hoche Latenz getrimmt worden ist.(L1 Cache) Der Northwood sollte aber staerker davon profitieren.

HOT

2006-03-21, 18:27:46

Der Prescott vieleicht.Da dieser auf eine hoche Latenz getrimmt worden ist.(L1 Cache) Der Northwood sollte aber staerker davon profitieren.

Eine Netbrust Architektur würde eher davon profitieren als eine Dothan architektur. Die ist eben extra so designt, dass der Speicher ruhig langsamer sein darf und die CPU trotzdem schnell ist. Zudem profitiert ein Northwood mehr von mehr cache als der Prescott, siehe Gallatin gegen Prescott 2M.

betasilie

2006-03-21, 18:34:06

Die besondere Marktsituation gibt Coda da wohl recht. AMD dürfte schon lange nicht mehr existieren, wenn es das Kartellrecht nicht gäbe ;)
Ok, aber kann man das pauschal so sagen?

Ich meine, wenn jede Firma per Kartellgericht einklagen könnte Architekturen erfolgreicher Firmen zu kopieren, dann wäre das doch ein Witz. Es gibt genug Prozzis, die nicht ohne Lizenz gefertigt werden dürfen und wieso sollte das bei IA64 anders sein? Dann könnte man auch IBM/Soyn dazu zwingen, den Cell für andere Firmen freizugeben, oder ähnlich.

HellHorse

2006-03-21, 18:42:25

Es ist leider nicht so einfach aus Multicores softwareseitig Leistung rauszubekommen wie du anscheinend glaubst.
Vergiss es, Leute die noch nie ein nebenläufiges nicht-Server Programm (oder überhaupt irgend ein Programm) geschrieben haben, welches annähernd linear mit der Anzahl Prozessoren skaliert haben einfach mehr Ahnung als du! Denn im Gegenstatz zu dir können sie Press Releases glauben oder schreiben.

betasilie

2006-03-21, 18:44:32

Es ist leider nicht so einfach aus Multicores softwareseitig Leistung rauszubekommen wie du anscheinend glaubst.
Das behauptest Du schon lange. Und immer wieder gibt es kompetente Leute, die meinen, dass Du falsch liegst.

Bokill

2006-03-21, 18:57:39

Der Rückstand?Welcher Rückstand? AMD hatte Patente von Intergraph lizensiert, die auch eine Implementierung einer speziellen ISA namens "PIC" vorsahen ...

Mit eben diesen Intergraph-Patenten (und manch anderen) musste Intel ziemlich viel in Prozessen bluten, weil EPIC in vielfacher Hinsicht den Ideen von "PIC" ähnelten.

Nachteilig für alle anderen Wettbewerber (bis auf Mitentwickler HP) war aber, dass die alten Cross Licence Verträge zu x86 hinfällig waren bei der ISA EPIC mit der EPIC Plattform Itanium.

Neben dem technischen Grund (Hoffnungen mit einer neuen Architektur deutlich mehr Leistung bekommen), gab es einen geschäftlichen Grund auf die EPIC Plattform mit dem Itanium zu setzen.

Bis auf Sun haben sich damals auch alle grossen Tiere auf EPIC als Nachfolgestandard zu x86 geeinigt. Zu dumm nur, dass der Markt sich deutlich anders entwickelte, bzw. die Alternative AMD64 als gut genug von einstmaligen Itanium-Partnern aufgegriffen wurde.

MFG Bobo(2006)

Bokill

2006-03-21, 19:05:02

... ein Geniestreich seitens Intel -- wer weiß, wie es sonst heute um x86 stünde. ... Auch andere hatten schon früh die Idee mit einem RISC-Kern einen x86 kompatiblen Prozessor zu bauen. Das war das Projekt rund um NexGen und erschienen sogar schon früher damit auf den Markt als der PentiumPro ... also nix mit Geniestreich ...

MFG Bobo(2006)

HOT

2006-03-21, 19:35:09

Auch andere hatten schon früh die Idee mit einem RISC-Kern einen x86 kompatiblen Prozessor zu bauen. Das war das Projekt rund um NexGen und erschienen sogar schon früher damit auf den Markt als der PentiumPro ... also nix mit Geniestreich ...

MFG Bobo(2006)

Daraus erwuchs der K6 :)

(del)

2006-03-21, 21:01:11

Daraus erwuchs der K6 :)
Ich dachte eher die FPU des K7...

Bokill

2006-03-21, 21:21:51

@HOT
@BessereHälfte

Schaut mal da rein -> "Eine kleine Historie zu NexGen, Atiq Raza ... AMD Sockelwechseln (http://www.orthy.de/modules.php?name=News&file=article&sid=1541)" [orthy.de].

MFG Bobo(2006)

Coda

2006-03-21, 22:26:26

Das behauptest Du schon lange. Und immer wieder gibt es kompetente Leute, die meinen, dass Du falsch liegst.Nirgends wurde jemals von Demirug, Xmas oder sonst einem der "kompetenten" Leute behauptet das Multithreading einfach sei. Ich glaube du verwechselst da etwas.

Es gibt Fälle da ist es relativ leicht (Man schaut die Software an und die Parallelsierbarkeit springt einem ins Auge, z.B. bei einem Raytracer), es gibt deutlich mehr Fälle da ist es wirklich schwer und es gibt auch viele Fälle wo es unmöglich ist.

Hol dir nen Compiler, lern programmieren und bilde dir deine eigene Meinung - ich weiß von was ich rede.

Abendlektüre: http://en.wikipedia.org/wiki/Amdahls_Law
Ich machs dir einfach und zitiere:
In the special case of parallelization, Amdahl's law states that if F is the fraction of a calculation that is sequential (i.e. cannot benefit from parallelisation), and (1 − F) is the fraction that can be parallelised, then the maximum speedup that can be achieved by using N processors isEs gibt wirklich genug Dinge die sich nicht parallelisieren lassen, entweder ihr bekommt das in eure Köpfe oder ihr lasst es bleiben.

Und es wird sogar noch besser:
As an example, if F is only 10%, the problem can be sped up by only a maximum of a factor of 10, no matter how large the value of N used. For this reason, parallel computing is only useful for either small numbers of processors, or problems with very low values of F: so-called embarrassingly parallel problems. A great part of the craft of parallel programming consists of attempting to reduce F to the smallest possible value.Ja schöne neue Multicore-Welt. Die Lösung all unserer Probleme :rolleyes:

Nicht das mich jemand falsch versteht: Ich hab selber einen Multicore und optimiere meine Software darauf, aber ich bin eben realistisch.

Kein Spiel der Welt wird aus n-Prozessoren die n-fache Leistung ziehen können, wahrscheinlich wird die Parallelisierbarkeit im besten Fall bei 50% liegen, das macht bei 2 Prozessoren dann einen Gewinn von 33%, bei 4 Prozessoren nur 60%, 8: 77%, 100: 98% (ja es konvergiert gegen 100%, mehr is da nicht egal wieviel Prozessoren es sind) - und das auch nur wenn man von einer optimalen Architektur ausgeht die es nicht gibt.

Neomi

2006-03-22, 00:40:23

Kein Spiel der Welt wird aus n-Prozessoren die n-fache Leistung ziehen können, wahrscheinlich wird die Parallelisierbarkeit im besten Fall bei 50% liegen, das macht bei 2 Prozessoren dann einen Gewinn von 33%, bei 4 Prozessoren nur 60%, 8: 77%, 100: 98% (ja es konvergiert gegen 100%, mehr is da nicht egal wieviel Prozessoren es sind) - und das auch nur wenn man von einer optimalen Architektur ausgeht die es nicht gibt.

In vielem hast du zwar Recht, aber ein wenig mehr Optimismus wäre nicht verkehrt. Sicher gibt es vieles in heutigen Spielen, was man nicht parallelisieren kann. Trotzdem kann man noch einiges zusätzlich reinpacken, was momentan noch nicht realisierbar ist.

Wie wäre es beispielsweise mit Photon Mapping? Dieses und nächstes Jahr sicher nicht, aber wenn irgendwann von 1024 Cores noch 1012 arbeitslos sind, kann man es ja mal drauf ankommen lassen. Auf Vertexbasis läßt sich da bestimmt noch einiges an Qualität rausholen. Endlich läßt ein vorbeifahrendes rotes Auto eine weiße Hauswand leicht rötlich schimmern, dynamische Objekte integrieren sich wesentlich besser in die Landschaften. Oder auch die Berechnung von hunderten Shadowmaps per Softwarerasterizer. Zumindest gibt es immer die Möglichkeit, die Hardware zu beschäftigen und die Wohnung zu beheizen... :D

Letztendlich bleibt natürlich alles an dem Thread hängen, der die Ergebnisse der einzelnen Jobs zusammenfassen muß.

Coda

2006-03-22, 00:44:56

OK, seien wir mal etwas optimistischer und gehen wir von 66% aus, dann ist die maximal Steigerung der Faktor 3 (bei Quad-Core maximal Faktor 2). Selbst bei 80% kommt man nur auf Faktor 5.

Lustig, nicht?

Du hast schon recht, dass man die Cores mit Arbeit die dafür geeignet ist vollpumpen kann, aber wenn es eben an etwas seriellem hakt, dann bringen einem auch 100 Cores nix. Und für gerade diese Probleme ist die GPU doch oft sowieso viel geeigneter.

Multi-Cores passen einfach nicht in die Problemlösungsklasse "scheiß auf den Algorithmus, wenn er zu langsam läuft werfen wir Hardware danach" und damit sind sie einfach nicht die von vielen propagierte endgültige Performancelösung.

Quad-Cores werden es vermutlich in vielen Benchmarks schon sehr schwierig haben sich ggü. Dual-Cores einen klaren Vorteil zu verschaffen, aber bei Octa-Cores wird es für die CPU-Hersteller langsam echt kritisch werden die Käufer vom Sinn davon zu überzeugen (es sei denn wir reden von inhärent parallelisierbar Programmen wie 3D-Rendering - aber wer macht das schon? Für Video-Encoding wird es evtl. noch am ehesten Anklang finden).

Verdammt. Wieso skaliert der Silizium-Kack nicht einfach bis 100Ghz und alles wär gut :usad:

Neomi

2006-03-22, 01:52:34

OK, seien wir mal etwas optimistischer und gehen wir von 66% aus, dann ist die maximal Steigerung der Faktor 3 (bei Quad-Core maximal Faktor 2). Selbst bei 80% kommt man nur auf Faktor 5.

Lustig, nicht?

Jep, sicher ist das so. Es gibt einige Dinge, die schwer zu parallelisieren sind, aber nur wenige, die gar nicht parallelisierbar sind. Bei heutigen Spielen fallen mir da solche Dinge ein...

Physik: erstmal müssen alle beweglichen Objekte, die untereinander kollidieren können, in mehrere "kollidieren möglicherweise"-Gruppen geteilt werden. Jede dieser Gruppen kann dann unabhängig von den anderen ausgewertet werden. OK, größere Objektstapel (wie die immer wieder beliebten Pyramiden oder Mauern) würden in einer großen Gruppe landen, da wird es schon schwieriger. Aber auch da ist die Kollision von jeweils zwei Objekten getrennt von den anderen Kollisionen zu berechnen, danach muß "nur" (ich weiß, daß ist der eigentlich schwierige Teil) noch der Solver ran und die Wechselwirkungen an den berechneten Kontaktpunkten austüfteln.

KI: jeder Gegner sollte seine Entscheidungen nur von der jeweiligen Spielsituation abhängig machen und nicht die Gedanken der anderen Gegner lesen, also kann auch jeder unabhängig berechnet werden. Das funktioniert sogar in einer Team-KI, wenn nur Kommandos ausgetauscht werden und eine Reaktionszeit von ein paar Millisekunden (eben erst im nächsten Durchlauf) eingeräumt wird.

Sound: wenn eine Engine ihren Sound per Software berechnet (wie Doom 3, zumindest am Anfang), dann muß jeder Kanal unabhängig von den anderen berechnet werden. OK, kein echter Rechenzeitfresser, aber es geht prinzipiell.

Streaming: bei größeren Spielwelten lassen sich Sektoren, die wahrscheinlich bald in Sichtweite kommen, schonmal im Vorraus laden. Die Ressourcenerstellung (Vertex- und Indexbuffer, Texturen) ist ja zum Glück nicht auf einen Thread beschränkt.

Grafiksupport: spekulative Sichtbarkeitsprüfung, evtl. mit einer gewissen Sichtbarkeitswahrscheinlichkeit. Wenn sich z.B. für ein Objekt im Vorraus sagen läßt, daß es nicht sichtbar werden kann, weil der Spieler sich bis dahin maximal einen Meter bewegen kann, ist das gut. Bei 60% Wahrscheinlichkeit (dafür, daß es sichtbar ist) kann einfach gezeichnet werden, darunter vielleicht noch per Schnelltest geprüft werden. Objekte können schonmal vorsortiert werden, Objekte ohne Alphablendinganteil in Gruppen nach Typ zusammengefaßt werden (für weniger Statechanges).

Übliches: sogar die Sortierung eines einzigen Arrays kann auf mehrere Cores aufgeteilt werden. Das ist dann zwar kein In-Place-Sorter mehr und lohnt sich wegen des Overheads erst ab einer bestimmten Größe, aber möglich ist es.

Eigentlich wollte ich nicht soviel dazu schreiben, aber mir kommen ständig neue Ideen. So viele Ideen, so wenig Zeit.

Du hast schon recht, dass man die Cores mit Arbeit die dafür geeignet ist vollpumpen kann, aber wenn es eben an etwas seriellem hakt, dann bringen einem auch 100 Cores nix. Und für gerade diese Probleme ist die GPU doch oft sowieso viel geeigneter.

Wenn man mit einem Core nur doppelt so lange braucht wie mit vier, dann verdoppelt man eben die Rechenlast mit leicht parallelisierbaren Aufgaben. Vier Cores sind dann zwar nicht schneller als vorher, aber immerhin vier mal so schnell wie ein einzelner Core mit der zusätzlichen Rechenlast. Ist dann zwar nicht wirklich toll, sieht für den Laien aber nach effizienter Programmierung aus. :D

Die Dinge, an denen sich wirklich nichts drehen läßt, sind zum Glück eher selten. Vielleicht findet sich ja auch für das ein oder andere "unteilbare" Problem eine Alternative, die zwar doppelt so viel berechnen muß, das aber in vier Teilen schafft und auf Quadcores dann doppelt so schnell ist.

Multi-Cores passen einfach nicht in die Problemlösungsklasse "scheiß auf den Algorithmus, wenn er zu langsam läuft werfen wir Hardware danach" und damit sind sie einfach nicht die von vielen propagierte endgültige Performancelösung.

Endgültige Lösungen gibt es nie, Parallelisierung (soweit möglich) ist eben die neue Herausforderung für die absehbare Zukunft. Aber ich mag Herausforderungen (wenn doch nur genug Zeit wäre) und freue mich schon richtig auf die Quadcores.

Coda

2006-03-22, 01:56:53

Ich schätze den Anteil an unparallelisierbaren Dingen eben größer - und vor allem den Willen der Entwickler soviel Zeit auf Parallelisierung zu verwenden kleiner ein als du.

Hälst du weniger als 20% Rechenzeit auf unparallelisierbarem Code bei 30FPS wirklich für realistisch? Evtl. täuscht mich ja wirklich mein Instinkt bei der ganzen Sache.

Vor allem wird der Knick mit größerem N in der Amdahl-Kurve (von F=0 bis 1) natürlich immer krasser und damit muss F auch immer kleiner werden um noch einigermaßen was aus den vielen Cores rauszuholen.

Endgültige Lösungen gibt es nieKlar. Taktskalierung hat überall funktioniert

Neomi

2006-03-22, 02:16:00

Ich schätze den Anteil an unparallelisierbaren Dingen eben größer - und vor allem den Willen der Entwickler soviel Zeit auf Parallelisierung zu verwenden kleiner ein als du.

Als Programmierer ist man in der Spielebranche (quasi genau mein Gebiet) falsch, wenn man nicht bereit ist, neue Dinge auszuprobieren. Den Job kann man eigentlich nur dann richtig gut machen, wenn man Spaß dran hat, und dann ist auch die Motivation da. Am Willen scheitert es nicht, aber leider an der verfügbaren Zeit. Deshalb werden einige Dinge nicht umgesetzt werden, die zwar technisch, aber nicht zeitlich möglich sind.

Hälst du weniger weniger als 20% Rechenzeit auf unparallelisierbarem Code bei 30FPS wirklich für realistisch? Evtl. täuscht mich ja wirklich mein Instinkt bei der ganzen Sache.

Weniger als 20% ist extrem schwierig, aber nicht unlösbar. Nur muß die Engine von Anfang an darauf ausgelegt sein, nachträgliches Umbasteln an einer bestehenden Engine (was leider auch oft nötig ist, da die Zeit für komplette Neuentwicklungen fehlt) wird solche Regionen nicht erreichen können.

Machbar halte ich mit kurzem Umstrukturieren 80%, mit intensivem Nachdenken und einem Hauch von Zeit 60%, mit genug verfügbarer Zeit und richtigem Einsatz vielleicht 40%. Alles darunter erfordert dann schon eine Berücksichtigung ab Grundsteinlegung und ordentliche Erfahrung mit Threads.

Vor allem wird der Knick mit größerem N in der Amdahl-Kurve (von F=0 bis 1) natürlich immer krasser und damit muss F auch immer kleiner werden um noch einigermaßen was aus den vielen Cores rauszuholen.

Solange nicht die Leistung einzelner Cores drastisch sinkt, um die Anzahl zu erhöhen, sollte alles weiterhin ausreichend schnell laufen, was schon vorher lief. Im schlimmsten Fall bleibt eben verfügbare Rechenkraft ungenutzt, wenigstens werden die Spiele dann nicht mehr von Firewall, Antivirenscanner und ähnlichen Dingen ausgebremst, die bei normalen Anwendern ja oft im Hintergrund laufen.

Klar. Taktskalierung hat überall funktioniert

Taktskalierung würde zwar für alle Programme funktionieren, aber leider funktioniert Taktskalierung an sich nicht mehr. Deshalb müssen wir ja ausweichen.

Coda

2006-03-22, 02:18:38

Als Programmierer ist man in der Spielebranche (quasi genau mein Gebiet) falsch, wenn man nicht bereit ist, neue Dinge auszuprobieren. Den Job kann man eigentlich nur dann richtig gut machen, wenn man Spaß dran hat, und dann ist auch die Motivation da. Am Willen scheitert es nicht, aber leider an der verfügbaren Zeit. Deshalb werden einige Dinge nicht umgesetzt werden, die zwar technisch, aber nicht zeitlich möglich sind.Ja hast wohl recht. Aber das ändert auch nichts am Problem.

Weniger als 20% ist extrem schwierig, aber nicht unlösbar. Nur muß die Engine von Anfang an darauf ausgelegt sein, nachträgliches Umbasteln an einer bestehenden Engine (was leider auch oft nötig ist, da die Zeit für komplette Neuentwicklungen fehlt) wird solche Regionen nicht erreichen können.

Machbar halte ich mit kurzem Umstrukturieren 80%, mit intensivem Nachdenken und einem Hauch von Zeit 60%, mit genug verfügbarer Zeit und richtigem Einsatz vielleicht 40%. Alles darunter erfordert dann schon eine Berücksichtigung ab Grundsteinlegung und ordentliche Erfahrung mit Threads.Siehst du. Und selbst bei 20% bekommen wir mit nem Quadcore gerade mal die 2,5x Rechenleistung. Ziemlich traurig finde ich.

Aber vorgerechnet habe ich jetzt ja schon genug. Es ist einfach so dass die Beschleunigung weit geringer ausfällt als man zunächst vermuten würde.

Solange nicht die Leistung einzelner Cores drastisch sinktGenau das machen die Videokonsolen, aber das ist ein anderes Thema *hust*

Vor allem Cell ist in dem Hinblick ja wirklich übel.

Taktskalierung würde zwar für alle Programme funktionieren, aber leider funktioniert Taktskalierung an sich nicht mehr. Deshalb müssen wir ja ausweichen.Weiß ich, weiß ich...

Es geht mir ja auch eher darum, dass die Leute hier verstehen dass man eben nicht einfach das Program wundersamerweise auf Multicore optimiert und man dann mal eben n-fache Leistung raus bekommt ;)

Neomi

2006-03-22, 02:29:22

Quad-Cores werden es vermutlich in vielen Benchmarks schon sehr schwierig haben sich ggü. Dual-Cores einen klaren Vorteil zu verschaffen, aber bei Octa-Cores wird es für die CPU-Hersteller langsam echt kritisch werden die Käufer vom Sinn davon zu überzeugen (es sei denn wir reden von inhärent parallelisierbar Programmen wie 3D-Rendering - aber wer macht das schon? Für Video-Encoding wird es evtl. noch am ehesten Anklang finden).

Der Hauptgrund, weshalb ich auf mehrere Cores scharf bin, ist ein Editor (bzw. mehrere), an dem ich schon einige Zeit bastle. Streulichtberechnung für Landschaften, Normalmaps für Objekte (Raycasting von Lowpoly mit Mapping in Highpoly Referenzmodell), Komprimierung von großen Mengen an Texturen, ...

Da will ich irgendwann noch eine ordentliche Jobverwaltung für bauen, inklusive automatischem Freischalten abhängiger Jobs (bzw. teilweise Freischaltung, einer kann ja von vielen anderen abhängig sein) nach jeder Vollendung.

Neomi

2006-03-22, 02:34:43

Es geht mir ja auch eher darum, dass die Leute hier verstehen dass man eben nicht einfach das Program wundersamerweise auf Multicore optimiert und man dann mal eben n-fache Leistung raus bekommt ;)

Oh ja, solche "Forderungen" mag ich auch besonders. Wer daran glaubt, hat wohl noch nie selbst richtig programmiert. Dann gibt es da aber auch noch die Meinungen, daß Dualcore in Spielen nicht mehr als 20% bringen kann, weil das (Beweis durch Beispiel) bei dem und dem und dem Spiel so ist. Klingt komisch, habe ich aber selbst schon irgendwo gelesen.

#44

2006-03-22, 07:26:16

Sicher lassen sich bestehende spiele / programme nur bedingt beschleunigen... aber durch dc/mc besteht doch sicher die möglichkeit das was man schon hat (zb ki) dann so zu programmieren das es als eigener thread läuft, und für sich viel leistungsfähiger ist als eine ki die nur nebenher auf nem sc berechnet wird, oder etwa nicht? (meine programmierkentnisse sind in dem bereich noch nit ausreichend, aber man darf ja mal vermuten)

und in dieser verbesserung sehe ich die vorteile, da einzelne programmteile jetzt wesentlich rechenlastiger sein können ohne das die mhz zahl eine cpu sich drastisch steigern müsste... durch multicore sinkt ja wie schon gesagt eher die taktfrequenz des einzelnen

(und das man so schnell über ne gewisse core anzahl hinauskommt halte ich sowieso für unwarscheinlich)

#44

2006-03-22, 07:56:45

noch ne sehr wichtige frage dazu:
bezieht sich das gesetz nicht auf die parallelisierbarkeit EINES ALGORITMUS?

das würde dann heißen (da ki, physik, gameengine usw) das gerade bei spielen ein deutlicherer leistungsgewinn möglich ist da ja nicht ein algorithmus paralellisiert wird sondern mehrere algorithmen von verschiedenen einheiten berechnet werden... (sonst würden gpu und ppu ja schließlich auch nicht so deutliche leistungssteigerungen zulassen indem nur ein teil der berechnung ausgelagert wird...)

ich bin mir atm ziemlich sicher das das so ist...

was also den geschwindigkeitsgewinn für den einzelnen algortihmus angeht ist das wirklich wenig... aber dadurch das eben nicht nur ein algorithmus geteilt sondern ein ganzer programmteil ausgelagert wird (siehe bsp graka) müssten doch viel größere gewinne drinn sein.

ich bring mal einen meiner sehr abstrakten vergleiche: haus bauen(bzw mauer)
wenn nun n arbeiter verwendet werden die gemeinsam ziegelsteine (immer einzelne steine und beide immer am selben stein)(stellt die algorithmen dar) auf die mauer setzen ist der gewinn der leistung klar keine verdopplung... wenn aber jeder an einem anderen mauerteil arbeitet (physik, ki) dann ist der leistungsgewinn maximal eine ver-n-fachung der einzelleistung

so lege ich das gesetz aus, und denke auch das es so richtig ist
denkt mal drüber nach

Ganon

2006-03-22, 08:52:34

Hmm...

Gerade eine KI sollte doch massiv Cores fressen, oder nicht? Ich meine, warum haben rundenbasierende Spiele meist eine sehr gute "KI"? Ganz einfach weil die CPU genug Zeit hat die Lage zu analysieren und dann entsprechend zu reagieren.

Das geht in Echtzeit-Spielen natürlich (noch) nicht. Die Entscheidung der CPU-Spieler muss sich im Millisekunden-Bereich bewegen.

Was müsste die CPU berechnen, um halbwegs gute Entscheidungen in "Echtzeit" zu lösen?
- Eigene Situation (Gesundheitszustand, Munitionsvorrat)
- Umgebung (Fluchtmöglichkeit, Deckung, Andere CPU-Spieler die helfen könnten)
- Interaktionsmöglichkeit (Gegenstände im Raum die man nutzen könnte, z.B. Feuerlöscher)
- Aktionen mit anderen CPU-Spielern koordinieren
- Entscheidungsfindung (schießen, wegrennen, ducken, etc.)

Diese Sachen könnte alle parallel laufen, denke ich, da unser Gehirn das ja auch nicht viel anders macht. Das ist sicher nicht leicht, aber denkbar.

In den heutigen Spielen merkt man schon das die KI einfache Skripte sind, die bestimmte Aktionen unwiderruflich ablaufen lassen. Zum Beispiel (jetzt mal PerfectDark/N64) schießt du einem Gegner die Waffe aus der Hand, dann steht er erst mal dumm da. Dann sucht er die Waffe und hebt sie gemütlich auf. Da kann ich auch noch so lange vor ihm stehen und um ihn rum schießen, der denkt nicht mal dran, wegzulaufen. Ergebnis -> Kanonenfutter.

Nun. Unabhängig davon könnte man mehrere CPU-Kerne nutzen, um fehlende Hardware-Eigenschaften in der CPU nachbilden zu können. Z.B. wenn die Grafikkarte jetzt eben diese Technik nicht intus hat, dann wird diese eben in der CPU nachgebiltet. Klar, ist das langsamer, aber bei mehreren Cores (8-16 mit SIMD-Einheit) sicher ausreichend.

Coda

2006-03-22, 12:47:22

bezieht sich das gesetz nicht auf die parallelisierbarkeit EINES ALGORITMUS?Nein. Auf das ist auch auf die Erzeugung eines kompletten Frames eines Spiels übertragbar, bzw auf eine beliebige Zeitspanne in einem Programm. Aber wenn du versuchst auf dieser Basis weiterzustreiten werde ich mich nicht drauf einlassen, das ist mir echt zu blöd.

Gerade eine KI sollte doch massiv Cores fressen, oder nicht? Ich meine, warum haben rundenbasierende Spiele meist eine sehr gute "KI"? Ganz einfach weil die CPU genug Zeit hat die Lage zu analysieren und dann entsprechend zu reagieren.Das kommt wie immer auf den verwendeten Algorithmus an ob es sich überhaupt auf mehrere Cores verteilen lässt.

Man muss sich halt jetzt oft was neues einfallen lassen, daran wird sich evtl. auch das Gameplay in Zukunft orientieren obwohl es uns natürlich nicht direkt auffällt, weil wir die Single-Core-Version davon ja nicht kennen werden.

Nun. Unabhängig davon könnte man mehrere CPU-Kerne nutzen, um fehlende Hardware-Eigenschaften in der CPU nachbilden zu können. Z.B. wenn die Grafikkarte jetzt eben diese Technik nicht intus hat, dann wird diese eben in der CPU nachgebiltet. Klar, ist das langsamer, aber bei mehreren Cores (8-16 mit SIMD-Einheit) sicher ausreichend.Das kannst aus verschiedensten Gründen vergessen.

Gast

2006-03-22, 13:01:50

Nein. Auf das ist auch auf die Erzeugung eines kompletten Frames eines Spiels übertragbar, bzw auf eine beliebige Zeitspanne in einem Programm. Aber wenn du versuchst auf dieser Basis weiterzustreiten werde ich mich nicht drauf einlassen, das ist mir echt zu blöd.

1. das war ne frage und noch lange keine streitbasis...
2. ist nein (in diesem fall) eine unbegründete behauptung

Denn algorithmus = verfahren ein problem zu lösen
und ein game besteht aus verdammt viele algorithmen. selbst etwas "einfaches" wie die wegfindung besteht aus mehreren algorithmen

wieso sollte das zu blöd sein? weil du evtl was falsch verstehst/verstanden hast und nicht glaubst ich könnte das besser verstehen?
(siehe punkt 2.... ich sage ja nicht das ich es besser verstehe aber wenn dann begründe doch warum ich unrecht habe)

Coda

2006-03-22, 13:02:47

Gast

2006-03-22, 13:07:36

Ein Algorithmus ist eine abstrakte Formulierung für einen Programmablauf. Auch die Erzeugung eines kompletten Frames ist ein "Algorithmus".

Amdahl's Law passt dort genauso, weil die seriellen Elemente genauso limitieren. Die Formel kannst du dir mit etwas Logik selbst herleiten.

Wenn eben 20ms für einen Frame brauchst, dann können wenn du 50% davon parallelisieren kannst halt maximal 10ms hinten rauskommen (für N gegen unendlich - N Anzahl Prozessoren).

also das mit dem algorithmus stimmt nicht... denn soviel ich weiss ist ein algorithmus eine befehls abfolge um ein spezielles problem zu lösen
zb wie komme ich von a nach b (wegfindung)
/merke grad das du auch mehr oder weniger das gemeint hast
aber der erzegung eines frames geht wesentlich mehr vorraus als nur berechnung von farben... und das sind auch alles algorithmen

Coda

2006-03-22, 13:10:49

Du verstehst mich nicht. Ich meine die komplette CPU-Leistung die erbracht werden muss zur Erzeugung eines Frames. Die "Farben" macht sowieso die GPU.

Das lässt sich mit Sicherheit auf jede Laufzeitspanne eines jeglichen Programms übertragen, du must nur mal drüber nachdenken anstatt es einfach mal grundsätzlich in Frage zu stellen.

#44

2006-03-22, 13:15:45

Mal was anderes... es gibt ja schon genug beispiele wo sowas praktiziert wird...
zb grafikberechnung und da sind leistungssteigerungen über 100% mit 1 zusätzlichen prozessor (gpu) schon heute möglich.
oder das netzwerk das nach ausserirdischem leben im all sucht (läuft übers inet und jeder kann mit der gratis sw mitmachen) da kriegt auch jeder nen teil der aufgabe... und etz sag nicht das die leistung nicht über 100% gesteigert ist
aktuelle superhochleistungs rechner... auch die sind vernetzte einzelne einheiten

Glaubst du wirklich das das alles praktiziert werden würde wenn parallelisierung nicht klappen würde?

ich gebe zu für den einzelnen algoritmus gilt das gesetz...
aaaaber ein game IST KEIN EINZELNER ALGORITHMUS (das kann ich sogar mit meinen bescheidenen programmierkenntnissen sagen, da grundwissen)

Coda

2006-03-22, 13:21:29

Glaubst du wirklich das das alles praktiziert werden würde wenn parallelisierung nicht klappen würde?In den Fällen ist F ja ziemlich nahe 0.

Ich habe übrigens nirgends behauptet dass Parallelisierung nicht funktioniert - sonst würde ich es wohl kaum selber machen. Nur der maximale Gewinn ist nunmal oft sehr begrenzt.

es sei denn wir reden von inhärent parallelisierbar Programmen wie 3D-Rendering - aber wer macht das schon? Für Video-Encoding wird es evtl. noch am ehesten Anklang findenDu ließt meine Postings ja sowieso nicht anscheinend.

ich gebe zu für den einzelnen algoritmus gilt das gesetz...
aaaaber ein game IST KEIN EINZELNER ALGORITHMUS (das kann ich sogar mit meinen bescheidenen programmierkenntnissen sagen, da grundwissen)Das gilt für beliebige Zeitbereiche eines Programmes. In der Informatik redet man immer von Algorithmus wenn es um Theorie geht.

EOD

Gast

2006-03-22, 13:30:19

Das gilt für beliebige Zeitbereiche eines Programmes. In der Informatik redet man immer von Algorithmus wenn es um Theorie geht.
EOD

Doch ich lese dein postings und alles was mich daran bis jetzt stört ist deine definition von algorithmus.

du gibst zu das das für grafik gilt... aber auch die grafik ist teil des spiels und nichts externes. ich sehe hier übrigens einen wiederspruch
würde man deine logik fortführen (auch grafik ist ein zeitbereich eines programms) hieße das das mit einer graka max 66% mehrleistung drinn wären

das ist aber defakto nicht so, was allein mir grund gibt dir zu wiedersprechen

http://de.wikipedia.org/wiki/Algorithmus <-- lies das mal

Ganon

2006-03-22, 13:37:05

Das kommt wie immer auf den verwendeten Algorithmus an ob es sich überhaupt auf mehrere Cores verteilen lässt.

Naja. Das man in dem Fall mit den altbekannten Algos nicht mehr weit kommt, dürfte klar sein. ;)

Man muss sich halt jetzt oft was neues einfallen lassen, daran wird sich evtl. auch das Gameplay in Zukunft orientieren obwohl es uns natürlich nicht direkt auffällt, weil wir die Single-Core-Version davon ja nicht kennen werden.

Naja. Es ist ja bekannt das etwas nur solange der Wahrheit entspricht, bis es jemand das Gegenteil bewiesen hat. ;)

Klar. Es muss für alles entsprechend auch genug zu berechnen geben. Weil sonst lohnt sich entsprechender Overhead für das Multi-Threading nicht. Ich brauch z. B. in einer Physik-Engine nicht die Welt in Teile teilen und voneinander unabhängige Objekte parallel berechnen, wenn es gar nicht genug Objekte dafür gibt.

Das wird wohl auch zur Zeit das Problem sein. Mehrere Prozessoren würden den Vorgang nicht beschleunigen, sondern eher die max. Anzahl an Objekten (was auch immer "Objekt" hier jetzt ist) anheben.

Das ist jetzt allgemein gesagt. Inwiefern das jetzt durch diverse Probleme heutiger Ansichten nach möglich ist, sei mal dahin gestellt.

#44

2006-03-22, 13:56:31

so hab mich mal angemeldet... damit ich meine beträge auch editieren kann.
ist einfach bequemer

und um nicht weiter darüber streiten zu müssen geb ich dir einfach mal recht... ich kann auch innerhalb deiner meinung genauso argumentieren... nur die begriffe ändern sich.

aber ich halte es dennoch nicht für zutreffend (das man von quadcore weniger profitieren wird) da pc spiele sehr niedrige sequentielle anteile habe
(und das meinte ich damit, als ich sagte sie bestehen aus vielen algorithmen. vlt gibst du mir jetz recht) denn schon allein eine physikengine könnte fast ein eigenenständiges programm sein.
wenn man jetzt jeden teil eines spieles nimmt (ki, gamengine, physikengine, sound und was es nicht noch alles geben kann. auch kann man die einzelnen komponenten weiter zerlegen)
und je auf einem eigenen core ausführt hat man einen sequentiellen anteil (der anteil der nur von einer einzelnen cpu berechnent und nicht aufgeteilt werden kann) von 0
da weder die physik noch die ki oder der sound GEMEINSAME (daher sequentielle) berechnungen ausführen (sie greifen höchstens auf ergebnisse des anderen zu)

so wird aus unseren beiden meinungen ein schuh... bzw ein game ;)

@ topic: somit sehe ich auch für quadcores noch durchaus größere leistungssprünge

jedoch je höher die anzahl der cores zunimmt desto kleiner werden die leistungssprünge (hab ich übrigens auch schon vor der diskussion mit coda mal wo hier im forum gepostet)

andere größere technologien für desktop cpus in den nächsten 4 jahren sehe ich aber erstmal nicht

turboschlumpf

2006-03-22, 14:20:49

#44

2006-03-22, 14:49:47

Damit würde eine CPU mit der Anzahl der Cores nicht schlechter skalieren als mit dem Takt.

wobei das wiederum programm-abhängig ist... wie schon erwähnt wurde: je kleiner der sequentielle anteil der progs. desto größer der leistungszuwachs.

betasilie

2006-03-22, 14:54:50

@Coda
Wie Du sehen kannst, ist deine Meinung zu Multicore nicht umumstritten. Nimm es nicht persönlich, Du bist sicher kompetenter als ich, aber oft vertrittst Du Meinungen etwas lautstark, die so nicht haltbar sind und bist in gewissen Bereichen eher ablehnend und pessimistisch.

Die richtigen Cracks in den Spielestudios, die sowieso überwiegend im Konsolenbreich zu finden sind, werden schon schnell Fortschritte machen und neue Herrangehensweisen finden, Multicoresysteme gut auszulasten. Und dass man bei Muticorelösungen bei den meisten Codes etwas unter der Effizienz von Singethreadlösungen bleiben wird, bestreitet ja auch niemand, aber da Multicore auf dem breiten Markt erst seit kurzem verfügbar ist, wird man sich erst jetzt im großen Stil mit Multicorecodes in Spielen beschäftigen und entsprechende Fortschritte bei der Entwicklung neuer Codes machen.

Coda

2006-03-22, 15:01:15

Wie Du sehen kannst, ist deine Meinung zu Multicore nicht umumstritten.Was gibts denn bitte daran zu bestreiten? Selbst Neomi geht davon aus, dass es 20-40% nicht parallelisierbaren Code gibt und dann sagt einem die Logik nunmal dass die maximale Steigerung eben nichtmehr so ist wie ihr euch das vorstellt.

Und das ist sehr wohl haltbar.

Die richtigen Cracks in den Spielestudios, die sowieso überwiegend im Konsolenbreich zu finden sind, werden schon schnell Fortschritte machen und neue Herrangehensweisen finden, Multicoresysteme gut auszulasten. Ihr versteht das Problem nicht. Wenn ich im seriellen Code den Bottleneck habe, dann bringt mir das alles nichts (50ms in unparallelisierbarem Code und ich hab halt nur maximal 20 FPS, da kann ich Cores danach schmeißen für das parallelisierbare Zeug bis ich schwarz werde).

Gerade die Konsolen-CPUs sind da wirklich selten dämlich durch ihre geringe Leistung ohne Threading.

da pc spiele sehr niedrige sequentielle anteile habeDas ist eine Behauptung die du einfach in den Raum stellst. Und wenn "niedrig" 20% hat das eben schon ziemliche Auswirkungen auf die Skalierung mit Threading.

Nochmal: Ich sage nirgends dass Parallelisierung nicht kommen wird, aber sie wird eben nicht soviel bringen wie manche denken. Vor allem wird das ganze sehr schnell sehr viel schwieriger mit mehr als 2 Cores, weil dann die Amdahl-Kurve von ner Gerade in ne ziemlich krasse Hyperbel übergeht.

Nochmal:
For this reason, parallel computing is only useful for either small numbers of processors, or problems with very low values of F: so-called embarrassingly parallel problemsWas ist daran denn bitte schwer zu verstehen? Wenn es nicht gut parallelisierbar ist (und gut ist wirklich F<=20%) dann hat man sehr schnell sehr große Skalierungsprobleme.

Das ist im Übrigen nicht meine Meinung sondern das sind schlicht und ergreifend Fakten.

turboschlumpf

2006-03-22, 15:20:06

Siehst du. Und selbst bei 20% bekommen wir mit nem Quadcore gerade mal die 2,5x Rechenleistung. Ziemlich traurig finde ich.Damit würde eine CPU mit der Anzahl der Cores nicht schlechter skalieren als mit dem Takt.wobei das wiederum programm-abhängig ist... wie schon erwähnt wurde: je kleiner der sequentielle anteil der progs. desto größer der leistungszuwachs.Logisch, aber darum ging es mir nicht.

Was bitte ist an einer Skalierung von gut 60 % "traurig"? Das ist doch Standard.

betasilie

2006-03-22, 15:22:24

Was gibts denn bitte daran zu bestreiten? Selbst Neomi geht davon aus, dass es 20-40% nicht parallelisierbaren Code gibt und dann sagt einem die Logik nunmal dass die maximale Steigerung eben nichtmehr so ist wie ihr euch das vorstellt.
Natürlich, was aber nicht im Gegensatz dazusteht, dass man Multicore gerechte Alternativen für viele dieser Codes entwickeln wird.

Du machst gerade so, als ob Du der Fachman schlechthin wärst, aber ich denke nicht, dass Du wirklich einer der Top-Fachleute der Branche bist. Entwicklest Du überhaupt Spielecode im kommerziellen Rahmen? ... Es hört sich nämlich so an, wenn man bedenkt mit was für einer Selbstverständlichkeit Du diversen Fachleuten der Branche widersprichst.

Ihr versteht das Problem nicht. Wenn ich im seriellen Code den Bottleneck habe, dann bringt mir das alles nichts (50ms in unparallelisierbarem Code und ich hab halt nur maximal 20 FPS, da kann ich Cores danach schmeißen für das parallelisierbare Zeug bis ich schwarz werde).

Gerade die Konsolen-CPUs sind da wirklich selten dämlich durch ihre geringe Leistung ohne Threading.
Siehe oben. (... Für welche Studios entwickelst Du?)

Radeonator

2006-03-22, 15:25:29

lol, da hat sich 64Bit noch netmal ansatzweise durchgesetzt und die Leute tun so als ob 128Bit angeschossen kommt. :|

>90% der Desktop PC laufen auf 32Bit OS mit Glück nen AMD64 drin und trotzdeben 32Bit OS.

Also vielleicht ist für die ein oder andere Sache 128Bit nice, für den Retail Markt jedoch nur als PR Gag. ;)

Also erstmal muss überhaupt 64Bit mal ausgenutzt werden, dann kann man über anderes philosofieren.

Coda

2006-03-22, 15:28:32

Natürlich, was aber nicht im Gegensatz dazusteht, dass man Multicore gerechte Alternativen für viele dieser Codes entwickeln wird.

Du machst gerade so, als ob Du der Fachman schlechthin wärst, aber ich denke nicht, dass Du wirklich einer der Top-Fachleute der Branche bist. Entwicklest Du überhaupt Spielecode im kommerziellen Rahmen? ... Es hört sich nämlich so an, wenn man bedenkt mit was für einer Selbstverständlichkeit Du diversen Fachleuten der Branche widersprichst.

Siehe oben. (... Für welche Studios entwickelst Du?)Ich habe zwar noch keine Spiele entwickelt aber andere kommerzielle Software mit Multithreading. Das macht allerdings eigentlich keinen Unterschied, da die Probleme genau die gleichen sind.

Spiele sind mit Sicherheit keine inhärent parallelisierbares Programme. Allein schon der ganze Script-Code der geschrieben wird und oft einen Großteil der Runtime von z.B. Far Cry oder UT2004 ausmacht ist so per se nicht parallelisierbar. Ich weiß allerdings nicht ob Sweeney an UnrealScript was geändert hat für UT2007.

Das Problem an der ganzen Sache ist doch wie ich schon ein paar Mal erwähnt habe dass bereits "geringe" Anteile (10-20%) an seriellem Code die maximale Geschwindigkeitssteigerung stark limitieren.

HOT

2006-03-22, 15:33:49

Es ist eigentlich ganz einfach: Es ist immer besser über Takt zu skalieren. Bringt es der Takt alleine nicht, muss die Architektur breiter werden. Ist die Architektur breit genug, müssen halt mehrere Cores her.

Wäre Fertigung kein Problem und könnte man über den Takt skalieren, ist das selbstredend am effizientesten, weil man keinen Verschnitt hat. Es liegt keine Leistung brach.
Auch die Verbreiterung der Architektur ist noch effizient, wenn auch nicht so effizient wie mehr Takt. Irgendwann wird es einfach unrentabel weitere parallele ALUs einzubauen, weil der Algorithmus an sich einfach nicht weiter zerlegbar ist. (Ein Algorithmus ist nichts weiter als eine sehr exakte stukturierte Formulierung einer Problemlösung. Man muss halt genau formulieren, weiol man es dem Rechner verständlich machen muss.)
Der nächste Schritt ist eben, mehrere Algorithmen parallel zu rechnen und mit anderen zu synchronisieren. Das machen SMP Systeme (Dual Core CPUs).
Aber hier gilt ähnliches wie bei der Architekturverbreiterung: Es müssen viele verschiedene Algorithmen da sein, die parallelisiert werden können. Es hört sich so einfach an, lassen wir die Physik mal separat laufen, die Grafik und den Sound auch. Aber: Du musst den Kram synchronisieren! Wenn du bei Farcry eine Waffe abfeuerst, bekommst du eine Grafik, einen Sound und die KI reagiert darauf. All diese Threads müssen verzögerungsfrei ablaufen.
Man kann sicherlich viel parallelisieren im Programmcode, mit Tricks kommt man sicher auf mehr Effizienz dabei, aber man muss sehen, was überhaupt Sinn macht; wieviele parallele Threads zeitgleich überhaupt laufen, um das Ganze effizient zu gestalten. Denn, wenn nur 2 Threads laufen, liegen 2 weitere Kerne eines Quad-Core brach und tun nichts.
Je mehr Kerne, desto ineffizienter wird die Geschichte. Für Spiele behaupte ich mal, dass mehr als 3 Kerne absolut keinen Sinn mehr machen.

#44

2006-03-22, 15:33:58

ich behaupte das weil: ein game gerad aus so vielen unabhängigen einzelkomponenten zusammengebastelt wird. das macht die paralellisierbarkeit doch aus? hat bereits mit grafik geklappt und wird auch noch mit ki (die auch ordentlich leistung fordert) und anderen code teilen klappen

in zukunft wird auch die entwicklung neue wegen gehen (müssen) (hast du ja selbst gesagt) um f klein zu halten.

und das er recht hat mit dem was er behauptet steht ausser frage.

nur schätze ich gerade nicht paralellisierbare aufgaben auch wesentlich geringer ein, zumindest solange die core zahl noch unter ca 8 ist (auch hier nenne ich wiederholt die einzelkomponenten die dann unabhängig laufen könnten: sound, physik, ki, wegfindung, gameengine, vom prozessor zu erledigende grafik anteile)
und mit wegfindung meine ich ein system das selbstständig ohne waypoints erkennt wo eine figur laufen kann und wo nicht und das dann entsprechend umsetzt (klar das ist wieder aufwand aber das steht auf nem anderen blatt)

und ausserdem gewinnt man nicht nur durch programmcode bei nem dc geschwindigkeit... durch die entlastung der cpu von hintergrundthreads und damit verbundenen wechselzeiten (um den 1/coreanzahl faktor(bei gleichmäßiger verteilung)) entstehen wieder neu nutzbare rechenzeit die gerade bei sc öfter für ruckler sorgen kann wenn zb. av software auch läuft

Coda

2006-03-22, 15:36:02

ich behaupte das weil: ein game gerad aus so vielen unabhängigen einzelkomponenten zusammengebastelt wird. das macht die paralellisierbarkeit doch aus?Vieles hängt auch voneinender ab. Ich kann nicht Stencil-Shadows berechnen ohne vorher die potentielle sichtbare Geometry zu haben, etc.

#44

2006-03-22, 15:41:28

dann wird ein core eben auf den anderen warten müssen... wie heute bei cpu & graka
oder ist sowas nur schwer umzusetzten?
(mir ist klar das man da leistung verliert.... aber ich glaube das je nach optimierung schon bei dc 40-85% drinne sein sollten und ein qc dann nochmal ca 50%(aber über schätzungne lässt sich streiten))

und nohchmal wegen der synchronität: da muss dann u.U. ein prozessor das ganze überwachen/zusammenarbeit koordinieren wie in einem netzwerk

Coda

2006-03-22, 15:43:40

Ja eben das ist ja das Problem. Die Wartezeiten durch seriellen Code.

(mir ist klar das man da leistung verliert.... aber ich glaube das je nach optimierung schon bei dc 40-85% drinne sein sollten und ein qc dann nochmal ca 50%(aber über schätzungne lässt sich streiten))Das brauchst du nicht schätzen, das kannst du nach der Formel die ich die ganze Zeit benütze genau ausrechnen. Und da kommt die maximale Leistungssteigerung raus, ohne abzüge durch Overheads und Ineffizienten der Architektur (Cache-Trashing, etc.).

GloomY

2006-03-22, 15:43:41

[...] und sonst fällt mir jetzt gerde auch nix ein, was Silizium ablösen könnte.Es gibt eine Menge Halbleiter, die nach der Dotierung eine wesentlich höhere Ladungsträgerbeweglichkeit besitzen als Silizium. Germanium ist so ein Kandidat, es gibt aber auch noch andere. Auch wenn Germanium heutzutage noch zu teuer für die Massenproduktion ist, sind die überlegenen Eigenschaften durchaus bekannt und werden auch im Labor erprobt.
Momentan gibt es erste Anzeichen, dass sich Asynchrone Chips eventuell etablieren könnten. Erste marktreife Chips sind schon verfügbar.Immer mehr Chips besitzen keine einheitliche Taktung des gesamten Chips mehr sondern einzelne Teile, die schneller oder langsamer getaktet werden. Diese Unterteilung in verschiedene "Clock-Domains" wird in Zukunft wohl noch zunehmen.
Immer dieses Geseier von wegen veraltet. "Totgesagte leben länger" sag ich ich da nur. Da lässt sich noch einiges steigern.Da stimme ich mal uneingeschränkt zu.

GloomY

2006-03-22, 15:43:55

Blöde Frage: Seh ich das in Intels Marketingunterlagen richtig, dass man bei den "Core"-Prozessoren quasi eine Art ULIW-Compiler drin hat?

Von http://www.intel.com/technology/architecture/coremicro/:
"Now with the Intel Core microarchitecture, Intel significantly enhances this capability with Intel®Wide Dynamic Execution. It enables delivery of more instructions per clock cycle to improve execution time and energy efficiency. Every execution core is 33% wider than previous generations, allowing each core to fetch, dispatch, execute and retire up to four full instructions simultaneously.

Intel Wide Dynamic Execution also includes a new and innovative capability called Macro-Fusion. Macro-fusion combines certain common x86 instructions into a single instruction for execution."Ich sehe rein gar nichts, was hier für VLIW spricht. Es gibt keine feste Zuordnung von Befehl an Ausführungseinheit, was ja VLIW ausmacht. Die Befehle werden immer noch dynamisch zur Ausführungszeit auf freie ALUs etc. verteilt. Solange es einen Scheduler in einem superskalaren Prozessor gibt, ist es garantiert kein VLIW (oder EPIC).
Das behauptest Du schon lange. Und immer wieder gibt es kompetente Leute, die meinen, dass Du falsch liegst.Das Problem ist doch viel eher, dass es stark auf den Algorithmus ankommt. Je nachdem, was die Leute programmieren, ist das mehr oder weniger leicht. Der eine, der ein ziemlich leicht zu parallelisierendes Programm hat, redet dann davon, dass es einfach ist. Und ein anderer, der an einem verdammt schwierig zu parallelisierenden Programm mit einer Reihe von Abhängigkeiten (-> lineare Ausführung) oder Locks für den wechselseitigen Zugriff arbeitet, der wird sich die Haare raufen über den Aufwand, den er dort hineinstecken muss.

Software ist eben nicht gleich Software.
Taktskalierung würde zwar für alle Programme funktionieren, aber leider funktioniert Taktskalierung an sich nicht mehr. Deshalb müssen wir ja ausweichen.Och, so ganz bin ich nicht davon überzeugt, dass das nicht mehr funktioniert. Es ist bloss schwieriger geworden und kommt nicht von alleine (z.B. durch kleinere Herstellungsprozesse). Der P4 ist in diesem Kontext immer ein schlechtes Beispiel, weil bei ihm an vielen Stellen massig IPC geopfert wurde, um diesen hohen Takt zu erreichen.

Man muss halt insbesondere den Stromverbrauch im Auge behalten und wahrscheinlich an sehr vielen Stellen bis auf die Transistorebene Hand anlegen. Der Einsatz von verschieden schnellen/leckenden Transistoren ist dabei Pflicht, so wie Intel z.B. beim Tulsa verschiedene effektive Kanallängen verwenden wird. Die (wenigen) Stellen, die performance-kritisch für die Schaltgeschwindigkeit des gesamten Chips sind, bekommen die schnellen und stark Strom schluckenden Transistoren und der große Rest des Chips die langsameren und Stromsparenden. (*)

Natürlich sind das große Entwicklungskosten, die hierbei entstehen, aber es ist technisch machbar. Oder wie erreicht der Cell Prozessor sonst seine 4,5 GHz? Der Power6 wird uns zeigen, dass Taktskalierung noch möglich ist. Davon bin ich überzeugt.

(*) Williamette, Northwood und Prescott haben durchgängig nur eine Sorte von Transistoren verwendet. Rate mal welche ;)
edit: Argh, Prescott benutzt 2 Arten von Transistoren mit unterschiedlichen Schwellspnnungen.

#44

2006-03-22, 15:47:04

Ja eben das ist ja das Problem. Die Wartezeiten durch seriellen Code.

Das brauchst du nicht schätzen, das kannst du nach der Formel die ich die ganze Zeit benütze genau ausrechnen. Und da kommt die maximale Leistungssteigerung raus, ohne abzüge durch Overheads und Ineffizienten der Architektur (Cache-Trashing, etc.).

wobei wir wieder bei der diskussion um die definition von algorithmus (auf den sich das gesetz bezieht) sind

Coda

2006-03-22, 15:47:59

Ich hab dir schonmal gesagt, dass du mit ein wenig Gehirnschmalz drauf kommen wirst, dass sich das auf eine beliebige Laufzeit-Zeitspanne eines Programms übertragen lässt.

2h Gesamtlaufzeit, davon sind 50% parallelisierbar -> maximal 1h Gewinn egal wieviel Cores. Steigerung: maximal 2x.

Was er in den 2h rechnet und welche Algorithmen es sind ist doch völlig schnurz. Es ist eben 50% der Rechenzeit auf serielles Zeug verloren. Das ist wirklich Mathematik 9. Klasse.

#44

2006-03-22, 15:50:57

hah! das ist ein fehler
gerade bei spielen ist das innerhalb des codes UNTERSCHIEDLICH
da der code stellenweise so verschieden ist wie ich und du (bzw unsere meinungen ;) )

HOT

2006-03-22, 15:52:01

wobei wir wieder bei der diskussion um die definition von algorithmus (auf den sich das gesetz bezieht) sind

:D
http://de.wikipedia.org/wiki/Algorithmus

Coda

2006-03-22, 15:52:07

hah! das ist ein fehlerDas ist kein Fehler, das war ein Beispiel, das Amdahl's "Law" belegt (eigentlich sollten solche Trivialitäten nicht "Gesetz" genannt werden).

Das funktioniert genauso wenn ich sage dass in den 2h eben nur 20% seriell sind. Dann ist der mögliche Geschwindigkeitsgewinn eben entsprechend größer, aber trotzdem limitiert.

mapel110

2006-03-22, 15:53:57

Coda

2006-03-22, 15:55:33

Richtig. Und was machen Söny und Winzigweich bei ihren Konsolen? Genau das Gegenteil X-D

#44

2006-03-22, 16:01:03

betasilie

2006-03-22, 16:05:00

Richtig. Und was machen Söny und Winzigweich bei ihren Konsolen? Genau das Gegenteil X-D
Die beiden Firmen hätten dich einstellen sollen, damit Du ihnen erklärst, dass ihre Entscheidungen zu Multicore und ihre bisweilen exorbitant hohen Investitionen in die Entwicklung solcher CPUs dumm waren. Nur Spinner da, die keine Ahnung von Spieleentwicklung und entsprechender Hardware haben. ;(

Deine Meinung in allen Ehren, aber wie Du sie rüber bringst, trotz deiner fehlenden Kenntniss bzgl. Spieleentwicklung, ist schon sehr befremdlich.

Coda

2006-03-22, 16:06:48

vlt hab ich ne falsche auffassung... aber ich glaube eher weniger... ich denke einfach nur du überschätzt (zumindest bei spielen) den anteil an sequenziellem code (vlt sogar gewaltig) /bzw das was man schon so parallelisieren könnte. klar wird auch ein multicore winword kaum an leistung gewinnen (müssen) aber bei spielen sehe ich viel potenzial, auch noch für quadcore.Nochmal: Bereits vermeintlich "geringe" Anteile an sequentiellem Code können verheerende Auswirkungen haben.

Die beiden Firmen hätten dich einstellen sollen, damit Du ihnen erklärst, dass ihre Entscheidungen zu Multicore und bisweilen exorbitant hohen Investitionen in die Entwicklung solcher CPUs dumm waren. Nur Spinner da, die keine Ahnung von Spieleentwicklung und entsprechender Hardware haben. ;(Da gings um politische Dinge. MS wollte den Core selber fertigen. Das G5-Design hätte IBM aber niemals rausgerückt, deshalb haben sie eben 3 simple Cores genommen. Bei Söny musste man ja schon bei der PS2 am Geisteszustand der HW-Entwickler zweifeln.

Deine Meinung in allen Ehren, aber wie Du sie rüber bringst, trotz deiner fehlenden Kenntniss bzgl. Spieleentwicklung, ist schon sehr befremdlich.Ich selbst bin mir sicher, dass ich genügend Kenntnis habe um das zu beruteilen. Neomi hat mir auch nie so richtig wiedersprochen, wie dir evtl. aufgefallen sein sollte.

Mit dem könnte ich ewig darüber diskutieren, weil ich auch merke dass er etwas davon versteht, aber bei euch ist es einfach nur lästig.

Gast

2006-03-22, 16:07:11

Deine Meinung in allen Ehren, aber wie Du sie rüber bringst, trotz deiner fehlenden Kenntniss bzgl. Spieleentwicklung, ist schon sehr befremdlich.

Muss dir doch bekannt vorkommen, du gibst ja auch immer dein Bestes im Konsolenforum :redface:

Aquaschaf

2006-03-22, 16:11:02

hat man einen sequentiellen anteil von 0

Das ist Blödsinn und es gibt dazu auch einen schönen Artikel auf Gamasutra.

The inherent complexity of game engines makes them more difficult to thread than other applications. Various subsystems [e.g., artificial intelligence (AI), physics, character animation, collision detection, rendering, audio, etc.] manage aspects of the game engine. As a player moves through the virtual world of the game, a video forms. However, there is no predefined sequence of events. The actions of the player are effectively random from the game's perspective. The game is a real-time, event-driven process. This creates a problem for threading – the frame sequence is inherently sequential. In other words, each frame depends on the preceding frame. Therefore, multiple frames cannot be computed independently and in parallel to boost frame rates and improve performance. Techniques to predict more than a frame in advance would introduce latency and negatively impact the player experience.

Since it is impossible to exploit inter-frame parallelism, one must look within a frame for potential threading targets. Simultaneously computing the AI, character animation, collision detection, etc. would be ideal. However, most of today's engines were designed without considering parallel computation. As a result, dependencies exist among the subsystems that limit the effectiveness of threading (Figure 1). Here are just a few examples:

- Some characters cannot move until the AI subsystem tells them what to do.
- Sounds (e.g., foot steps, gunshots, speech, etc.) cannot be emitted until all events and actions for the frame are decided.
- Collision detection is a continuous process that can interrupt other computations.
- Rendering cannot occur until the final state of the frame is decided.

Und dazu kommt noch das Problem wegen der feinen Granularität. Tendenziell hat man sehr kurzlebige Threads; der Overhead der durch die Parallelisierung entsteht ist groß. Mit mehr Physikberechnungen, KI, Animationen und so weiter ist es zwar möglich von mehreren Prozessoren zu profitieren aber Spiele gehören prinzipiell zu Software die dafür nicht gut geeignet ist.

#44

2006-03-22, 16:21:25

Lies doch mal den 2. teil deines zitates... da steht was ich meine....
und ja das das keine probleme macht hab ich wo behauptet?

wobei ich nicht glaube das die wartezeiten in einem bereich sind wo ein mensch sie jemals wahrnehmen kann... (selbst bei 100ms ist das schon schwer(man kann bis 200ms mmn auch noch akzeptabel cs:s im net zocken, wenn der ping konstant ist)) das gilt für sound sowie die ai

ausserdem ist im 2. teil auch nur von aktuellen und nicht von engines die rede die explizit für mc gecoded wurden (das aktuelle engines kaum profitieren ist mir natürlich klar) (gemeint sind natürlich aktuelle engines die an dc angepasst wurden)

IVN

2006-03-22, 16:31:56

@Coda
Es ist nicht so das Cores gleich bleiben,und nur deren Anzahl erhoeht wird.
Schnellere Komunikation zwischen den selben koennte Abhilfe schaffen.
-Ein "Spiel" ist nicht nur ein Shooter.Es gibt auch solche wie die X-Serie.Da koennten MCs mehr bringen als bei einem FPS/einer normalen Flugsimulation.

p.s. mit dem seriellen-Anteil hast du wahrscheinlich Recht.Denoch ist dieser bei verschieden Einsatzgebieten unterschiedlich.Bei einem RTS kleiner als bei einem FPS...
p.p.s.Wenn du schon einen dynamischen Arbeitsgebiet gewaehlt hast solltest du dich auch anpassen koennen,und nicht nur meckern....Leap ahead. :tongue:

Aquaschaf

2006-03-22, 16:36:19

Lies doch mal den 2. teil deines zitates... da steht was ich meine.... und ja das das keine probleme macht hab ich wo behauptet?

Du hast wörtlich geschrieben in einem Spiel gibt es 0 sequentiellen Anteil. Das ist einfach falsch. Mit dem Zitat endet der Artikel ja nicht. Auch wenn eine Engine ideal für Multithreading programmiert ist behalten Amdahl's Gesetz und das Problem der Granularität ihre Gültigkeit und auch dann ist der Gewinn recht begrenzt.

Coda

2006-03-22, 16:38:05

Es ist nicht so das Cores gleich bleiben,und nur deren Anzahl erhoeht wird.
Schnellere Komunikation zwischen den selben koennte Abhilfe schaffen.Das Gesetz geht von einem bereits perfekten Multithreading ohne jeglichen Overhead aus. In der Praxis ist es natürlich noch schlimmer.

betasilie

2006-03-22, 16:52:12

Nochmal: Bereits vermeintlich "geringe" Anteile an sequentiellem Code können verheerende Auswirkungen haben.

Da gings um politische Dinge. MS wollte den Core selber fertigen. Das G5-Design hätte IBM aber niemals rausgerückt, deshalb haben sie eben 3 simple Cores genommen. Bei Söny musste man ja schon bei der PS2 am Geisteszustand der HW-Entwickler zweifeln.
Tja, diese Überheblichkeit zeichnet dich aus, genauso wie der Schluss von der PS2 auf die PS3 schließen zu können. Im übrigen ist die PS2, trotz ihrer teilweise sehr schwer handelbaren Architektur, ein Phänomen von Leistungsfähigkeit, wenn man sich aktuelle Titel auf dieser 6 Jahre alten Konsole anschaut.

Aber schon klar, Du weißt ja alles besser und bei Sony sitzen geistesgestörte Entwickler. :uclap:

Im übrigen hat MS durchaus die Wahl gehabt auf eine anderes CPU Design auszuweichen, aber sie wollten es garnicht. Multicore ist beim Design der XBox 360 eine elementarer Bestandteil der Architektur, nicht zuletzt, weil ein Core für die Sicherheit verantwortlich ist und ein anderer für Sound und das OS. ... Daher ist auch diese These deinerseits nicht haltbar in dieser Form.

Ich selbst bin mir sicher, dass ich genügend Kenntnis habe um das zu beruteilen. Neomi hat mir auch nie so richtig wiedersprochen, wie dir evtl. aufgefallen sein sollte..
Neomi hat dir duchaus widersprochen, nur verhält er sich wesentlich diplomatischer, als Du, und ich denke er weiß, dass Du sowieso nicht von deiner Meinung abweichst, so wie man das bereits von dir kennt. ... Im übrigen auch seltsam, dass ich Neomis Meinung absolut nachvollziehbar und kompetent empfinde, ganz im Gegensatz zu deinen Aussagen, wobei Du doch meinst, dass ihr einer Meiung seid.

Ich erinnere nur mal daran wie lange Du Cell für einen Streamingprozessor gehalten hast und dich wochenlang über die Leute bie Sony mit dem "zweifelhaften Geisteszutand" hergezogen bist, bis dir mal jemand verklickert hat, dass Cells SPEs keine Streamingprozzis sind. :rolleyes:

Ebenso mit deiner Hetze gegen die Konsolen CPUs, weil sie keine out-of-order Architektur haben, die Du wochenlang getrieben hast, obwohl oder bis dir Leute, wie Demirug, klar gemacht haben, dass out-of-order bei Konsolen mit ihrer fixen Architektur bei weitem nicht so wichitg sind, wie bei einem PC, und die Compiler den Großteil der Nachteile abfangen können.

Fakt ist, Du lehnst dich mit deiner angeblich achsotollen Kompetenz extrem weit aus dem Fenster und bekommst von wesentlich kompetenteren Leute immer wieder nen Dämpfer, ohne dass dich das über dein überhebliches Auftreten nachdenken lässt.

Mit dem könnte ich ewig darüber diskutieren, weil ich auch merke dass er etwas davon versteht, aber bei euch ist es einfach nur lästig.
Die Frage ist, ob er ewig mit dir darüber diskutieren will. X-D

Und als lästig empfinde ich deine Art ebenfalls. Du spielst dich als dermaßen kompetent auf, obwohl Du kein Spielentwickler bist und ständig daneben liegst mit deiner Meinung.

Und um das nochmal festzuhalten, Du hast keine Ahnung von Spieleentwicklung, solange Du nicht beruflich in dieser Branche arbeitest. Und selbst dann gehörst Du noch lange nicht automatisch zu den Personengruppen, die wirklich kompentent sind, denn das sind nur sehr wenige.

Als ob Du weißt was die Typen bei CryTek, NaughtyDog, NinjaTheory, etc. wirklich gerade für Engine- und Codekonzepte entwickeln für Multicore-Systeme. Nicht mal eine Hauch Ahnung hast Du davon und nicht ein Funken der Begabung dieser Topleute, wie die allermeisten hier wohl auch nicht darüber verfügen. Also führ dich nicht so auf, als Du ob Du der Oberguru bist, der alles besser weiß.

Gast

2006-03-22, 16:54:28

Du hast wörtlich geschrieben in einem Spiel gibt es 0 sequentiellen Anteil

nicht ganz... gemeint war das es bei der verteilung die ich beschrieben hab keinen "sequenziellen" anteil gibt... war u.U. schlecht ausgedrückt (ki-gamengine-physik) da jedes system vom anderen unabhängig lauffähig ist

Coda

2006-03-22, 17:00:07

Ich erinnere nur mal daran wie lange Du Cell für einen Streamingprozessor gehalten hast und dich wochenlang über die Leute bie Sony mit dem "zweifelhaften Geisteszutand" hergezogen bist, bis dir mal jemand verklickert hat, dass Cells SPEs keine Streamingprozzis sind.
Das mag sein, aber jeder macht mal Fehler. Im ersten Moment hat das auch Demirug geglaubt, daher kam diese Meinung.

Andererseits hat das aber auch nicht viel zu meiner Auffassung über Cell geändert. Er steht nur etwas besser da.

Und überhaupt wurde ich damals vom Playstation-Troll-No.1 (Jesus) geradezu zu solchen Aussagen genötigt. Irgendwas muss man diesen Fanatikern ja entgegenbringen. Ich kann es einfach nicht leiden wenn Bullshit verbreitet wird ("Cell ist die tollste CPU aller Zeiten").

Ebenso mit deiner Hetze gegen die Konsolen CPUs, weil sie keine out-of-order Architektur haben, die Du wochenlang getrieben hast, obwohl oder bis dir Leute, wie Demirug, klar gemacht haben, dass out-of-order bei Konsolen mit ihrer fixen Architektur bei weitem nicht so wichitg sind, wie bei einem PC, und die Compiler den Großteil der Nachteile abfangen können.Da die Branch-Prediction auch nicht das gelbe vom Ei ist hat das sehr wohl Auswirkungen. Das Ding ist noch dazu nichtmal superskalar.

Im übrigen hat MS durchaus die Wahl gehabt auf eine anderes CPU Design auszuweichen, aber sie wollten es garnicht. Multicore ist beim Design der XBox 360 eine elementarer Bestandteil der Architektur, nicht zuletzt, weil ein Core für die Sicherheit verantwortlich ist und ein anderer für Sound und das OS. ... Daher ist auch diese These deinerseits nicht haltbar in dieser Form.Es ist ein stink normales SMP-System, da is nix mit fester Zuordnung. Und wenn, dann wäre es noch trauriger, denn einer dieser Cores kann für die gesammte Gamelogik wirklich fast nichts reißen im Gegensatz zu einem modernen Prozessor.

Fakt ist, Du lehnst dich mit deiner angeblich achsotollen Kompetenz extrem weit aus dem Fenster und bekommst von wesentlich kompetenteren Leute immer wieder nen Dämpfer, ohne dass dich das über dein überhebliches Auftreten nachdenken lässt.Ich bitte dich. Man kann nicht alles wissen. Auch die anderen machen manchmal Fehler in ihren Aussagen.

Neomi hat dir duchaus widersprochenZitat bitte.

Und um das nochmal festzuhalten, Du hast keine Ahnung von Spieleentwicklung, solange Du nicht beruflich in dieser Branche arbeitest. Und selbst dann gehörst Du noch lange nicht automatisch zu den Personengruppen, die wirklich kompentent sind, denn das sind nur sehr wenige.Ich mache es seit mehren Jahren als Hobby. Auch auf etwas höherem Niveau, zumindest was Grafik angeht.

Glaubst du denn ich saug mir das Wissen über GPUs etc. aus den Fingern oder was?

Ob ich jetzt beruflich einen genetischen Algorithmus für Parameterextraktion eines MOSFET-Modells mache oder eine Gamelogik ist glaube ich von der Komplexität nicht viel anders :tongue:

#44

2006-03-22, 17:01:48

nochmal zu dem artikel von gamasutra (ich weigere mich prizipiell irgendwas vorgekautes einfach so zu schlucken):

Since it is impossible to exploit inter-frame parallelism, one must look within a frame for potential threading targets. <--- exakt auf was ich hinaus will

Simultaneously computing the AI, character animation, collision detection, etc. would be ideal. However, most of today's engines were designed without considering parallel computation.<--- muss sich ändern, auch das will ich

As a result, dependencies exist among the subsystems that limit the effectiveness of threading (Figure 1). <--- leider, hab ich aber auch schon zugegeben

Here are just a few examples:

- Some characters cannot move until the AI subsystem tells them what to do. <--- in welchem millisecond bereich liegt das? ;D

- Sounds (e.g., foot steps, gunshots, speech, etc.) cannot be emitted until all events and actions for the frame are decided. <--- ja wenn das frame nicht fertig ist... dann passiert garnichts und ich wage zu bezweifeln das es jmd stört wenn zusätzlich zum bild noch der sound hängt (oder verste ich das grad falsch)

- Collision detection is a continuous process that can interrupt other computations. <--- ppu wird das übernehmen bzw nen eigener core der nix anderes zu tun kriegt (wird aber erst ab 4/8 cores wirklich interessant)

- Rendering cannot occur until the final state of the frame is decided. <--- ist das jetzt anderst??? heutzutage macht das halt eben ein core nacheinander... da müssen sich eben die programmierer drum kümmern...

soviel zu dem statement das mir ja so toll wiederspricht

und ja: auch hobby entwickler haben ahnung (nicht soviel wie nen team pros aber untauglich sind die sicher nit) was ja die viele shareware die man finden kann auch beweist

@coda: cool *G* kannst mir vlt mal irgenwie nen link zukommen lassen, wo man deine werke bewunder kann? ich bin selbst begeisterter programmierer (ok zur zeit noch viel mehr begeisterung als richtiges programmieren aber 1200 seiten technisches englisch durchwürgen zu wollen um ansatzweise *richtig* programmieren zu können nen ich doch mal versiert, heist aber nicht das ich garkeine erfahrung habe... (erstes basic prog mit ca 10 oder 12^^) habs leider zu stark schleifen gelassen)

betasilie

2006-03-22, 17:19:54

Glaubst du denn ich saug mir das Wissen über GPUs etc. aus den Fingern oder was?
Ich will dir absolut nicht dene Kompetenz streitg machen. Du bist kompetent und ich lese viele deiner Beiträge mit Interesse. ;) ... Auf der anderen Seite empfinde ich viele deiner Aussagen, besonders im Kontrast zu den Kontras, die Du von anderen kompeten Personen bekommst, als ziemlich überheblich, weil deine Kompetenz halt ziemlich begrenzt ist, in Hinblick auf echte Profis, die jetzt für millionenteure Produktionen ihre Multicore-Konzepte entwickeln.

Wie Neomi schon sagte, etwas weniger Pessimismus würde gut tun und etwas weniger dickköpfig Firmen wie Sony oder MS aburteilen, als ob dort nur Vollhonks am Werke sind, wäre auch fein.

Und wenn man Firmen wie z.B. CryTek glauben darf, haben sie ihre Engine schon im Vorfeld in Hinsicht auf Multicoresysteme entwickelt, weil sie diese Entwicklung abgesehen haben, und sehen das eher als Möglichkeit sich von der Konkurrenz abzusetzen, durch ihr Know-how, statt als schlimme Entwicklung. Und sie sind da nicht alleine.

Und Du sitzt halt nicht in so einer Firma, wo echte Profis am Werke sind. Auch wenn Du als langjähriger Hobbyprogrammierer sicher etwas Ahnung hast, ist es wohl ein himmelweiter Unterschied sowas beruflich zu machen und ggf. mit einem Hammertalent gesegnet zu sein, was nur auf wenige Leute in der Branche zutrifft, als sowas privat als Hobby zu betreiben. ... Und es kommt drauf an, was die Profis aus Multicorehardware rausholen können, nicht was Du rausholen kannst. ;)

Coda

2006-03-22, 17:22:37

Ich will dir absolut nicht dene Kompetenz streitg machen. Du bist kompetent und ich lese viele deiner Beiträge mit Interesse. ;) ... Auf der anderen Seite empfinde ich viele deiner Aussagen, besonders im Kontrast zu den Kontras, die Du von anderen kompeten Personen bekommst, als ziemlich überheblich, weil deine Kompetenz halt ziemlich begrenzt ist, in Hinblick auf echte Profis, die jetzt für millionenteure Produktionen ihre Multicore-Konzepte entwickeln.Das ändert alles nichts an dem simplen Gesetz.

Cell und Xenos sind sehr schnell von seriellem Code limitiert und auch bei PC-Multicores wird das ein Problem werden.

Auch die besten Leute werden daran nichts ändern können.

#44

2006-03-22, 17:22:50

Und Du sitzt halt nicht in so einer Firma, wo echte Profis am Werke sind. Auch wenn Du als langjähriger Hobbyprogrammierer sicher etwas Ahnung hast, ist es wohl ein himmelweiter Unterschied sowas beruflich zu machen und ggf. mit einem Hammertalent gesegnet zu sein, was nur auf wenige Leute in der Branche zutrifft. ... Und es kommt drauf an, was die aus Multicorehardware rausholen können, nicht was Du rausholen kannst.

du redest vom coden wie vom leistungssport... aber alles was man beim coden brauch ist: LOGIK, u.U hardwareverständniss, und die nötigen befehle der programmiersprache... da kann ein "hobbyprogrammierer" durchaus mit einem pro mithalten... je nach dem wie groß das interesse ist... nur nicht mit dem budget...

#44

2006-03-22, 17:24:53

Das ändert alles nichts an dem simplen Gesetz.

Cell und Xenos sind sehr schnell von seriellem Code limitiert und auch bei PC-Multicores wird das ein Problem werden.

Auch die besten Leute werden daran nichts ändern können.

hätte nicht gedacht das ich dir heute noch mal komplett zustimme :D
über das thema wann dieses wird eintrifft will ich nit streiten das wäre sinnlos... das muss einfach die zukunft zeigen. aber hier haben wir es mit einer technik (gerade im games bereich) in den kinderschuhen zu tun... da wurde schon viel spekulert "schneller wirds nicht mehr" (kommentar zum p1 200mhz (oder so ähnlich, kann mich nicht genau erinnern da ich da selbst noch in den kinderschuhen steckte ;) ))

obwohl... es wurden schon viele probleme gelöst indem man sie umging... (bezug zu deinem letzten satz)

Neomi

2006-03-22, 17:33:28

Ich selbst bin mir sicher, dass ich genügend Kenntnis habe um das zu beruteilen. Neomi hat mir auch nie so richtig wiedersprochen, wie dir evtl. aufgefallen sein sollte.

Mit dem könnte ich ewig darüber diskutieren, weil ich auch merke dass er etwas davon versteht, aber bei euch ist es einfach nur lästig.

Danke, gleichfalls! :)

Neomi hat dir duchaus widersprochen, nur verhält er sich wesentlich diplomatischer, als Du, und ich denke er weiß, dass Du sowieso nicht von deiner Meinung abweichst, so wie man das bereits von dir kennt. ... Im übrigen auch seltsam, dass ich Neomis Meinung absolut nachvollziehbar und kompetent empfinde, ganz im Gegensatz zu deinen Aussagen, wobei Du doch meinst, dass ihr einer Meiung seid.

Die Frage ist, ob er ewig mit dir darüber diskutieren will. X-D

Moooment, widersprochen habe ich nicht wirklich. Coda hat durchaus Recht, es fehlt nur ein wenig der Optimismus. Im Grunde sind wir tatsächlich einer Meinung, das sieht nicht nur er so. Und ja, ich könnte ebenfalls ewig mit ihm darüber diskutieren, aber leider hat ein Tag nur 24 Stunden.

PS: von den einzelnen Cores der neuen Konsolen bin ich ebenfalls nicht wirklich begeistert. Daß MS sich nicht für eine andere CPU entschieden hat, halte ich für eine Kostenfrage (und in dem Zusammenhang ist die Entscheidung durchaus richtig), nicht für eine technisch orientierte Entscheidung. Ich mache mir zwar lieber Gedanken darum, was damit machbar ist, als das nicht machbare zu bemängeln, aber toll finde ich die Wahl auch nicht gerade.

PS/2: die echten Profis in diesem Gebiet SIND Hobbyentwickler, die ihr Hobby zum Beruf gemacht haben. Außerdem hat Talent nichts mit dem Budget zu tun.

Aqualon

2006-03-22, 17:33:33

betasilie

2006-03-22, 17:37:01

Das ändert alles nichts an dem simplen Gesetz.

Cell und Xenos sind sehr schnell von seriellem Code limitiert und auch bei PC-Multicores wird das ein Problem werden.

Auch die besten Leute werden daran nichts ändern können.
Natürlich, da widerspreche ich auch garnicht, aber man wird Wege finden andere Wege zu gehen. Dass Multicore-Entwicklungen in nächster Zeit erstmal Probleme verursachen und den Profis viel Kopfschmerzen bereiten, will ich nicht auf keinen Fall verneinen, aber die Entwicklung wird und muss vorangehen, denn Multicore ist die Zukunft und man wird sicherlich sehr schnell lernen anders zu entwicklen, als das bisher üblich war.

Und genau da wird sich die Preu vom Weizen trennen, denn es gibt halt einige Genies in der Branche, die sich vom Durchschnitt absetzen.

du redest vom coden wie vom leistungssport... aber alles was man beim coden brauch ist: LOGIK, u.U hardwareverständniss, und die nötigen befehle der programmiersprache... da kann ein "hobbyprogrammierer" durchaus mit einem pro mithalten... je nach dem wie groß das interesse ist... nur nicht mit dem budget...
Ich habe in menem Bekanntschtskreis Entwickler - und ja, die wirklichen Cracks sehen das als Leistungssport.

Und Du willst doch nicht verneinen, dass es durchaus Talente oder Genies unter den Entwicklern gibt, die sich von der Konkurrenz weit absetzen und von Hobbyprogrammieren ohnehin?

#44

2006-03-22, 17:39:07

Es können sich doch durch Multicore auch ganz neue Möglichkeiten ergeben. Beispielsweise komplett dynamisch generierte Level. Während man ein Level gerade spielt, kann ein anderer Core schon mal den nächsten Level berechnen und man spart sich die Ladezeit bzw. kann das ganze ausgefeilter machen.

das mit den leveln ist eher ne speicherfrage denke ich. ausserdem bsp oblivion: da kommt schon streaming zum einsatz (aber das könnte dadurch sicher verbessert werden da hast du recht)

Und Du willst doch nicht verneinen, dass es durchaus Talente oder Genies unter den Entwicklern gibt, die sich von der Konkurrenz weit absetzen und von Hobbyprogrammieren ohnehin?

genies gibts überall... das zählt nicht ;) du hast einfach nur von profis geredet... und vlt ist dir nicht bewusst das viele dieser eben jener auch mal "nur" hobbyprogrammierer gewesen sind...

ich sag mal so: 75 % der programmierung sind Logik... der rest wissen um die programmiersprache... meistens scheitert es an dem 1. weil man das 2. leicht erlernen kann

nur weil man für etwas bezahlt wird kann man es nicht unbedint auch besser...
aber du hast natürlich nicht unrecht... (auch wenn solche talente genauso unter den hobbyprogrammierern sind) nur hast du das kann in meinem satz vlt zu ernst genommen ;)

und ja, die wirklichen Cracks sehen das als Leistungssport.

du meinst die cracker... ;) ;) ;) weil die liefern sich mit dem herstellen von cracks/keygens teilweise echt rennen darum als erste einen rauszubringen...
ansonsten naja... ich glaube eher das die meisten "einfach nur ihrer arbeit (bzw hobby) nachgehen"

@neomi: den aspekt budget hab ich nur aufgenommen um zu verdeutlichen das ein hobbyprogrammierer nicht soviel zeit aufwenden kann (ausser er ist ein guter dieb ;) ) weil er noch anderes zu tun hat. daran hat beta wohl auch das mit dem "profi" festgemacht

Neomi

2006-03-22, 18:05:34

- Rendering cannot occur until the final state of the frame is decided. <--- ist das jetzt anderst??? heutzutage macht das halt eben ein core nacheinander... da müssen sich eben die programmierer drum kümmern...

Gerade das stimmt nicht. Sicher, das Rendering kann man nicht abschließen, aber man kann schonmal anfangen. Man kann schonmal die Landschaft zeichnen, während ein anderer Thread die Objekte zusammensammelt, die sichtbar sind. Man muß erst dann mit dem Zeichnen warten, wenn man die Ergebnisse braucht. Und wenn noch nicht entschieden ist, ob ein Objekt sichtbar ist oder nicht, wenn der Renderthread soweit ist, ist auch nicht sonderlich schlimm. Dann zeichnet man eben einfach spekulativ. Das ist zwar langsamer als nicht zeichnen, falls das Objekt nicht sichtbar ist, aber schneller als auf das Ergebnis zu warten und dann zu zeichnen.

Das größte Problem (aber das hängt sehr vom Genre des Spiels ab) ist meiner Meinung nach derzeitig, daß Drawcalls immer nur in dem einen Thread ausgeführt werden können, in dem das 3D-Device erstellt wurde. Das ist zwar für fast alle Fälle die einzige Möglichkeit, kostet aber massig Zeit. Mit Vista wird sich das Problem nicht erledigen, aber immerhin stark entzerren dank des schlankeren Treibermodells (deutlich weniger Overhead).

betasilie

2006-03-22, 18:13:13

HellHorse

2006-03-22, 18:17:52

Als Programmierer ist man in der Spielebranche (quasi genau mein Gebiet) falsch, wenn man nicht bereit ist, neue Dinge auszuprobieren.
Klar, deshalb sind ja so gut wie alle Spiele in C++ geschrieben. Scheisse, wenn ich daran denke, dass für Tim Sweeny Nullpointer derefenzierien immer noch ein grosses Problem ist. Genauso wie ArrayIndexOutOfBounds Exceptions. Der könnte seinen ganzen numerischen Code mit Sachen wie Sisal parallelisieren, seit mehr als 10 Jahren, aber eben, GameDev X-D
@Coda
Wie Du sehen kannst, ist deine Meinung zu Multicore nicht umumstritten. Nimm es nicht persönlich, Du bist sicher kompetenter als ich, aber oft vertrittst Du Meinungen etwas lautstark, die so nicht haltbar sind und bist in gewissen Bereichen eher ablehnend und pessimistisch.
Coda ist bloss realitisch, weil er im Gegsatz zu den Optimisten Multithreaderfahrungen hat.
Die richtigen Cracks in den Spielestudios, die sowieso überwiegend im Konsolenbreich zu finden sind, werden schon schnell Fortschritte machen und neue Herrangehensweisen finden, Multicoresysteme gut auszulasten. Und dass man bei Muticorelösungen bei den meisten Codes etwas unter der Effizienz von Singethreadlösungen bleiben wird, bestreitet ja auch niemand, aber da Multicore auf dem breiten Markt erst seit kurzem verfügbar ist, wird man sich erst jetzt im großen Stil mit Multicorecodes in Spielen beschäftigen und entsprechende Fortschritte bei der Entwicklung neuer Codes machen.
Die gleichen Cracks, die bloss ein logische XBox 360 CPU auslasten? X-D
Die immer noch die Lösung aller Probleme in C++ sehen? X-D

Ja, die schaffen es sicher innerhalb von 6 Monaten eine Game Engine zu schreiben, die super mit meheren Cores skaliert X-D
Spiele sind mit Sicherheit keine inhärent parallelisierbares Programme. Allein schon der ganze Script-Code der geschrieben wird und oft einen Großteil der Runtime von z.B. Far Cry oder UT2004 ausmacht ist so per se nicht parallelisierbar. Ich weiß allerdings nicht ob Sweeney an UnrealScript was geändert hat für UT2007.
Wenn man das PDF zu "seiner nächsten Programmiersprache" anschaut hat der dafür keine Idee (von dem her ist hier in den nächsten Jahren nichts zu erwarten). Für den numerischen Code will er etwas funktionales (macht automatische Parallelisierung per Compiler möglich da keine Nebeneffekte). Ich musste unweigerlich an Sisal denken, was genau das macht.

robobimbo

2006-03-22, 20:07:09

Ich denke mir eher, Intel wird AMD samt x86-64 nun platt machen wollen. Erstmal spielen sie brav mit.

*kristallkugel*

Intel wird weiterhin brav mitspielen und AMD leben lassen. Würden sie AMD plätten wären sie defacto Monopolist im PC Markt und dann hätten sie die FTC am Hals. Ich glaub denen ist es lieber gut Geld zu verdienen (was sie ja machen) und weiterhin grösster Chipproduzent zu sein

bg

robo

Gast

2006-03-22, 20:22:02

Nebensächliche Frage:

Die Schwellenspannung von Silizium beträgt 0,7 Volt. Wir sind heute, bei 65 nm-Fertigunstechnologie (Intels Presler), bei 1,2 Volt Betriebsspannung angelangt. In spätestens ein paar Jahren, bei evtl. 45 nm-Fertigungstechnologie, wenn die CPU-Spannung unter 1 Volt rutscht, kann es gar nicht mehr weitergehen mit der CPU-Entwicklung auf Silizium-Basis. Das Potenzial von Silizium ist dann fast komplett ausgeschöpft. Wie wird es denn dann weitergehen?

Neomi

2006-03-22, 21:00:45

Klar, deshalb sind ja so gut wie alle Spiele in C++ geschrieben. Scheisse, wenn ich daran denke, dass für Tim Sweeny Nullpointer derefenzierien immer noch ein grosses Problem ist. Genauso wie ArrayIndexOutOfBounds Exceptions. Der könnte seinen ganzen numerischen Code mit Sachen wie Sisal parallelisieren, seit mehr als 10 Jahren, aber eben, GameDev X-D

Ist ja nett von dir, daß du mal eben alle Spieleentwickler über einen Kamm scheerst. Danke. Da ich auch zu der Sippe gehöre, muß ich mich ja angesprochen fühlen.

C++ ist doch nicht deshalb schlecht, weil manche Leute mit den erweiterten Möglichkeiten gegenüber anderen Sprachen nicht klarkommen. Und nur, weil beim unachtsamen Umgang mit Pointern auch etwas schief gehen kann, sind gleich alle Entwickler verbohrt, die die Sprache trotzdem nutzen? Ich habe keine Probleme mit Pointern, warum soll ich also auf die Vorteile verzichten? Oder nehmen wir mal die Bereichsüberprüfung von Arrays. Warum sollte man damit Zeit vergeuden, wenn unter gar keinen Umständen ein Index außerhalb des gültigen Bereichs vorkommen kann? Und wenn die Überprüfung doch mal nötig ist, ist sie auch mit C++ kein Thema. Nenne mir einen Nachteil von C++, den man nicht problemlos umgehen kann.

AnPapaSeiBua

2006-03-22, 21:01:14

Diese Schwellenspannung gilt doch nur für NPN- und PNP-Transistoren, aber doch nicht für FETs, die für CPUs verwendet werden.

BlackBirdSR

2006-03-22, 21:30:27

Diese Schwellenspannung gilt doch nur für NPN- und PNP-Transistoren, aber doch nicht für FETs, die für CPUs verwendet werden.

Läuft doch mein PM schon bei 0.7V ;)

Trap

2006-03-22, 23:15:12

Nenne mir einen Nachteil von C++, den man nicht problemlos umgehen kann.
Man kann nicht problemlos haben:
-hot-code-replacement
-concurrent code (alles von Hand machen müssen ist nicht problemlos)
-closures
-Eingabefeld für beliebige C++-Ausdrücke die dann im laufenden Programm ausgeführt werden für explorative programming
-Metaprogrammierung in C++ ist meiner Meinung nach nicht problemlos sondern grauenhaft hässlich

Coda

2006-03-22, 23:23:24

C++ ist was Multithreading angeht wirklich ganz bestimmt nicht der Weisheits letzter Schluss. Aber C# und Java sind es garantiert auch nicht.

Es wird Zeit für eine neue Herangehensweise, aber leider sind da viele Leute viel zu festgefahren mit ihren alten Denkweisen.

Wisst ihr wie man die SPEs des Cells ansteuert wenn ein Linux-Kernel drauf läuft? Per Filesystem. Ich hab echt nur gedacht: :|

HellHorse

2006-03-23, 00:22:16

C++ ist was Multithreading angeht wirklich ganz bestimmt nicht der Weisheits letzter Schluss. Aber C# und Java sind es garantiert auch nicht.
Natürlich nicht, die implementieren ja auch nur ein Jahrzehnte altes Model, das in dieser Zeit die Schwächen deutlich aufzeigte.
Wenn man schaut wie langsam sich die Welt entwicklet und wie wenig heute gemacht wird, was es nicht schon vor 40 Jahren gab, es recht unwahrscheinlich, dass sich in 4 Jahren Probleme lösen lassen, die sich in all der Zeit nicht lösen liessen.

#44

2006-03-23, 07:19:57

Wisst ihr wie man die SPEs des Cells ansteuert wenn ein Linux-Kernel drauf läuft? Per Filesystem. Ich hab echt nur gedacht: :|

:| eeehm ja... vlt kann man die ja auch als zwischenspeicher missbrauchen ;D :ucrazy3: :ulol3:

Ganon

2006-03-23, 08:03:13

Es wird Zeit für eine neue Herangehensweise, aber leider sind da viele Leute viel zu festgefahren mit ihren alten Denkweisen.

Ich mag mich jetzt irren, aber gibt es nicht ne Programmiersprache die parallele Abarbeitung vorsieht? Ich meine mal sowas gelesen zu haben, aber ich weiß es leider nicht mehr so genau...

Shink

2006-03-23, 08:22:08

Sowas gibt es eigentlich in Fortran (wenn auch nicht jeder Compiler etwas sinnvolles damit anstellt)

Gast

2006-03-23, 08:57:44

C++ ist was Multithreading angeht wirklich ganz bestimmt nicht der Weisheits letzter Schluss. Aber C# und Java sind es garantiert auch nicht.

Inwieweit unterscheidet sich denn das Multithreading von C++ zu dem von
C#/Java? Oder anders, beide greifen sowieso auf die API's der OS'e zu, um Threads zu erstellen/verwalten. Inwieweit soll denn da C++ einen Nachteil haben, außer dass es vielleicht bei C#/Java nett gekapselte bzw. leicht zu bedienende Klassen gibt?

Es wird Zeit für eine neue Herangehensweise, aber leider sind da viele Leute viel zu festgefahren mit ihren alten Denkweisen.

Ein paar Bsp. wären ganz nett.

Trap

2006-03-23, 09:57:37

Ein paar Bsp. wären ganz nett.
Erlang, C-omega oder transactional memory sind Sachen die ich mir angeguckt hab.

Sogar OpenMP würde ich als neue Herangehensweise zählen, auch wenn es mittlerweile so Mainstream ist dass selbst MS VisualC++ es supported.

Gast

2006-03-23, 10:25:02

Erlang, C-omega oder transactional memory sind Sachen die ich mir angeguckt hab.

Dazu kann ich nichts sagen, aber gib doch mal bitte konkrete Bsp. wo genau etwas gemacht wird, dass mit C++ nicht geht. Ist C Omega nicht eine Studie zu Microsoft, in die Datenabfrage einfach gehandelt werden soll/kann?

Sogar OpenMP würde ich als neue Herangehensweise zählen, auch wenn es mittlerweile so Mainstream ist dass selbst MS VisualC++ es supported.

Was ja überwiegend sowieso nur bei C++ zum Einsatz kommt. Und selbst dann macht es nichts, was man nicht auch ohne hinbekommen müsste oder sehe ich das falsch? Maximal kann man das Threading irgendwie in syntaktischen Zucker verpacken, was aber auf OS Ebene passiert ist eh das selbe und wo genau man es anwenden muss, wird einem auch noch nicht abgenommen.

Trap

2006-03-23, 10:44:58

HellHorse

2006-03-23, 11:02:41

Ein paar Bsp. wären ganz nett.
Ich wiederhole mich nur ungerne:
Sisal, funktional (single assignment => keine Nebeneffekte), dadruch kann der Compiler den Code automatisch (0 Aufwand von Seiten des Programmierers) parallelisieren, hauptsächlich für numerischen Code interessant.

C++ ist doch nicht deshalb schlecht, weil manche Leute mit den erweiterten Möglichkeiten gegenüber anderen Sprachen nicht klarkommen.
Mein Problem mit C++ sind nicht Leute, die es beherrschen. Mein Problem mit C++ sind Leute die C++ einsetzen und es nicht beherrschen. Was sind für mich untrügliche Zeichen, dass jemand C++ nicht beherrscht? BufferOverflows und MemoryLeaks. Wenn man sich anschaut viel Software für BufferOverflows anfällig ist, sind das verdammt viele. Wenn Tim Sweeny angibt NullPointer und IndexOutOfBounds sind ein wichtiges Problem, das gelöst werden muss, dann spricht das wohl nicht gerade für den gekonnten Umgang seiner Kunden mit C++.
Das macht ingesamt verdammt viele Fälle, in denen C++ nicht eingesetzt werden sollte, weil es die Entwickler einfach nicht beherrschen.
Nenne mir einen Nachteil von C++, den man nicht problemlos umgehen kann.
All die Leute die kleinen Plan davon haben und es trotzdem einsetzen.

Gast

2006-03-23, 11:04:12

C-omega hat mehrere Teile, der den ich meine hieß vorher Polyphonic C#.

Es geht nicht darum, dass irgendwas mit C++ nicht geht, sondern dass es nicht einfach und zuverlässig geht.
http://en.wikipedia.org/wiki/Software_transactional_memory finde ich einfach.

Ich will den Nutzen garantiert nicht absprechen, aber es ist eben IMO eher eine evolutionäre Entwicklung, nichts ground braking, fußt immer noch auf die selben Konzepte auf. Das mit STM klingt interessant, werde ich mir mal genauer anschauen. Allerdings, was ich so schnell überflogen habe, geht es ja nur um Transaktionen im Programmablauf. Transaktionen selbst verlaufen nun mal aber sequentiell ab, nichts mit Parallelisierung. Und ob man damit nun leicht das Synchronisieren beim Threading erledigen kann, ändert ja nichts daran, dass man erst mal Threads erstellen muss, die sinnvoll ausgelastet werden. Aber ich muss mir das erst mal genauer anschauen, denn da fehlen mir einfach die Infos.

Trap

2006-03-23, 12:02:29

Ja, software transactions sind nur eine Kontrollstruktur zur Synchronisation von threads. Aber eine viel einfachere und eher für komplexer Programme geeignete Kontrollstruktur als manuelle Synchronisation mit mutexes/locks/crititcal sections.

Polyphonic C# geht eher in die Richtung message-passing und keine geteilten Ressourcen. Ohne geteilte Ressourcen braucht man natürlich auch keine Synchronisation der Zugriffe darauf.

Automatische Parallelisierung hat ähnliche Probleme zu lösen wie automatische Verifikation, daher vermute ich mal, dass es in offensichtlichen Fällen funktioniert und/oder in speziell dafür konstruierten, recht eingeschränkten Sprachen. Praktische Erfahrungen damit hab ich allerdings keine.

Neomi

2006-03-23, 14:48:04

Das macht ingesamt verdammt viele Fälle, in denen C++ nicht eingesetzt werden sollte, weil es die Entwickler einfach nicht beherrschen.

All die Leute die kleinen Plan davon haben und es trotzdem einsetzen.

Bei manchen Sourcen, die ich so sehe, bin ich auch "entsetzt", das Problem kenne ich. Also nichts, was wirklich gegen C++ selbst spricht, sondern gegen schlechten Code, der hier mehr Zerstörungspotential hat. Ich verzichte aber nicht deshalb auf die Vorteile, weil nicht jeder sie nutzen kann.

Die Vorteile anderer Sprachen, wie Trap sie oben genannt hat, sind durchaus da. Aber ich habe da nichts gesehen, was nicht mit vertretbarem Aufwand auch in C++ geht. Letztendlich sind die einzigen Dinge, die per C++ unlösbar sind, nur mit Assembler machbar.

][immy

2006-03-23, 16:05:05

Bei manchen Sourcen, die ich so sehe, bin ich auch "entsetzt", das Problem kenne ich. Also nichts, was wirklich gegen C++ selbst spricht, sondern gegen schlechten Code, der hier mehr Zerstörungspotential hat. Ich verzichte aber nicht deshalb auf die Vorteile, weil nicht jeder sie nutzen kann.

Die Vorteile anderer Sprachen, wie Trap sie oben genannt hat, sind durchaus da. Aber ich habe da nichts gesehen, was nicht mit vertretbarem Aufwand auch in C++ geht. Letztendlich sind die einzigen Dinge, die per C++ unlösbar sind, nur mit Assembler machbar.

klar kannst du auch alles in C++ machen was in Java oder C# geht, wahrscheinlich sogar noch ein wenig mehr. aber das ist ja auch eine frage des aufwands. neue Programmiersprachen entwickeln sich ansich nicht weil mit der vorherigen etwas nicht möglich wäre, sondern weil die alte zu unkomfortabel geworden ist und das entwickeln verlangsamt. ansonsten würden wir heute noch alles in assemblercodes oder noch schlimmer Bytecodes schreiben.

Desto komplexer programme werden, desto eher kann man die vorteile neuerer Programmiersprachen erkennen. Was in C++ mehrere Befehle benötigt ist in C# dann nur noch ein Einzelner befehl oder ähnliches.

Allein schon die Programmierung von Direct3D in C++ und C# unterscheidet sich recht stark. während man in C++ noch vieles manuell machen muss hat man für C# Managed DirectX welches die Anprogrammierung von Direct3D extrem vereinfacht. Also ist der Aufwand sehr gering. Außerdem kümmert sich C# oder Java der Garbage Collector direkt darum das der Speicher auch korrekt freigegeben wird, was man in C++ noch manuell machen musste. Zwar ist der Code von Java und C# meist noch ein ganzes stück langsamer als der von c++, aber der Aufwand ist viel geringer und damit ist die Entwicklung ein ganzes stück schneller.

Noch ist zwar nicht die zeit gekommen wo C++ fast komplett abgelöst werden kann, aber auch diese Zeit wird einmal kommen in der C++ "nur" noch eine nebenprogrammiersprache ist. Welche Programmiersprache allerdings dann führend sein wird, tja wer weiß das schon, derzeit sieht es aber so aus als würde dies zumindest eine Java-Ähnliche sprache werden (C# ist zumindest aus meiner sicht ein von microsoft "ausgeliehenes" und verbessertes java).

PHuV

2006-03-23, 16:16:56

Mein Problem mit C++ sind nicht Leute, die es beherrschen. Mein Problem mit C++ sind Leute die C++ einsetzen und es nicht beherrschen. Was sind für mich untrügliche Zeichen, dass jemand C++ nicht beherrscht? BufferOverflows und MemoryLeaks. Wenn man sich anschaut viel Software für BufferOverflows anfällig ist, sind das verdammt viele. Wenn Tim Sweeny angibt NullPointer und IndexOutOfBounds sind ein wichtiges Problem, das gelöst werden muss, dann spricht das wohl nicht gerade für den gekonnten Umgang seiner Kunden mit C++.
Das macht ingesamt verdammt viele Fälle, in denen C++ nicht eingesetzt werden sollte, weil es die Entwickler einfach nicht beherrschen.

All die Leute die kleinen Plan davon haben und es trotzdem einsetzen.

Das Problem haste aber in C auch, und wozu gibt es Purify und Quantify von Rationtial Rose bzw. nun von IBM ;) .

Und zu Microsoft und C#, anstelle so eine Grütze wie C# zu verbrechen hätte M$ lieber mal in den aktuellen Entwicklungsungebungen wie VC und .Net200x mal den C99-Standard einführen sollen.

ScottManDeath

2006-03-23, 18:02:46

Das Problem haste aber in C auch, und wozu gibt es Purify und Quantify von Rationtial Rose bzw. nun von IBM ;) .

Und zu Microsoft und C#, anstelle so eine Grütze wie C# zu verbrechen hätte M$ lieber mal in den aktuellen Entwicklungsungebungen wie VC und .Net200x mal den C99-Standard einführen sollen.

Hast Du mit C# gearbeitet? Bzw. was findest Du daran "Grütze"?

Demirug

2006-03-23, 18:44:47

So stur sind Spieleentwickler auch nicht:

It was a blast to connect with customers, answer their questions, and hear about the cool things they wanted to do with XNA Framework. All of the developers readily identified with the productivity gains that C#, and more specifically managed code, would enable. Everyone was impressed with the Culture and Pocket-Jongg built from the same source, running on both Windows XP and Xbox 360 on our custom version of the CLR. In addition to industry professionals, many from academia were also interested in the platform.

http://blogs.msdn.com/robunoki/archive/2006/03/23/558724.aspx

IMHO ist C# einfach eleganter als C++

D3D10_TECHNIQUE_DESC techDesc;
g_pTechnique->GetDesc( &techDesc );
for( UINT p = 0; p < techDesc.Passes; ++p )
{
g_pTechnique->GetPassByIndex( p )->Apply(0);
g_pd3dDevice->Draw( 3, 0 );
}

vs.

foreach (D3D10.EffectPass pass in technique.Passes)
{
pass.Apply();
device.Draw(3, 0);
}

SCNR

HOT

2006-03-23, 19:05:30

C++ ist im Prinzip einfach zu aufwändig für heutige Spieleentwickler könnt ich mir vorstellen, wie aber auch für andere Entwicklungen. Unsere Firma z.B. steigt langsam aber sicher komplett auf Java um (und wir sind ein Laden mit über 1000 Mitarbeitern, machen aber keine Spiele :D) einfach weil der Support dadurch entlastet wird - es werden wesentlich weniger Fehler gemacht und wenn findet man sie leichter.
Wurden vor einigen Jahren noch viele Sache ziemlich prozedural gemacht, ist heute Objektorientierung state of the Art.
Ich weiss nicht wie es in der Spielebranche ist, aber bei uns wird C++ eigentlich nurnoch für Produktpflege eingesetzt. Ansonsten wird C# oder noch lieber Java eingesetzt.
Ein guter Kumpel von mir arbeitet in einer Microsoft zertifizierten Bude und die setzen fast ausschliesslich auf C#, einfach weil es schneller geht ;)

Coda

2006-03-23, 20:13:09

Da bei Spielen das letzte bischen Leistung zählt wird sich da C++ wohl noch einige Zeit lang halten vermute ich (zumindest bei den absoluten Grafikkrachern).

Ganon

2006-03-23, 20:39:32

Da bei Spielen das letzte bischen Leistung zählt wird sich da C++ wohl noch einige Zeit lang halten vermute ich (zumindest bei den absoluten Grafikkrachern).

Ich würde auch Grafikpracht ohne Ende opfern, wenn durch leichtere Programmierung endlich mal die Spiele vom Gameplay und Story besser werden. ;)

Naja. Egal, ist nicht das Thema. OK. Das andere bisher auch nicht. ;)

Aber bei steigender Grafikkarten-Belastung sollte doch die verwendete Programmiersprache für Grafik doch eher nebensächlich werden, oder?

Trap

2006-03-23, 20:43:54

Etwas anderes als C++ zu benutzen muss auch für Spiele nicht schlecht sein, mindestens ein AAA-Titel für PS2 ist in was anderem geschrieben und war sehr erfolgreich.

So erfolgreich, dass Sony die Entwickler gekauft hat und darauf bestanden hat, dass der Nachfolger in C++ programmiert wird...

Demirug

2006-03-23, 20:44:36

Da bei Spielen das letzte bischen Leistung zählt wird sich da C++ wohl noch einige Zeit lang halten vermute ich (zumindest bei den absoluten Grafikkrachern).

Es sind in der Regel maximal 5% des Codes wieklich performance kritisch. Da kann dann C++/CLR sehr gute Dienste leisten.

Das Problem ist hier mal wieder eine Fall von Henne und Ei. Die Entwickler nutzen kein .Net weil es kaum Middleware gibt und es gibt kaum Middleware weil kaum ein Entwickler .Net nutzt.

Das zweite Problem ist die bisher fehlenden Portierbarkeit im Konsolenumfeld.

Coda

2006-03-23, 20:47:48

Es sind in der Regel maximal 5% des Codes wieklich performance kritisch. Da kann dann C++/CLR sehr gute Dienste leisten.Klar, da hast du sicher recht.

][immy

2006-03-24, 22:48:27

Es sind in der Regel maximal 5% des Codes wieklich performance kritisch. Da kann dann C++/CLR sehr gute Dienste leisten.

Das Problem ist hier mal wieder eine Fall von Henne und Ei. Die Entwickler nutzen kein .Net weil es kaum Middleware gibt und es gibt kaum Middleware weil kaum ein Entwickler .Net nutzt.

Das zweite Problem ist die bisher fehlenden Portierbarkeit im Konsolenumfeld.

ui, so wenig ist das nur noch. die hatten doch auch mal die quake 2 engine auf c# bzw .net umgeschrieben und es war "nur" etwa 20% langsamer als der C-code. allerdings war das auch noch .net 1.x und nicht 2.0 und noch nicht großartig optimiert

das kaum .net eingesetzt wird sehe ich ein wenig anders. klar in der spiele-entwicklung wird das noch einige zeit dauern, aber .net programme für windows-systeme sind eigentlich nicht mehr mangelware. bzw viele firmen entwickeln schon seit einiger zeit mit .net.

einer der vorteile von .net ist ja, das ein programm auf ein system optimiert wird ohne das das programm noch geändert werden muss. schließlich werden die assemblies bei einem start auf einem anderne system neu compiliert und automatisch auf das system optimiert (sofern das framework entsprechende system-optimierungen kennt bzw der compiler). ganz nebenbei hat man dadurch wie bei java die plattform-unabhängigkeit erreicht. ich glaube zwar kaum das es für konsolen in nächster zeit ein .net framework geben wird, aber immerhin wäre es wie bei java möglich

Demirug

2006-03-24, 23:03:57

[immy']ui, so wenig ist das nur noch. die hatten doch auch mal die quake 2 engine auf c# bzw .net umgeschrieben und es war "nur" etwa 20% langsamer als der C-code. allerdings war das auch noch .net 1.x und nicht 2.0 und noch nicht großartig optimiert

IIRC wurde da einfach der C Code genommen und nur gerade soviel geändert das es der managed C++ compiler compiliert.

[immy']das kaum .net eingesetzt wird sehe ich ein wenig anders. klar in der spiele-entwicklung wird das noch einige zeit dauern, aber .net programme für windows-systeme sind eigentlich nicht mehr mangelware. bzw viele firmen entwickeln schon seit einiger zeit mit .net.

Ich bezog mich nur auf die Spieleentwicklung.

[immy']einer der vorteile von .net ist ja, das ein programm auf ein system optimiert wird ohne das das programm noch geändert werden muss. schließlich werden die assemblies bei einem start auf einem anderne system neu compiliert und automatisch auf das system optimiert (sofern das framework entsprechende system-optimierungen kennt bzw der compiler). ganz nebenbei hat man dadurch wie bei java die plattform-unabhängigkeit erreicht. ich glaube zwar kaum das es für konsolen in nächster zeit ein .net framework geben wird, aber immerhin wäre es wie bei java möglich

Microsoft hat für die XBox360 einen Framework und mindestens zwei Spiele die sowohl auf dem PC wie auch auf der XBox 360 laufen. Das ganze läuft unter der Bezeichnunbg "XNA Framework".

Mir musst du .Net nicht schmackhaft machen. Ich würde wohl kaum selbst ein Managed Direct3D 10 schreiben wenn ich nicht von .Net überzeugt wäre.

Gast

2006-03-25, 00:13:29

[immy']

ganz nebenbei hat man dadurch wie bei java die plattform-unabhängigkeit erreicht. ich glaube zwar kaum das es für konsolen in nächster zeit ein .net framework geben wird, aber immerhin wäre es wie bei java möglich

plattformunabhängigkeit? theoretisch ja, aber praktisch gibts doch .NET nur für windows (ok, jetzt auch die XBOX360).

Gast

2006-03-25, 00:19:22

plattformunabhängigkeit? theoretisch ja, aber praktisch gibts doch .NET nur für windows (ok, jetzt auch die XBOX360).

Plattformunabhängigkeit ist ein ziemlich weitläufiger Begriff. Selbst wenn in der Praxis die volle .NET Funktionalität sich auf Windows beschränkt, auch wenn es tatsächlich Fremdimplementierungen wie Mono gibt, ist es immer noch plattformunabhängig. Ich kann die Plattform sogar auf eine einzelne Software/Softwarekonfiguration reduzieren, ist alles nur eine Definitionsfrage.

Gast

2006-03-25, 00:24:07

Plattformunabhängigkeit ist ein ziemlich weitläufiger Begriff. Selbst wenn in der Praxis die volle .NET Funktionalität sich auf Windows beschränkt, auch wenn es tatsächlich Fremdimplementierungen wie Mono gibt, ist es immer noch plattformunabhängig. Ich kann die Plattform sogar auf eine einzelne Software/Softwarekonfiguration reduzieren, ist alles nur eine Definitionsfrage.

naja, es ist immer alles eine definitionsfrage ;)

aber wäre Java da nicht die wesentlich bessere wahl, schließlich läuft es schon auf windows, linux, mac und sogar diversen portablen geräten.

ich kann mir jedenfalls nicht vorstellen dass MS runtimes für fremdplattformen herstellen wird, also ist diese "unabhängigkeit" doch nur auf MS-produkte beschränkt.

Gast

2006-03-25, 00:35:56

aber wäre Java da nicht die wesentlich bessere wahl, schließlich läuft es schon auf windows, linux, mac und sogar diversen portablen geräten.

Wenn diese ach so tolle OS Unabhängigkeit denn so dringend benötigt würde, würden heute alle nur noch in Java programmieren. Tut man aber nicht. In einigen Bereichen mag das ja durchaus zwingend sein, aber im Großen und Ganzen halte ich das einfach für substanzlose Argumente, die immer wieder aus der Schublade ausgekramt werden

ich kann mir jedenfalls nicht vorstellen dass MS runtimes für fremdplattformen herstellen wird, also ist diese "unabhängigkeit" doch nur auf MS-produkte beschränkt.

Richtig, damit habe aber weder ich noch viele andere ein Problem. Wer eben in der Praxis richtige OS Unabhängigkeit benötigt, der muss dann eben Java nehmen. So ergänzt sich doch beides sehr gut. Man muss ja nicht immer alles schwarz/weiß sehen. Auf der einen Seite schimpft man immer über die fehlenden Alternativen zu Windowsprodukten, auf der anderen Seite spricht man aber jenen den Status einer Alternative selbst gerne ab.

Gast

2006-03-25, 00:44:42

Wenn diese ach so tolle OS Unabhängigkeit denn so dringend benötigt würde, würden heute alle nur noch in Java programmieren. Tut man aber nicht. In einigen Bereichen mag das ja durchaus zwingend sein, aber im Großen und Ganzen halte ich das einfach für substanzlose Argumente, die immer wieder aus der Schublade ausgekramt werden

stimmt natürlich dass man nicht immer unbedingt die os-unabhängigkeit braucht.

aber dann lass mich die frage mal anders formulieren:
was ist an .NET soviel besser als in java, dass man überhaupt zu ersterem greift.

man kann ja durchaus in java programmieren auch wenn das programm schließlich nur auf einem zielsystem laufen soll, nur sehe ich ehrlich gesagt nichts schlimmes daran die option zu haben, das ganze auch auf anderen plattformen laufen zu lassen.

besser ausgedrückt: was sind die vorteile von .NET gegenüber java?
das java den vorteil der plattformunabhängigkeit hat habe ich ja schon erkannt, nur sehe ich in .NET keinen vorteil wenn es schon Java gibt.

btw: ich hab schon viel mehr java-anwendungen als net-anwendungen gesehen ;)

(del)

2006-03-25, 00:58:49

Intel wird weiterhin brav mitspielen und AMD leben lassen. Würden sie AMD plätten wären sie defacto Monopolist im PC Markt und dann hätten sie die FTC am Hals. Ich glaub denen ist es lieber gut Geld zu verdienen (was sie ja machen) und weiterhin grösster Chipproduzent zu seinJou, falsch ausgedrückt. Ich meinte eher AMD64 platt machen. WOLLEN. Andererseits erscheint mir das aber zu spät nun. MS will nicht für EPIC. Ist das größte Prob.

Imho kommen Dualcores ohne Frage in Fahrt. Ob nun 90% oder 60% bei gutem Kode, egal. Wie bei SLI. Vielleicht 2x2 noch. Mehr vertragen momentane Konzepte imho nicht wirklich. Ist schon alles erzählt worden von Coda&Co. Und wenn es anfänglich noch Probs geben wird, hilft man schnell mit Virtualisierung nach. Denn darunter stell ich mir nicht nur VMWare vor...

(del)

2006-03-25, 01:05:58

besser ausgedrückt: was sind die vorteile von .NET gegenüber java?das java den vorteil der plattformunabhängigkeit hat habe ich ja schon erkannt, nur sehe ich in .NET keinen vorteil wenn es schon Java gibt.

btw: ich hab schon viel mehr java-anwendungen als net-anwendungen gesehen ;)
Gegenfrage: Kannst Du Dir Catalysts CCC 1:1 in Java vorstellen.

Coda

2006-03-25, 01:08:34

Gegenfrage: Kannst Du Dir Catalysts CCC 1:1 in Java vorstellen.Wieso nicht? Man bräuchte nur ein wenig JNI-Code um die Registry anzusprechen.

MS will nicht für EPIC.Es gibt bereits ein IA64-Windows.

Gast

2006-03-25, 01:09:23

besser ausgedrückt: was sind die vorteile von .NET gegenüber java?
das java den vorteil der plattformunabhängigkeit hat habe ich ja schon erkannt, nur sehe ich in .NET keinen vorteil wenn es schon Java gibt.

Kann ich dir so nicht sagen, dazu müsste man sich exzellent mit beidem auskennen. Windows Entwickler, die bisher hauptsächlich mit Microsoft Produkten gearbeitet haben, z.B. die ganzen VB6 Entwickler. Das werden wohl Millionen sein, die werden wohl größtenteils auf .NET umgestiegen sein. Wenn du generell mit Microsoft Produkten arbeitest, vor allem Serverprodukte, bieten diese in den neuen Versionen hauptsächlich Features, die mit .NET implementiert sind bzw. sich über .NET ansprechen lassen.
Oder lass es mich anders ausdrücken: Ich möchte nicht in einer Welt mit Monokulturen leben, in der es nur Java gibt. ;)

btw: ich hab schon viel mehr java-anwendungen als net-anwendungen gesehen ;)

Das kommt ja darauf an in welchem Umfeld du dich bewegst. Wenn du einen .NET Entwickler fragst, wird er dir wohl genau das Gegentel nennen. Auf dem Desktop vom Mainstream User mag das sogar durchaus noch sein, aber ich prognostiziere einmal, dass sich gerade da in Zukunft ganz klar .NET vor Java etablieren wird, zumindest auf Windows. Auf dem Server wird sowohl Java, als aucb .NET intensiv eingesetzt.

Gast

2006-03-25, 02:18:45

btw: ich hab schon viel mehr java-anwendungen als net-anwendungen gesehen ;)

java ist erstens derbe lahm und zweitens ist .NET für zig sprachen verfügbar...

Coda

2006-03-25, 02:22:42

Java und .NET geben sich was sowohl JITC-Kompilat als auch JITC-Geschwindigkeit angeht fast nichts.

][immy

2006-03-25, 09:11:03

Java und .NET geben sich was sowohl JITC-Kompilat als auch JITC-Geschwindigkeit angeht fast nichts.
nunja, .net ist doch schon ein ganzes stückchen schneller als java.

wie ich schon irgendwo hier geschrieben habe, .net ist ein von microsoft "geliehenes" java, welches sie dann noch verbessert haben.
großer vorteil von .net ist auch die programmiersprachen unabhängigkeit. man kann code in VB, C++, C#, J# (bzw java) etc schreiben und trotdem noch ohne probleme mit den anderen assemblies die mit anderen .net programmiersprachen geschrieben wurden verbinden.

weiterer vorteil ist, das in .net auch nur das compiliert wird was benötigt wird und wenn es benötigt wird. das kann zwar gleichzeitig den nachteil haben das zwischendurch geladen wird, aber hat den vorteil das die startzeit kürzer ist.
gegenüber java ist es auch ein ganzes stück systemnäher als java.

zur plattformunabhängigkeit, das heißt nur, das du die programme auf ein anderes system portieren kannst, ohne diese umschreiben zu müssen. das ist genauso durch das .net FX gegeben wie durch die java runtime. zwar gibt es das .net FX derzeit fast nur für windows, aber eine portierung für andere plattformen ist möglich. nebenbei gibt es das .net FX auch für pda's und dergleichen (natürlich dann für windows ce ^^)

Ganon

2006-03-25, 10:31:46

Java und .NET geben sich was sowohl JITC-Kompilat als auch JITC-Geschwindigkeit angeht fast nichts.

Nunja. Je nach Plattform. Unter OS X ist Mono ein ganzes Stück schneller als Java, im GUI-Bereich. ;)

HOT

2006-03-25, 11:19:44

Gegenfrage: Kannst Du Dir Catalysts CCC 1:1 in Java vorstellen.

Ein CCC entwickelt auf SWT und JOGL Basis würde dem .net scheiss davonrennen.

HOT

2006-03-25, 11:21:37

java ist erstens derbe lahm und zweitens ist .NET für zig sprachen verfügbar...

Das ist ein Trugschluss. Swing ist lahm, Java ist schnell. Nicht so schnell wie C++ aber es wird mit jeder Version besser. Übrigens wird Java in der Spielentwicklung eingesetzt: Der Servercode von SWG ist AFAIK in Java geschrieben.

ScottManDeath

2006-03-25, 11:56:52

Ein CCC entwickelt auf SWT und JOGL Basis würde dem .net scheiss davonrennen.

Kannst Du dies begründen? Und warum sollte man in einem Treibereinstellungsmenü OpenGL verwenden? :confused:

(del)

2006-03-25, 13:26:44

Kannst Du dies begründen? Und warum sollte man in einem Treibereinstellungsmenü OpenGL verwenden? :confused:uhmm... bissl 3D macht das CCC schon. Sind ja nicht nur Knöpfe und Schieberegler ;)

(del)

2006-03-25, 13:35:47

Es gibt bereits ein IA64-Windows.Ich weiß, daß es den Server2003 dafür gibt. Für die Workstations tut sich aber nichts. Oder hab ich was verpasst?

Demirug

2006-03-25, 13:44:43

Ich weiß, daß es den Server2003 dafür gibt. Für die Workstations tut sich aber nichts. Oder hab ich was verpasst?

Wird es auch nicht geben solange die Verkaufzahlen von IA64 Hardware dermassen schlecht sind. Ausser ein paar Serveranwendungen wird auch kaum Software für IA64 geben.

Coda

2006-03-25, 13:48:55

[immy']nunja, .net ist doch schon ein ganzes stückchen schneller als java.Nö.

[immy']weiterer vorteil ist, das in .net auch nur das compiliert wird was benötigt wird und wenn es benötigt wird. das kann zwar gleichzeitig den nachteil haben das zwischendurch geladen wird, aber hat den vorteil das die startzeit kürzer ist.Das macht Java genauso.

[immy']gegenüber java ist es auch ein ganzes stück systemnäher als java.Aha. Ich weiß zwar was du meinst, und es ist auch nicht richtig.

Ein CCC entwickelt auf SWT und JOGL Basis würde dem .net scheiss davonrennen.Das glaube ich kaum. Wie gesagt, das nimmt sich fast nichts.

Nunja. Je nach Plattform. Unter OS X ist Mono ein ganzes Stück schneller als Java, im GUI-Bereich. ;)Das dürfte eher mit der Bibliothek zusammenhängen.

Ich weiß, daß es den Server2003 dafür gibt. Für die Workstations tut sich aber nichts. Oder hab ich was verpasst?Gab es mal. Wurde abgesägt, weil kein Markt.

Aber wenn Intel wirklich IA64 auf den Mainstream-Markt drängen will hat MS den Code so oder so.

Xmas

2006-03-26, 20:50:11

Genauso wie es mehrere .Net-Sprachen gibt, gibt es auch einige JVM-Sprachen, nicht nur Java.

Coda

2006-03-26, 20:51:29

Für Java war das aber nicht so richtig vorgesehen soweit ich weiß.

Gast

2006-03-27, 08:38:03

Genauso wie es mehrere .Net-Sprachen gibt, gibt es auch einige JVM-Sprachen, nicht nur Java.

Sind die aber auch so unkompliziert interoperabel untereinander? AFAIK braucht man bestimmte Klassen, um diese Interoperabilität zu gewährleisten und diese sind dann noch jeweils sprachabhängig.

Slipknot79

2006-08-24, 15:11:28

Tigerchen

2006-08-24, 15:22:24

EPIC hat zu viel gekostet. Das wird Intel nicht einfach so einbuddeln. Wobei ich IA64, nur vom Adressraum her gesehen, nicht als besser/sinnvoller als simples AMD64 ansehe. Ich denke mir eher, Intel wird AMD samt x86-64 nun platt machen wollen. Erstmal spielen sie brav mit. Dann (wenn!) verschwindet x86-64 wie HyperThreading und man wird uns EPIC aufs Auge drücken wollen. Die Investition war und ist einfach zu groß. Alles hängt davon ab, wie AMD das Vista-Zeitalter übersteht. Intel hat einen verdammt langen Atem. Irgendwann müßen aber auch sie wieder Luft holen. Und Mickeysoft "signalisiert" gelegentlich auch mal was. Ich würd EPIC noch nicht begraben, auch wenn ich mich nicht so drauf freue.

EPIC wird niemals kommen. Jetzt wo x86 mit den vielen Cores auch noch das Transputerkonzept mit aufgenommen hat sowieso nicht mehr.