Intel: prepare for 'thousands of cores' [Archiv]

Coda

2008-07-03, 02:31:29

Der RV770 von AMD/ATI hat auch 800 "Cores" im ALU-Teil. Dass es eigentlich nur 10 SIMD-Einheiten sind, verschweigt das Marketing ganz gerne. Was ähnliches erwarte ich auch bei Intel.
Ich nicht. Ergibt keinen Sinn bei dieser Ankündigung. Intel hat bei "Core" noch nie einzelne ALUs gemeint.

Tausende vollwertige x86-Cores, die autonom arbeiten können und dem Betriebssystem gegenüber transparent sind, halte ich für etwas unglaubwürdig in der absehbaren Zeit.
Er redet ja auch über die Zukunft. Das viel größere Problem bei 1000 Cores ist einfach das sobald man auch nur den geringsten Synchronisationsaufwand hat der Speedup zusammenpurzelt wie ein Kartenhaus.

del_4901

2008-07-03, 02:39:18

Er redet ja auch über die Zukunft. Das viel größere Problem bei 1000 Cores ist einfach das sobald man auch nur den geringsten Synchronisationsaufwand hat der Speedup zusammenpurzelt wie ein Kartenhaus.
Ach, wir werden das schonwieder ausbaden dürfen/müssen. Wird halt einfach nicht Syncronisiert :|

(del)

2008-07-03, 03:20:24

Irgendwie scheint Intel seit einiger Zeit den Gedanken zu verfolgen, daß man nicht alles dem Kernel überlassen kann bzw. daß man das nur mit einem SEHR großen Aufwand erledigen kann.
So ein Beispiel wären zB. die Stromsparfunktionen die immer mehr von der CPU selbst entschieden und gesteuert werden.

Als jemand der keinen Plan davon hat =) würde ich einen load balancer in die Architektur packen und die Last auf zB. die 500 Cores selbst verteilen und mich um die Syncronisation kümmern (mit zB. speziellen sync flags die der Programmierer den Threads mit auf den Weg gibt), statt sich wie bis jetzt komplett auf den Kernelscheduler zu stützen. Der Scheduler würde sich dann nicht mehr um die Threads, sondern nur um die Prozesse selbst kümmern müßen. Grob gesagt.

Für mich ist alles andere irgendwie der falsche primitive Weg. Bis auf paar spezielle Anwendungen sind nämlich auch 2008 mehr als 4 Kerne ein mittleres Drama. Was die Ideen der Entwickler angeht und erst recht was die Entwicklungswerkzeuge angeht. 4 Kerne sind ein kleines Drama :usweet:
Und auch wenn jetzt Leute die genauso oder noch weniger Plan haben wieder mit SupremeCommander kommen, sehe ich 2008 genausowenig Fortschritte diesbezüglich auf uns zukommen wie auch 2009 und 2010.

Die Skills der Programme/Programmierer und die von VC, ICC und GCC und die der Scheduler werden sich bis dahin imho nicht grundlegend ändern. Genau das aber wäre nötig.

Gast

2008-07-03, 16:26:21

Die Skills der Programme/Programmierer und die von VC, ICC und GCC und die der Scheduler werden sich bis dahin imho nicht grundlegend ändern. Genau das aber wäre nötig.
Dafür sind Taskbasierte Systeme wie TBB mit User-Space Scheduler da. Die meisten Anwendungen lassen sich damit sehr gut auch für wesentlich mehr als 4 Kerne parallelisieren, wenn man das Design von Grund auf entsprechend auslegt.
Komponentenweise Parallelisierung ist halt eine Sackgasse und momentan leider die am häufigst genutzte Lösung.

FlashBFE

2008-07-03, 16:40:37

Komponentenweise Parallelisierung ist halt eine Sackgasse und momentan leider die am häufigst genutzte Lösung.

Was heißt leider? Threads erzeugen auch einen Haufen Verwaltungsaufwand, was auch wieder Leistung kostet. Deshalb gilt beim Programmieren das Motto "nur soviel wie nötig". Würde man jeden Algorithmus, der nur irgendwie parallelisierbar ist, auf unterster Ebene in Threads aufteilen, wäre für das Gesamtprogramm die Anzahl an gleichzeitig laufenden Threads fast unberechenbar.

Gast

2008-07-03, 16:58:49

Was heißt leider? Threads erzeugen auch einen Haufen Verwaltungsaufwand, was auch wieder Leistung kostet. Deshalb gilt beim Programmieren das Motto "nur soviel wie nötig". Würde man jeden Algorithmus, der nur irgendwie parallelisierbar ist, auf unterster Ebene in Threads aufteilen, wäre für das Gesamtprogramm die Anzahl an gleichzeitig laufenden Threads fast unberechenbar.
Task != Thread
....

Coda

2008-07-03, 16:59:22

Die Skills der Programme/Programmierer und die von VC, ICC und GCC und die der Scheduler werden sich bis dahin imho nicht grundlegend ändern. Genau das aber wäre nötig.
Es wird immer so getan als wäre das der einzige limitierende Faktor...

Dafür sind Taskbasierte Systeme wie TBB mit User-Space Scheduler da. Die meisten Anwendungen lassen sich damit sehr gut auch für wesentlich mehr als 4 Kerne parallelisieren, wenn man das Design von Grund auf entsprechend auslegt.
Komponentenweise Parallelisierung ist halt eine Sackgasse und momentan leider die am häufigst genutzte Lösung.
Jain. Wenn man taskbasiert mit einem Abhängigkeitsgraph arbeitet dann muss man dort auch sicher an einigen Punkten trotzdem synchronisieren. Und nur 5% der Zeit daran vergeudet und man hat einen maximalen Speedup von 20 egal ob 100 oder 1000 Cores.

Monger

2008-07-03, 17:20:13

So lange wie es Computer gibt, so lange gibt es auch schon Bedarf an Parallelisierung. Und obwohl in dem Feld nun schon seit mindestens 20 Jahren intensiv gearbeitet wird, ist man da doch erschreckend wenig vorwärts gekommen: Multithreading ist immer noch das A und O, und wirft immer noch die selben Probleme auf.

Ich bin auch nicht überzeugt davon, dass hochparallele Verarbeitung überhaupt funktionieren KANN. Der Computer ist nunmal eine äußerst zentralisierte Struktur: die CPU gibt den Takt an, und alle Rechnerkomponenten liefern der CPU nur zu. In meinen Augen müsste man die gesamte klassische Rechnerarchitektur über Bord werfen, um da nennenswert weiterzukommen. Wie das aber konkret aussehen soll, entzieht sich komplett meiner Fantasie.

del_4901

2008-07-03, 17:45:54

Ich bin auch nicht überzeugt davon, dass hochparallele Verarbeitung überhaupt funktionieren KANN. Der Computer ist nunmal eine äußerst zentralisierte Struktur: die CPU gibt den Takt an, und alle Rechnerkomponenten liefern der CPU nur zu. In meinen Augen müsste man die gesamte klassische Rechnerarchitektur über Bord werfen, um da nennenswert weiterzukommen. Wie das aber konkret aussehen soll, entzieht sich komplett meiner Fantasie.
Nimm dir einfach ein Beispiel aus der Natur... es sitzt zwischen deinen 2 Ohren, da funktioniert das bisher prächtig.

Aquaschaf

2008-07-03, 18:01:49

sth

2008-07-03, 18:12:44

Nimm dir einfach ein Beispiel aus der Natur... es sitzt zwischen deinen 2 Ohren, da funktioniert das bisher prächtig.
...und ist so komplex das wir es bisher nur ansatzweise verstehen. ;)

"Thousands of cores" ... naja, für einige Anwendungen sicherlich praktisch, z.B. wenn man Rasterisierung, Raytracing, Physikberechung etc. auf dem Chip machen will. Aber sehr viele Algorithmen lassen sich eben nicht mal eben auf "thousands of cores" parallelisieren. Und mit diesen Grenzen schlägt man sich nicht erst seit gestern herum (Stichwort Supercomputing, Clustering). Sicherlich steckt in der heutigen Software noch immens viel ungenutztes Potential was Parallelisierung angeht, aber trotzdem gibt es auch Grenzen.

[edit]: Ich denke auch, dass die Zukunft vorerst in dem von Aquaschaf beschriebenen Ansatz liegen wird. Im Endeffekt nichts anderes als das was heute schon mit CPU + GPGPU betrieben wird. In welcher Hardware-Form ist natürlich noch eine andere Frage.

Botcruscher

2008-07-03, 18:26:39

Irgendwie sinnfrei bei Anwendungen die sich nicht so sehr zerstückeln lassen.

Imo erwartet uns der gleiche Werbemüll wie bei HT, DC und Quadcore. Zieht die Software keinen Gewinn muss der Anwender eben 10 Sachen gleichzeitig machen. Kann zwar keiner... aber die Balken stimmen.

PS: Oder anders:

Wir haben hier einen ganz tollen, neuen, teuren Prozessor. Macht mal...

Frucht-Tiger

2008-07-03, 18:47:30

Ich wäre eher für ein heterogenes Rechnermodell. Ein paar dicke Cores für vernünftige sequentielle Ausführungsgeschwindigkeit und dazu ein Haufen kleinerer für parallelisierbare Aufgaben. Hochparallele Ansätze sind zwar interessant - aber wozu das sequentielle Modell gleich ganz über Bord werfen?

Denke ich auch, anders wäre es ja nicht möglich im PC Markt, da könnte man ja 99% der existierenden Software in die Tonne hauen.

Ansonsten finde ich diesen ganzen Many-Core Kram relativ uninteressant, es will mir nicht wirklich einleuchten, was man mit hunderten Leistungsschwachen x86 Cores machen soll(PC Markt). Außerdem soll ja dann eh eine GPU mit in den Die, das sollte doch reichen um alles Kreuz und Quer zu encoden/decoden/packen was auch immer.

FlashBFE

2008-07-03, 19:01:35

Task != Thread
....
Und was willst du mir damit sagen?

In meinen Augen müsste man die gesamte klassische Rechnerarchitektur über Bord werfen, um da nennenswert weiterzukommen. Wie das aber konkret aussehen soll, entzieht sich komplett meiner Fantasie.
Es wäre schon erstmal sehr hilfreich, wenn sich die Entwicklungsumgebungen und Programmiersprachen noch mehr als jetzt an die veränderte Situation anpassen würden. Solange ich immernoch Handstände machen muss, um z.B. Threads mit Daten zu füttern und eine halbe Ewigkeit bei der Fehlerkorrektur zubringe, kann sich das starkparallele Prinzip nicht durchsetzen.

Ich glaube aber nicht, dass wir zu den tausenden Kernen kommen werden. Vorher wird eher der Transistor durch z.B. die "Crossbar Latch" abgelöst werden, was wieder einen guten Sprung in der seriellen Ausführung ermöglicht.

Monger

2008-07-03, 19:25:07

Nimm dir einfach ein Beispiel aus der Natur... es sitzt zwischen deinen 2 Ohren, da funktioniert das bisher prächtig.

Auch wenn der Vergleich immer wieder gezogen wird: das menschliche Gehirn hat mit einem Rechner nun wirklich gar nichts zu tun.

Jede Nervenzelle handelt selbstständig, jede Nervenzelle dient nicht nur als Rechner, sondern gleichzeitig als Speicher. Entscheidungen werden elektrisch übermittelt, aber biochemisch entschieden und gespeichert. Nervenzellen wachsen, und verdrahten sich ständig neu. Auch wenn sich sowas in neuronalen Netzen annähernd vernünftig emulieren lässt - effizient nachbilden lässt sich das nicht.

Im menschlichen Nervensystem (und das schließt das gesamte Nervengeflecht - von den Fingerspitzen über das Sonnengeflecht übers Rückenmark bis ins Hirn) werden an jeder einzelnen Stelle unabhängig vom Rest Entscheidungen getroffen, und das ganz ohne dass die Nervenzellen dazu vom Hirn dazu beordert werden müssten.

Deshalb meine ich ja: wenn wir unsere Rechnerarchitektur so dezentral organisieren wollten, müssten wir sie komplett übern Haufen werfen. Jede Soundkarte müsste sich bereits ausreichend selbst initialisieren können, sobald sie Saft bekommt. DAS wäre ein dezentraler Ansatz!

Es wäre schon erstmal sehr hilfreich, wenn sich die Entwicklungsumgebungen und Programmiersprachen noch mehr als jetzt an die veränderte Situation anpassen würden.
Klar wäre das wünschenswert. Aber ich sehe da nur geringe Chancen.
Gerade z.B. bei den grafischen Oberflächen hatte man in Java schon sehr weitreichende Parallelisierungen angestrebt - und ist dann Schritt für Schritt wieder zurückgerudert, weil es einfach so viele hässliche und unkontrollierbare Nebeneffekte gab.

Parallelität ist auch immer ein bißchen "fuzzy" - und dafür existiert immer noch kein gescheites Programmierkonzept.

Spasstiger

2008-07-03, 20:49:30

Ich bin auch nicht überzeugt davon, dass hochparallele Verarbeitung überhaupt funktionieren KANN. Der Computer ist nunmal eine äußerst zentralisierte Struktur: die CPU gibt den Takt an, und alle Rechnerkomponenten liefern der CPU nur zu. In meinen Augen müsste man die gesamte klassische Rechnerarchitektur über Bord werfen, um da nennenswert weiterzukommen. Wie das aber konkret aussehen soll, entzieht sich komplett meiner Fantasie.
Das Internet scheint extreme Parallelisierung zu erlauben, siehe diverse Distributed-Computing-Projekte. Die Delay-Zeiten sind zwar hoch, aber die Netto-Rechenleistung übertrifft jeden Superrechner.

Demirug

2008-07-03, 20:57:43

Das Internet scheint extreme Parallelisierung zu erlauben, siehe diverse Distributed-Computing-Projekte. Die Delay-Zeiten sind zwar hoch, aber die Netto-Rechenleistung übertrifft jeden Superrechner.

Die entsprechenden Aufgaben erlauben extreme Parallelisierung. Das hat nichts mit dem Internet zu tun.

Gast

2008-07-03, 20:59:49

Nimm dir einfach ein Beispiel aus der Natur... es sitzt zwischen deinen 2 Ohren, da funktioniert das bisher prächtig.

allerdings funktioniert es für die dinge, die typischerweise ein rechner macht alles andere als prächtig.

FlashBFE

2008-07-03, 21:16:06

Was Microsoft mit Chess (http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=1392&0sr=p) in der Konstruktion hat (siehe auch diese Präsentation (http://research.microsoft.com/projects/CHESS/chess.ppt)) klingt schonmal zumindest für die Fehlersuche vielversprechend. Ich hab nur das Gefühl, dass das alles viel zu lange braucht.

del_4901

2008-07-03, 21:23:45

allerdings funktioniert es für die dinge, die typischerweise ein rechner macht alles andere als prächtig.
Schonmal einen luziden Traum gehabt? Dann erst weißt du das Computerspiele firlefanz sind.

DavChrFen

2008-07-03, 21:43:31

IMHO könnte es ein Ausweg sein, das so ähnlich wie bei manchen Mainframes zu machen: Man hat Prozessoren (oder allgemein Recheneinheiten), die die eigentlichen Aufgaben machen und seperat welche, die nur für die Synchronisation und sonstigen Overhead zuständig sind.
Intel hat doch mit dem IA64-Konzept schon was gemacht, wo man mit weniger Aufwand einen parallelisierbaren Code schreiben kann. Vielleicht fließt von dort auch bischen Erfahrung mit ein.

[OT on] Netburst4Ever
[OT off]

Gast

2008-07-03, 22:02:04

Für welche (Home/Client-) Anwendung? Die Killerapplikation für den Bereich kommt nicht, sonst liefe die Software schon auf irgendwelchen Großrechnern.

(del)

2008-07-04, 01:12:01

Es wird immer so getan als wäre das der einzige limitierende Faktor...Also das waren schonmal 3 =) Für weiter "Vorschläge" auf der Suche nach Sündenböcken ist man natürlich dankbar. Ich meine direkt, gleich in einem Replay...

Coda

2008-07-04, 01:15:03

Du hast nicht verstanden was ich gemeint habe. Es wird immer Dinge geben die seriellen Code enthalten müssen. Da kann auch der beste Programmierer nichts daran ändern.

(del)

2008-07-04, 01:27:45

ESAD

2008-07-04, 01:46:57

Es muß ja nicht alles bis zum kleinsten Detail auf 100 Cores laufen. Ist schon ok.

Sonst bin ich ja deiner Meinung. Jemand aus der Szene sollte mal bei Intel anfragen, ob sie paar Tipps haben wie man sich auf die tausenden Cores nun vorbereiten soll ;)

ich weiß ja nicht ob du schonmal programmiert hast
aber multicore ist für standardanwendungen schon bei quadcore alles andere als einfach intelligent zu nützen

Epizentrum

2008-07-04, 02:17:17

"...developers should start thinking about tens, hundreds, and thousands of Megahurtz."

Fixed.

Ach ja, da sind wir wieder.

Gast

2008-07-04, 02:36:55

ich weiß ja nicht ob du schonmal programmiert hast
aber multicore ist für standardanwendungen schon bei quadcore alles andere als einfach intelligent zu nützenDas war auch nicht ironisch gemeint. Bzw. nicht in die Richtung die du eingeschlagen hast ;) Es ging Richtung Intel.

BH

Ectoplasma

2008-07-04, 08:25:19

Wichtig ist die Frage nach dem Bedarf. Welche Aufgabe soll von so vielen Cores profitieren? Und dann ist da noch die Frage, welche Aufgaben überhaupt parallelisierbar sind. Und das sind nicht so viele, wie uns unendliches Marketing-Geschwafel weiß machen will.

BlackBirdSR

2008-07-04, 17:05:12

uh wenn bei tausenden von Kernen einer auch nur eun verschwindend geringes halbes Watt benötigt...

da kommen noch ganz andere Herausforderungen auf uns zu, als genug Threads zu erzeugen.
Wer weiss, am Ende haben wir eine CPU mit genau 1000-Kernen, bei denen jeweils 250 Stück bestimmte Aufgabenbereiche abgrenzen. Mehr als ein viertel des Kerns darf niemals gleichzeitig aktiv sein um die thermischen Grenzen einzuhalten.
Nebenbei bräuchten die Signale von einem Teil des Kerns zu anderen eh zu lange....

icemanemp

2008-07-04, 19:47:59

Was passiert mit der ganzen ERP-Software die mit den dazu benötigten Datenbankmanagementsystemen immernoch den Massenmarkt in der Wirtschaft ausmachen?
Heutzutage sind da schon 16 Kerne für 20-30 User auf einem Citrix-Server mehr als genug. Die Daten kommen so oder so nicht schnell genug von der Datenbank. Massive Öffnung und Besorung von Daten über mehrere offene DB-Querys belasten den DB-Server ja auch extrem. Dann haben wir nicht nur Software Deadlocks durch gleichzeitige Ressourcenzugriffe, sondern auch noch das Problem der DB-Deadlocks...

Geht wohl dann alles wieder in Richtung Mainframe. 4 CPUs mit je 100 Kernen und die 120 Mitarbeiter mit Ihrer ERP-Software arbeiten alle auf einem Server... immer das gleiche Spiel.

P.S. Ich habe in ERP-Software bzw. DB angebundener Software kaum Anwendungsfälle gesehen die gut parallelisiert werden können... Ihr?

DavChrFen

2008-07-04, 19:58:15

Wenn wir hier schon wen aus der Proxis haben: d.h. die meisten der 120 Mitarbeiter arbeiten an den gleichen Tupeln, weil das nicht parallelisierbar ist, oder was? Ich hab in der Uni schon Vorlesungen über Datenbaken gehört und weiß deswegen nur was theoretisch dazu und habe noch keine Proxiserfahrung. Deswegen frage ich. Weil theorethisch dürfte das schon gut zu parallelisieren sein.

FlashBFE

2008-07-04, 21:31:36

dust

2008-07-04, 21:35:50

Gast

2008-07-04, 21:52:36

Die Abhängigkeiten.

Gast

2008-07-04, 21:56:06

Geht wohl dann alles wieder in Richtung Mainframe. 4 CPUs mit je 100 Kernen und die 120 Mitarbeiter mit Ihrer ERP-Software arbeiten alle auf einem Server... immer das gleiche Spiel.Da klatsch ich paar Sun T1000 mit 8 Kernen und 32 Threads :D und 180W pro Einschub und fertig ist die Sache. Für je 3700€.

16 Kerne für 30 User sind nicht nur mehr als genug sondern der Overkill schlechthin ;)

ESAD

2008-07-05, 22:31:47

Bei Datenbanken limitiert eigentlich nur Datenhaltung und -zugriff. Selbst wenn auf einem Server die komplette DB im RAM liegt, glaube ich kaum, dass das DBMS bei ->unendlich Zugriffen zuerst den Prozessor auslastet. Einzige Ausnahme sind gespeicherte Prozeduren und Aggregatabfragen, aber die sind meistens auch nur O(n).

und gerader dieser falschenhals des storage systems wird sich wohl durch flash schön weiten lassen ohne bis bisher storage systeme für den dopplten und dreifachen preis des servers anschaffen zu müssen

Gast

2008-07-07, 14:06:33

Zu Anfang des ganzen Mehrkernthemas gab es hier interessante Diagramme und grundsätzliche Überlegungen zur Sinnhaftigkeit des Ganzen. Da sah das eigentlich nicht so rosig für sehr viele Kerne aus. Mein Bauchgefühl sagt mir jedenfalls, dass das eine ähnliche Sackgasse wie Netburst ist. Bis zu einem gewissen Grad macht es Sinn und bietet Vorteile, aber bei 100 oder 1000 Cores glaub ich nicht mehr an irgendwelche Vorteile. Wöhlbemerkt alles nur auf grundsätzlichen theoretischen Gegebenheiten begründet. Wie man sowas noch ordentlich programmieren soll steht noch auf einem ganz anderen Blatt.

S940

2008-07-07, 17:06:31

Bis zu einem gewissen Grad macht es Sinn und bietet Vorteile, aber bei 100 oder 1000 Cores glaub ich nicht mehr an irgendwelche Vorteile. Jupp, ich zitiere mal den guten alten Amdahl, der fehlt hier im Thread eh noch:
http://upload.wikimedia.org/wikipedia/en/e/ea/AmdahlsLaw.svg
http://en.wikipedia.org/wiki/Amdahl%27s_law

Den ganzen Kern Tratra versteh ich deswegen nicht. Klar gibts ein große Gebiete der Forschung, die riesige Datenmengen auf 1000e von Kernen verteilen, nicht anders funktionieren heutzutage Supercomputer.

Aber ob das für den 0815 Windoof / Doom Nutzer sinnvoll ist ??

Natürlich laufen auch heutzutage schon ne Menge Tasks parallel / im Hintergrund, aber ab allerspätestens 10 Kernen seh ich keinen großen Gewinn mehr. Man kann einfach nicht alle Softwareprogramme in kleinere, parallele zerlegen.

ciao

Alex

dust

2008-07-07, 17:26:09

Jupp, ich zitiere mal den guten alten Amdahl, der fehlt hier im Thread eh noch:
http://upload.wikimedia.org/wikipedia/en/e/ea/AmdahlsLaw.svg
http://en.wikipedia.org/wiki/Amdahl%27s_law

Den ganzen Kern Tratra versteh ich deswegen nicht. Klar gibts ein große Gebiete der Forschung, die riesige Datenmengen auf 1000e von Kernen verteilen, nicht anders funktionieren heutzutage Supercomputer.

Aber ob das für den 0815 Windoof / Doom Nutzer sinnvoll ist ??
gerade für computerspiele ist es interessant, belebtere welten, jede person mehrere threads für unterschiedliche sachen. jede einzelne kugel ein eigener thread, finite elements für coole zerstörungen der umgebung, fluids berechnungen für zb. atmosphäre usw. unterschiedliche leveln von ki, philosopische, psychologische, soziale usw. und diese wesentlich komplexer.

Coda

2008-07-07, 17:43:04

dust, schonmal multithreading programmiert?

Vor allem "jede einzelne Kugel ein Thread" wäre absoluter Overkill egal wieviel Cores.

dust

2008-07-07, 18:04:55

dust, schonmal multithreading programmiert?

Vor allem "jede einzelne Kugel ein Thread" wäre absoluter Overkill egal wieviel Cores.
derzeit ist es nicht machbar, in zukunft mit tausenden cores wird es durchaus machbar sein. ich sehe es nicht als overkill...

Coda

2008-07-07, 18:07:57

Du weißt schon dass es verdammt teuer ist einen Thread zu erstellen und wieder sterben zu lassen?

So funktioniert das nicht. Man hat n Threads und muss darauf dann seine Arbeit verteilen. Und das möglichst ohne Synchronisierung. Was bei einem Thread pro "Objekt" verdammt viel wäre.

Aquaschaf

2008-07-07, 18:09:20

derzeit ist es nicht machbar, in zukunft mit tausenden cores wird es durchaus machbar sein. ich sehe es nicht als overkill...

Das ziemlich prinzipiell Unsinn weil dich die Kommunikation zwischen deinen endlos vielen Threads dann mehr kostet als du gewinnst. Mal abgesehen davon dass ich noch sehr stark bezweifle dass es jemals tausende general purpose cores auf einer CPU geben wird.

Gast

2008-07-07, 18:34:53

Habt ihr euch euer Wissen zum Thema Mikrotechnologie alle selbst angeeignet oder seid ihr hier alle Etechnik-Studenten?
Bin immer wieder verwundert, wieviel ihr teilweise wisst! *hands up* ;)
Gibt es gute Quellen, die es mir ermöglichen, mich in das Thema einzuarbeiten?

dust

2008-07-07, 19:02:26

wenn sie tausende cores in einen chip bauen so gehe ich davon aus, dass sie die threads auch mittels dezidierter hardware unterstützen. wenn nicht verwendest von den zigtausend cores ein paar hundert zur verwaltung. klar ist offen was das für cores sind und was die können und was nicht, ob das vektorcores, fpga oder was völlig anderes sein sollen.

wenn ein objekt ein oder mehrere threads sind bräuchtest du zwischen den objekten die interagieren und deren threads eine kommunikation aber sonst nicht. ändert sich am nachbarobjekt nichts brauchst auch nichts rechnen. ein hinkender vergleich, wo kein licht da kein schatten.

ich denke dabei in diese richtung
http://www.realityprime.com/articles/scenegraphs-past-present-and-future#tomorrow
http://de.wikipedia.org/wiki/Agentenbasierte_Modelle
http://de.wikipedia.org/wiki/Systemtheorie#Beispiele
http://de.wikipedia.org/wiki/Kybernetik

und nein das ist nicht fixfertig in einer schublade, rein als denkansatz gedacht wie man tausende cores verwenden könnte.

pest

2008-07-07, 19:33:25

So funktioniert das nicht. Man hat n Threads und muss darauf dann seine Arbeit verteilen. Und das möglichst ohne Synchronisierung. Was bei einem Thread pro "Objekt" verdammt viel wäre.

wer sagt das in Zukunft die Chips nicht untereinander kommunizieren
ohne das der Programmierer das erledigen muss. Wie Neuronen halt.

Coda

2008-07-07, 21:30:53

Es gibt sehr viel Forschung was Neuronale Netzwerke angeht und es gibt bisher nichtmal den Hauch der Hoffnung einer generellen Anwendbarkeit.

Kommunikation benötigt zudem auch immer Synchronisation weil man sonst gleichzeitig Daten überschreibt und ließt und das ist immer mit einem Overhead verbunden.

Gast

2008-07-07, 22:03:38

wer sagt das in Zukunft die Chips nicht untereinander kommunizieren
ohne das der Programmierer das erledigen muss. Wie Neuronen halt.
Tja, bis soweit ist und entsprechende Tools zur Verfügung stehen darf das Ding gerne bei Intel im Labor bleiben.

icemanemp

2008-07-08, 17:14:15

was soll an db nicht parallelisierbar sein? zb. eine tabelle in mehrere teile, jeder kern macht einen anderen teil. bei den abfragen muss man schauen was sich parallelisieren lässt und was nur sequentiell ablaufen kann.
Wer redt hier von DBMS Multithreading. ich rede hier von Anwendungs Multithreating, welche DBMS als Datenlieferanten benutzt.
Auf eine Datenbank muss man immer warte. Selbst schnellere Subsystem um die CPU machen das Netzwerk nicht schneller!
In unserer warenwirtschaftssoftware ist z.B. der Hauptanteil am Wirtschaftsbereich die Belegverarbeitung. Hier ist es extrem schwierig... Alles COM-Objekte. Tabellenzugriffe gecached. Mehrere 100.000 Zeilen Logikcode. Vom COM-Schichtcode mal abgesehen. Was für ein Aufwand, wenn z.B. ein Anwendungsserver durch Citrix mehrere Benutzer zulässt und diese die CPU-Kerne mit einzelnen Prozessen unserer Anwendung genug auslastet...

Aber ich denke bei SAP ist das auch nicht anders, aber die können ja ihre Physiker/Mathematiker auf ihre SAP-Grundschicht loslassen und die richten das dann... je nach abstaktionsebene (bei SAP sollte das gut geregelt sein) könnte man sowas eben auf verschiedenen Ebenen implementieren.

Aber der Aufwand steht wahrscheinlich in keinem Verhältnis in dieser Branche!

Buzzler

2008-07-08, 17:59:26

Tja, bis soweit ist und entsprechende Tools zur Verfügung stehen darf das Ding gerne bei Intel im Labor bleiben.
Und Du meinst echt, dass sowas schon bei Intel im Labor zu finden ist? Nicht vielleicht doch eher in den feuchten Träumen der Intel-Entwickler oder gar -Execs?

dust

2008-07-08, 18:51:51

Wer redt hier von DBMS Multithreading. ich rede hier von Anwendungs Multithreating, welche DBMS als Datenlieferanten benutzt.
Auf eine Datenbank muss man immer warte. Selbst schnellere Subsystem um die CPU machen das Netzwerk nicht schneller!
In unserer warenwirtschaftssoftware ist z.B. der Hauptanteil am Wirtschaftsbereich die Belegverarbeitung. Hier ist es extrem schwierig... Alles COM-Objekte. Tabellenzugriffe gecached. Mehrere 100.000 Zeilen Logikcode. Vom COM-Schichtcode mal abgesehen. Was für ein Aufwand, wenn z.B. ein Anwendungsserver durch Citrix mehrere Benutzer zulässt und diese die CPU-Kerne mit einzelnen Prozessen unserer Anwendung genug auslastet...

Aber ich denke bei SAP ist das auch nicht anders, aber die können ja ihre Physiker/Mathematiker auf ihre SAP-Grundschicht loslassen und die richten das dann... je nach abstaktionsebene (bei SAP sollte das gut geregelt sein) könnte man sowas eben auf verschiedenen Ebenen implementieren.

Aber der Aufwand steht wahrscheinlich in keinem Verhältnis in dieser Branche!

also eine typische microsoft geschichte... hrhrhrhrrrrrrrrrrr, damit habe ich überhaupt kein mitleid sondern im gegenteil, hämische schadenfreude. ;D :P

Und Du meinst echt, dass sowas schon bei Intel im Labor zu finden ist? Nicht vielleicht doch eher in den feuchten Träumen der Intel-Entwickler oder gar -Execs?
http://www.intel.com/technology/itj/2007/v11i3/4-environment/1-abstract.htm

http://techresearch.intel.com/articles/Tera-Scale/1421.htm

das sind nicht nur laborgeschichten

Buzzler

2008-07-08, 19:53:58

http://www.intel.com/technology/itj/2007/v11i3/4-environment/1-abstract.htm

http://techresearch.intel.com/articles/Tera-Scale/1421.htm

das sind nicht nur laborgeschichten
Ich hab das jetzt nur diagonal gelesen, aber gleich auf der ersten Seite steht: "We also present simulation results from a tera-scale simulator to show that McRT enables excellent scalability on tera-scale platforms."

Für mich heißt das, dass eben keine entsprechenden Prototypen existieren. Mit gutem Willen könnte man die Rechner bzw. Büros, in denen die stehen, auf denen die Simulationen laufen, als Labor bezeichnen, dann wären es tatsächlich Laborgeschichten...

Ansonsten ist der Tenor für mich eindeutig: Wir verlagern die Probleme auf die Softwareseite, spülen die Perfomance bisheriger Softwarekonzepte und schwer parallelisierbarer Algorithmen mit einem lockerleichten Achselzucken die Toilette runter und dafür haben wir als Hardware-Hersteller dann eine supertoll skalierende Architektur und nur noch Probleme, dass ganze in Silizium zu backen, was wir aber bisher auch schon hatten und supertoll können und damit fein raus sind. Aber vielleicht bin auch nur zynisch...

icemanemp

2008-07-08, 22:31:42

also eine typische microsoft geschichte... hrhrhrhrrrrrrrrrrr, damit habe ich überhaupt kein mitleid sondern im gegenteil, hämische schadenfreude. ;D :P
Ist das ein Insider oder muss ich das verstehen?
Was ist so schlecht an einer typischen Microsoftgeschichte?

P.S. Genauer definieren bzw. quoten auf was du eingehen willst...

dust

2008-07-09, 01:25:11

Ich hab das jetzt nur diagonal gelesen, aber gleich auf der ersten Seite steht: "We also present simulation results from a tera-scale simulator to show that McRT enables excellent scalability on tera-scale platforms."

Für mich heißt das, dass eben keine entsprechenden Prototypen existieren. Mit gutem Willen könnte man die Rechner bzw. Büros, in denen die stehen, auf denen die Simulationen laufen, als Labor bezeichnen, dann wären es tatsächlich Laborgeschichten...

http://softwarecommunity.intel.com/articles/eng/1460.htm
Intel® C++ STM Compiler, Prototype Edition 2.0
Product Overview
Parallel programming has traditionally been considered using locks to synchronize concurrent access to shared data. Lock-based synchronization, however, has known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory is proposed to simplify parallel programming by supporting “atomic” and “isolated” execution of user-specified tasks. It provides an alternate concurrency control mechanism that avoids these pitfalls and eases parallel programming. The Transactional Memory C++ language constructs that are included open the door for users to exercise the new language constructs for parallel programming, understand the transaction memory programming model, and provide feedback on the usefulness of these extensions with Intel® C++ STM Compiler Prototype Edition. This posting includes the Intel® C++ STM Compiler Prototype Edition 2.0 and runtime libraries for Intel transactional memory language construct extensions.
also kannst du schon selbst testen und deine programme ausprobieren.

Ansonsten ist der Tenor für mich eindeutig: Wir verlagern die Probleme auf die Softwareseite, spülen die Perfomance bisheriger Softwarekonzepte und schwer parallelisierbarer Algorithmen mit einem lockerleichten Achselzucken die Toilette runter und dafür haben wir als Hardware-Hersteller dann eine supertoll skalierende Architektur und nur noch Probleme, dass ganze in Silizium zu backen, was wir aber bisher auch schon hatten und supertoll können und damit fein raus sind. Aber vielleicht bin auch nur zynisch...
die taktfrequenzen sind nicht beliebig steigerbar. bleibt also nur mehr sachen parallel auszuführen. jeder hat in seinem rechner parallel laufende verarbeitungseinheiten, zb. cpu und gpu. wäre die cpu schnell genug bräuchten wir keinen spezialprozessor wie die gpu sondern würden alles in software rendern. software und hardware müssen zusammenspielen wenn man das meiste rausholen will, war immer so, ist so und wird immer so sein.

http://softwarecommunity.intel.com/communities/multicore
http://softwarecommunity.intel.com/articles/eng/1567.htm
Technical Books for Multi-Core Software Developers

keine ahnung was amd plant, vermute die gehen ebenfalls in eine ähnliche richtung.

generel gesehen ist eine parallele ausführung nichts neues, mangels dementsprechender cpu war es in der vergangenheit kaum thema bei standard desktop anwendundungen. für viele sachen im technischen oder wissenschaftlichen bereich ist parallelisierung schon länger thema.

Coda

2008-07-09, 01:58:09

Das sind auch alles nur kleine Pflaster, aber ganz sicher keine Wundermittel gegen die Probleme was du da aufführst.

dust

2008-07-09, 02:40:34

Das sind auch alles nur kleine Pflaster, aber ganz sicher keine Wundermittel gegen die Probleme was du da aufführst.
es wird auch keine wundermittel geben, das denken wird den entwicklern nicht abgenommen.

Coda

2008-07-09, 02:46:18

Es hilft in vielen Fällen auch Denken nicht weiter, weil das Problem einfach inhärent nicht parallelisierbar ist.

dust

2008-07-09, 02:50:48

Es hilft in vielen Fällen auch Denken nicht weiter, weil das Problem einfach inhärent nicht parallelisierbar ist.
von nicht parallelisierbaren sachen redet sowieso keiner sondern von den vielen sachen die es sind.

del_4901

2008-07-09, 02:53:47

von nicht parallelisierbaren sachen redet sowieso keiner sondern von den vielen sachen die es sind.
Noch hast du dafür kein praktisches Beispiel genannt.

dust

2008-07-09, 03:02:25

Noch hast du dafür kein praktisches Beispiel genannt.
doch weiter vorne, gerade für computerspiele ist es interessant, belebtere welten, jede person mehrere threads für unterschiedliche sachen. jede einzelne kugel ein eigener thread, finite elements für coole zerstörungen der umgebung, fluids berechnungen für zb. atmosphäre usw. unterschiedliche leveln von ki, philosopische, psychologische, soziale usw. und diese wesentlich komplexer.

Coda

2008-07-09, 03:50:52

Ganon

2008-07-09, 08:16:41

Fluids ist da eine Sache die wirklich fast 100% skaliert.

Wobei man dafür ja auch mittlerweile lieber eine GPU nimmt, als eine CPU. Zumindest das was die alles mit CUDA anstellen, kommt schon sehr nahe an Realismus und das in Echtzeit. Da braucht man nicht auf eine 3000Core CPU warten.

icemanemp

2008-07-09, 08:23:22

das hört sich für mich sehr typisch nach microsoft an, höhere anforderungen und es wird mühsam.
Naja, ich hab damit keine Probleme. Aber wenn du selbst in der Wirtschaft arbeiten würdest und z.B. Warenwirtschaftssoftware entwickelst bzw. andere stark DB-abhängige Software, dann würdest du sehen, das es keinen Bedarf an Multhithreading gibt... Machbar ist alles, aber riesiger Aufwand, da die Software vor allem durch ihre Grundschicht und ihre Logikschicht lebt. Ein Umstellung der jeweiligen Schicht ist ein Aufwand, den man nicht verkaufen kann! Denkst du Bitburger oder Radeberger interessieren sich für Multhithread-optimierte Warenwirtschaftssoftware. Denen geht es um ganz andere Sachen!

Radeonator

2008-07-09, 09:29:34

Wieso Träume aus 1001 Nacht?

http://www.tecchannel.de/index.cfm?pid=212&pk=467580

Zudem gibt es in anderen Bereichen schon länger many-core CPUs

Ganon

2008-07-09, 09:37:24

Zudem gibt es in anderen Bereichen schon länger many-core CPUs

Äh, hier geht es aber, wie du im Thread-Titel liest um 'thousands of cores', nicht um 80 ;)

Gast

2008-07-09, 10:00:18

Nimm dir einfach ein Beispiel aus der Natur... es sitzt zwischen deinen 2 Ohren, da funktioniert das bisher prächtig.

Wäre mir neu, dass man wirklich parallel denken kann. Man kann sicherlich einige Dinge gleichzeitig machen (z.B. reden und schreiben), aber parallel denken kannst du garantiert nicht.

Ganon

2008-07-09, 10:03:26

Wäre mir neu, dass man wirklich parallel denken kann. Man kann sicherlich einige Dinge gleichzeitig machen (z.B. reden und schreiben), aber parallel denken kannst du garantiert nicht.

Du weißt aber schon, wie viel das Gehirn auf ein mal macht, oder? Oder bist du blind, während du redest. Oder stumm wenn du hörst? ;)

Nein, alles machst du gleichzeitig und alles kannst du auch sehr gut zuordnen und das gleichzeitig. Wenn ein Stein auf dich zufliegt, kannst du ihm auch ausweichen, ohne das du erst darüber nachdenken musst ;)

Gast

2008-07-09, 10:09:52

Du weißt aber schon, wie viel das Gehirn auf ein mal macht, oder? Oder bist du blind, während du redest. Oder stumm wenn du hörst? ;)

Ja klar, in der Beziehung hast du Recht. Aber ich Rede von komplexen Denkvorgängen, die du selbst initiierst. Du kannst z.B. nicht irgend etwas parallel im Kopf rechnen. Du kannst es höchstens sehr schnell hintereinander rechnen. Klar macht dein Hirn noch andere Aufgaben, aber das passt meiner Meinung nach nicht zum Vergleich.

Ganon

2008-07-09, 10:21:06

Auch das Gehirn hat eben Grenzen. Nicht umsonst können blinde Menschen einen ihrer anderen Sinne sehr viel besser nutzen. Ein sehr belastender Teil fällt halt weg.

Gucke dir mal Autisten an. Die rechnen teils Sachen im Kopf, wo selbst ein Computer schlapp macht. Dort fehlt eben auch ein großer Teil der anderen Sinne. Zumindest "effektiv".

dust

2008-07-09, 10:38:06

Naja, ich hab damit keine Probleme. Aber wenn du selbst in der Wirtschaft arbeiten würdest und z.B. Warenwirtschaftssoftware entwickelst bzw. andere stark DB-abhängige Software, dann würdest du sehen, das es keinen Bedarf an Multhithreading gibt... Machbar ist alles, aber riesiger Aufwand, da die Software vor allem durch ihre Grundschicht und ihre Logikschicht lebt. Ein Umstellung der jeweiligen Schicht ist ein Aufwand, den man nicht verkaufen kann! Denkst du Bitburger oder Radeberger interessieren sich für Multhithread-optimierte Warenwirtschaftssoftware. Denen geht es um ganz andere Sachen!
es gibt durchaus den bedarf zu clustern wenn es grösser wird, da reicht ein einzelner prozessor nicht mehr. zuerst die db und die wawi auf eigene server und wenn das nicht reicht parallelisieren.

manche firmen verwenden auch oft sehr alten und bewährten code, cobol, rpg usw. seit as400, mvs, usw. tagen. auch ibm packt seit einiger zeit mehrere prozessoren in gehäusemodule und schaut, dass die alte software auf neuer hardware auch schneller rennt, weil sie sonst eben keine neuen z/os usw. systeme verkaufen könnten.

Monger

2008-07-09, 11:14:22

Ja klar, in der Beziehung hast du Recht. Aber ich Rede von komplexen Denkvorgängen, die du selbst initiierst. Du kannst z.B. nicht irgend etwas parallel im Kopf rechnen. Du kannst es höchstens sehr schnell hintereinander rechnen. Klar macht dein Hirn noch andere Aufgaben, aber das passt meiner Meinung nach nicht zum Vergleich.

Du "initiierst" selbst keine Denkvorgänge. Dein Hirn wälzt ständig alle möglichen Gedanken um, allerdings dringt nur der vorherrschende Gedanke dann bis ins Bewusstsein vor. In Wahrheit herrscht in deinem Kopf ein babylonisches Stimmengewirr - davon kriegen die meisten Menschen allerdings zum Glück nichts mit! ;)

Das Hirn ist eine unglaublich hochparallelisierte Struktur.

dust

2008-07-09, 11:17:08

Sobald du Interaktion hast ist auch KI dadurch begrenzt dass du Synchronisation brauchst wenn miteinander "geredet" werden soll.

Fluids ist da eine Sache die wirklich fast 100% skaliert. Bei Physik bin ich mir da schon nicht mehr so sicher.
fluids sind abhängige systeme, ein luftmolekül stösst an ein anderes. wie beim billard eine kugel an eine andere, mittels kraftvektoren zu berechnen. festkörper berechnet man ebenfalls mittels kraftvektoren siehe finite elements. du hast also immer einen aufwand für datenabgleich mit nachbarelementen.

auch im ki bereich lässt sich viel parallelisieren, weil in einem menschen vieles parallel abläuft und wir vieles parallel machen, sei es bewusst oder unbewusst.

dust

2008-07-09, 12:39:20

http://www.heise.de/newsticker/DreamWorks-Animation-wechselt-von-AMD-zu-Intel--/meldung/110652

Die DreamWorks-Animateure hatten seit 2005 AMDs Opteron-Prozessoren mit zwei Kernen verwendet, nun sollen Prozessoren der kommenden Nehalem-Generation (mit bis zu acht Cores/16 Threads) sowie Larrabee-Chips (zwischen 10 und 100 Cores) eingesetzt werden. "Wir waren mit AMD bislang zufrieden, aber in Bezug auf die Core-Zahl deckt sich die Intel-Roadmap eher mit unseren Bedürfnissen", wird der Vizechef der Dreamworks-Produktionsabteilung, John Batter, von AP zitiert.

Die zusätzliche Rechenkraft wird dringend gebraucht: Momentan dauere das Rendern eines einzigen Bildes bis zu 16 Stunden, so ein Unternehmenssprecher. Rund 1000 Workstations und 1500 Server verrichten ihren Dienst bei DreamWorks, sie sollen in den nächsten 18 Monaten auf Intel-Technik umgerüstet werden. Ein Team von Intel-Programmierern soll zudem die proprietäre DreamWorks-Rendersoftware auf die neue Architektur optimieren. Der große Traum der Animateure, das Arbeiten in Echtzeit, liegt allerdings noch immer in weiter Ferne.

wird also noch lange dauern bis wir computerspiele in kinoqualität haben.

Marodeur

2008-07-09, 12:52:32

Parallelisierung, Spezialisierung, unabhängige Kerne. Hm, warum muss ich grad an meinen alten Amiga denken? Wäre sowas in der Richtung vielleicht wieder denkbar? Statt eigenständiger Co-Prozessoren zur Entlastung eben viele Kerne welche die ganzen Aufgaben übernehmen, möglichst noch variabel? Vielleicht träum ich auch nur, kam mir halt beim lesen hier grad wieder in den Sinn. ;)

Coda

2008-07-09, 14:34:02

fluids sind abhängige systeme, ein luftmolekül stösst an ein anderes.
Es wird dort niemand Anfangen einzelne Moleküle zu berechnen. Jegliche Fluid-Dynamic-Simulation die ich kenne rechnet zu jedem Punkt ohne Abhängigkeiten. Und das ist auch kein Problem.

Wenn du nichts von dem Thema vestehst dann tu nicht so. Es nervt.

wird also noch lange dauern bis wir computerspiele in kinoqualität haben.
Grafik ist parallelisierbar. Shocking News! :eek:

dust

2008-07-09, 15:07:08

Es wird dort niemand Anfangen einzelne Moleküle zu berechnen. Jegliche Fluid-Dynamic-Simulation die ich kenne rechnet zu jedem Punkt ohne Abhängigkeiten. Und das ist auch kein Problem.

Wenn du nichts von dem Thema vestehst dann tu nicht so. Es nervt.

es gibt mehrere arten zu rechnen http://www.cfd-online.com/Wiki/Numerical_methods

du hast selbstverständlich abhängigkeiten, sonst gäbe es zb. keine schallausbreitung. :P

Grafik ist parallelisierbar. Shocking News! :eek:

na echt? was hast in deinem rechner stecken wennst deine spiele in kinoqualität hast, wenn ein bild in einem filmstudio stunden braucht und sie derzeit selbst mit vielen dicken prozessoren kein echtzeit schaffen? :eek:

Coda

2008-07-09, 15:22:56

es gibt mehrere arten zu rechnen http://www.cfd-online.com/Wiki/Numerical_methods

du hast selbstverständlich abhängigkeiten, sonst gäbe es zb. keine schallausbreitung. :P
Es wird aber nicht so gerechnet. Es wird zu jedem Punkt Vektoren gesetzt die die Ausbreitungsgeschwindigkeit von Zeitpunkt t beschreiben. Von diesen Daten wird dann an jedem Punkt ohne Abhängigkeiten t+1 berechnet.

Ich verstehe sehr genau von was ich rede. Du offensichtlich nicht. Und mit Google-Sucherergebnissen um dich schmeißen die du nicht mal gelesen geschweige denn verstanden hast kannst du auch bleiben lassen.

na echt? was hast in deinem rechner stecken wennst deine spiele in kinoqualität hast, wenn ein bild in einem filmstudio stunden braucht und sie derzeit selbst mit vielen dicken prozessoren kein echtzeit schaffen? :eek:
Was hat das damit zu tun? GPUs berechnen ein Bild trotzdem seit jeher hoch parallel. Das ist aber absolut überhaupt nichts neues.

Da wird durch tausend x86-Cores auch nicht irgendwie auf einmal ein "Wunder" passieren. Wir haben diese hochparallelen Grafikprozessoren schon Ewigkeiten. Eine GeForce GTX 280 arbeiten auf einmal mit 10000 Threads auf 30 Prozessoreinheiten.

del_4901

2008-07-09, 15:23:53

Du "initiierst" selbst keine Denkvorgänge. Dein Hirn wälzt ständig alle möglichen Gedanken um, allerdings dringt nur der vorherrschende Gedanke dann bis ins Bewusstsein vor. In Wahrheit herrscht in deinem Kopf ein babylonisches Stimmengewirr - davon kriegen die meisten Menschen allerdings zum Glück nichts mit! ;)

Das Hirn ist eine unglaublich hochparallelisierte Struktur.

Danke das du das so eloquent ausgedrueckt hast, so muss ich es nicht tun.

Gast

2008-07-09, 15:36:11

Du "initiierst" selbst keine Denkvorgänge.[QUOTE]

Na klar kann ich sie selbst initiieren. Was dabei auf Hirnebene stattfindet, spielt gar keine Rolle. Aber kannst du wirklich gleichzeitig zwei Aufgaben parallel im Kopf rechnen? Man kann sich höchsten soweit trainieren, dass man entweder sehr schnell hintereinander rechnet oder die Aufgaben effizient aufteilt.

[QUOTE]
Das Hirn ist eine unglaublich hochparallelisierte Struktur.

Das will niemand abstreiten. Es ist ja aber nicht Gegenstand der Diskussion, was mein Hirn alles so macht, damit mein physischer Körper funktioniert, sondern wie eine spezifische Aufgabe parallelisiert werden kann.

Gast

2008-07-09, 15:43:56

wird also noch lange dauern bis wir computerspiele in kinoqualität haben.Eigentlich haben wir fast nur Spiele in Kinoqualität: Blockbuster, Materialschlachten ohne Ende um von der fehlenden Tiefe abzulenken.
Ich will Spiele in Serienqualität, die sich (sowohl im Gameplay als auch in der Entwicklung) genug Zeit lassen um dem Spieler ein in sich stimmiges Gesamtbild zu bieten, welches er durch die selbstgewählte Perspektive erfährt. Wenn darunter die Präsentation leidet ists mir herzlich schnurzegal, B5 wischt schließlich immer noch mit fast allen anderen SciFi-Serien den Boden auf, obwohl die CGIs schon lange selbst im Vergleich zu primitiver Spielegrafik grottenschlecht aussehen.

Allerdings:
Serienqualität, nicht Serienformat! Episoden, die (falls überhaupt) alle paar Monate nachgeliefert werden zerstören jegliche Spannung.

Coda

2008-07-09, 15:44:13

Na klar kann ich sie selbst initiieren. Was dabei auf Hirnebene stattfindet, spielt gar keine Rolle. Aber kannst du wirklich gleichzeitig zwei Aufgaben parallel im Kopf rechnen? Man kann sich höchsten soweit trainieren, dass man entweder sehr schnell hintereinander rechnet oder die Aufgaben effizient aufteilt.

Das will niemand abstreiten. Es ist ja aber nicht Gegenstand der Diskussion, was mein Hirn alles so macht, damit mein physischer Körper funktioniert, sondern wie eine spezifische Aufgabe parallelisiert werden kann.
Ich weiß nicht aber irgendwie würde ich dem Gast auch teilweise recht geben. Eine Divisionseinheit in der CPU ist auch eine "hochparallele Struktur", aber ist nach außen halt nur als Divisionseinheit verwendbar.

Genauso gibt es ja im Gehirn z.B. "Einheiten" für Gesichtserkennung. Die sind aber auch nicht generell verwendbar. Natürlich kann man z.B. gleichzeitig Autofahren und reden, aber irgendwie hat die Natur da auch die gleichen Probleme gehabt wie wir jetzt. Was nicht parallel machbar ist geht auch nicht parallel.

dein Freund, der Gast

2008-07-09, 15:50:33

Grafik ist parallelisierbar. Shocking News! :eek:
und???

Die werden bisher bei DreamWorks wohl kaum die Grafiken mit Einzelplatzrechnern berechnet haben

Coda

2008-07-09, 15:53:50

Ich hab weiter oben schon darauf geantwortet. Das ist absolut nicht relevant.

dust

2008-07-09, 15:59:50

Es wird aber nicht so gerechnet. Es wird zu jedem Punkt Vektoren gesetzt die die Ausbreitungsgeschwindigkeit von Zeitpunkt t beschreiben. Von diesen Daten wird dann an jedem Punkt ohne Abhängigkeiten t+1 berechnet.

Ich verstehe sehr genau von was ich rede. Du offensichtlich nicht.

Fluids ist da eine Sache die wirklich fast 100% skaliert. Bei Physik bin ich mir da schon nicht mehr so sicher.

fluids sind abhängige systeme, ein luftmolekül stösst an ein anderes. wie beim billard eine kugel an eine andere, mittels kraftvektoren zu berechnen. festkörper berechnet man ebenfalls mittels kraftvektoren siehe finite elements. du hast also immer einen aufwand für datenabgleich mit nachbarelementen.

diese vektoren beeinflussen sich gegenseitig, diese rechnen wir natürlich t zu t+1. würden sich die vektoren nicht gegenseitig beeinflussen gäbe es nichts zu rechnen da sich nichts ändern würde.

Was hat das damit zu tun? GPUs berechnen ein Bild trotzdem seit jeher hoch parallel. Das ist aber absolut überhaupt nichts neues.

Da wird durch tausend x86-Cores auch nicht irgendwie auf einmal ein "Wunder" passieren. Wir haben diese hochparallelen Grafikprozessoren schon Ewigkeiten. Eine GeForce GTX 280 arbeiten auf einmal mit 10000 Threads auf 30 Prozessoreinheiten.

http://www.heise.de/newsticker/DreamWorks-Animation-wechselt-von-AMD-zu-Intel--/meldung/110652
Die zusätzliche Rechenkraft wird dringend gebraucht: Momentan dauere das Rendern eines einzigen Bildes bis zu 16 Stunden, so ein Unternehmenssprecher. Rund 1000 Workstations und 1500 Server verrichten ihren Dienst bei DreamWorks... Der große Traum der Animateure, das Arbeiten in Echtzeit, liegt allerdings noch immer in weiter Ferne.
wird also noch lange dauern bis wir computerspiele in kinoqualität haben.

dust

2008-07-09, 16:02:03

Eigentlich haben wir fast nur Spiele in Kinoqualität: Blockbuster, Materialschlachten ohne Ende um von der fehlenden Tiefe abzulenken.
Ich will Spiele in Serienqualität, die sich (sowohl im Gameplay als auch in der Entwicklung) genug Zeit lassen um dem Spieler ein in sich stimmiges Gesamtbild zu bieten, welches er durch die selbstgewählte Perspektive erfährt. Wenn darunter die Präsentation leidet ists mir herzlich schnurzegal, B5 wischt schließlich immer noch mit fast allen anderen SciFi-Serien den Boden auf, obwohl die CGIs schon lange selbst im Vergleich zu primitiver Spielegrafik grottenschlecht aussehen.

Allerdings:
Serienqualität, nicht Serienformat! Episoden, die (falls überhaupt) alle paar Monate nachgeliefert werden zerstören jegliche Spannung.
:up: bin ich voll bei dir...

Coda

2008-07-09, 16:04:21

diese vektoren beeinflussen sich gegenseitig, diese rechnen wir natürlich t zu t+1. würden sich die vektoren nicht gegenseitig beeinflussen gäbe es nichts zu rechnen da sich nichts ändern würde.
Nein tun sie nicht. Es wird eine Anfangsgeschwindigkeit angelegt an jeden Punkt und darauf basierend weitergerechnet. Es gibt etliche Streamprocessing-Fluid-Dynamic-Demos für Direct3D, CUDA usw. und da sind ganz sicher keine Abhängikeiten vorhanden.

Man rechnet vorher die Gradienten aus, d.h. man kann alles vollständig ohne Synchronisation rechnen.

http://www.heise.de/newsticker/DreamWorks-Animation-wechselt-von-AMD-zu-Intel--/meldung/110652
Und jetzt?

Das Grafik auch auf tausende Cores skaliert ist nichts neues. Das ist einfach ein alter Hut den man ganz sicher nicht groß aufbauschen muss. Liest du überhaupt was ich schreibe?

dust

2008-07-09, 16:25:23

Nein tun sie nicht. Es wird eine Anfangsgeschwindigkeit angelegt an jeden Punkt und darauf basierend weitergerechnet. Es gibt etliche Streamprocessing-Fluid-Dynamic-Demos für Direct3D, CUDA usw. und da sind ganz sicher keine Abhängikeiten vorhanden.

wenn ein auto 100km/h fährt fliesst die luft sehr dicht in einem mikroskopischen abstand an der karosserie vorbei und in 10cm abstand spürt man keinen windhauch? interessante welt in der du lebst, erzähl mehr.

Und jetzt?

Das Grafik auch auf tausende Cores skaliert ist nichts neues. Das ist einfach ein alter Hut den man ganz sicher nicht groß aufbauschen muss. Liest du überhaupt was ich schreibe?
Der große Traum der Animateure, das Arbeiten in Echtzeit, liegt allerdings noch immer in weiter Ferne.
wird also noch lange dauern bis wir computerspiele in kinoqualität haben.
Grafik ist parallelisierbar. Shocking News!

wix dir einen und lies es entspannt nochmals...

Coda

2008-07-09, 16:30:52

wenn ein auto 100km/h fährt fliesst die luft sehr dicht in einem mikroskopischen abstand an der karosserie vorbei und in 10cm abstand spürt man keinen windhauch? interessante welt in der du lebst, erzähl mehr.
Gradient berechnen. Danach weiterrechnen. Es geht ohne Synchronisation und Abhängigkeiten in den Rechenschritten. Fluid Dynamics skalieren 100%. Da brauch ich nicht in einer "interessanten" Welt zu leben weil ich das sicher weiß.

wix dir einen und lies es entspannt nochmals...
Geht das auch ohne Beleidigungen? Ich verstehe immer noch nicht was das mit dem Thema zu tun haben soll. Dass durch Multicores schnelleres Offline-Rendering möglich sein wird ist doch wohl logisch.

Was ist überhaupt dein Standpunkt? Dass ich falsch liege damit dass in vielen Fällen so viele Cores nichts bringen? Bisher ist mir das nicht ganz klar geworden. Falls dem so ist. Du liegst falsch :tongue:

Ganon

2008-07-09, 19:07:29

Hier eine "Blut-Simulation" auf CUDA.

http://youtube.com/watch?v=D4FY75GwA00

Das würde nicht flüssig laufen, wenn man es nicht parallel machen könnte ;)

ESAD

2008-07-09, 20:51:58

und wer sagt dir das es in echtzeit ist?

Legolas

2008-07-09, 20:54:40

und wer sagt dir das es in echtzeit ist?
Drück' mal auf "more info".

Ganon

2008-07-09, 21:05:35

und wer sagt dir das es in echtzeit ist?

Und hier noch mal der Auszug aus "More Info":

Typically it takes several minutes or hours to generate each frame of animation, but by making some minor compromises in visual quality and taking advantage of the GPU's parallelism and bandwidth the solver is fast enough for real-time applications (e.g., around 120-180 frames per second at 64x64x128 on a GeForce 8800 GTX).

Buzzler

2008-07-09, 21:27:48

http://softwarecommunity.intel.com/articles/eng/1460.htm
Intel® C++ STM Compiler, Prototype Edition 2.0
Ich lese da, dass damit locks automagisch nur noch in den Fällen zuschnappen, in den sonst Kollisionen auftreten würden und diese auch nur auf die betroffenen Speicherbereiche angewandt werden. Interessant (wenn das mit dem automagisch wirklich klappt) aber was hat das mit dem Thema zu tun? Ist mein englisch zu schlecht oder hab ich die Stelle überlesen, wo beschrieben wird, dass man Amdahl's Law abgeschafft hat und Parallelisierung voll kein Thema mehr ist?

die taktfrequenzen sind nicht beliebig steigerbar. bleibt also nur mehr sachen parallel auszuführen.
Weil parallelisiert werden muss, ist Parallelisierung auch folgerichtig quasi grenzenlos möglich, das ist so ungefähr Deine Argumentation?

Zu Deinem anderen Post: Ist ja schön und gut, jede Kugel 100% korrekt zu berechnen und die theoretisch extrem hohe Rechenleistung einer many-core-CPU mit Sachen auszunutzen, die einer solchen CPU liegen, aber das ändert doch am grundlegenden Problem, mal überhaupt gar nichts. Einfach jede Menge "embarassingly parallel" code zu erzeugen, der logischerweise nahezu perfekt skaliert, ist doch im Grunde völlig witzlos?!

Wieso Träume aus 1001 Nacht?

http://www.tecchannel.de/index.cfm?pid=212&pk=467580

Zudem gibt es in anderen Bereichen schon länger many-core CPUs
Also immerhin doch eine echte Laborgeschichte. Dass das für die Zielgruppe dieses Forums wirklich relevant ist, glaube ich wenn ein Spiel drauf läuft. ;)

mekakic

2008-07-10, 08:24:25

Hier eine "Blut-Simulation" auf CUDA.

http://youtube.com/watch?v=D4FY75GwA00

Das würde nicht flüssig laufen, wenn man es nicht parallel machen könnte ;) Wird die Berechnung für sowas gleichzeitig zwischen Grafik und Cuda verteilt? D.h. hat der Treiber eine Art Scheduler, der die Last zwischen GP und Grafik Anforderungen auf einer Karte aufteilt? Oder kann man in Cuda auch gleich irgendwie rendern? Oder brauch man für beides eine eigene Karte? Ersters würde mir am besten gefallen... :)

MadMax@

2008-07-10, 10:16:41

Es komt darauf an wie man die Fluids berechnet wen man nur die einfache Wellengleichung diskretisiert und ein explizietes verfahren wählt berechnet man den Wert zum Zeitpunkt t+1 wirklich nur an Hand der werte zum Zeitpunkt t.
Allerdings sind diese Verfahren sehr instabiel und funktionieren nur für sehr einfach Probleme bzw auch dort nur für bestimmte Parameter.
Sobald man hier zu zu besseren Verfahren übergeht hat man höhere Abhänigkeiten (zb. implizites Verfahren erfordert im obrigen Fall die lösung einer spares Matrix).
Und so etwas wie die Navier Stocks ist noch mal etwas anderes.

Gast

2008-07-10, 17:34:49