Multicore CPU mit Message Passing statt festgelegtem Speicherbereich

[Screemer]

Vielleicht gibts ja zu der idee ein wenig diskussions bedarf: http://www.golem.de/news/chinesischer-forschungschip-16-core-cpu-mit-message-passing-1202-89946.html

[Coda]

Ist halt auch nix neues. Gab's alles schonmal in größer. Das Problem ist, dass das wieder mehr Arbeit für die Entwickler ist und die haben jetzt schon so ihre Probleme mit Parallelisierung.

[Spirou]

Dafür verwendet man ja auch gänzlich andere Methoden und im Idealfall entsprechende Sprachen, sodaß die Arbeit der Entwickler eher effizienter wird. Bereits in den 80ern wurde vorgeführt, daß prozedurale Strukturen compilerseitig aus Datenbeschreibungssprachen abgeleitet werden können, sofern Abhängigkeiten sauber abgebildet werden.

Das ist dann allerdings auch das Ende des Bastelcodings mit an C angelehnten Sprachen, denen dafür die Mächtigkeit fehlt. In den 80ern fehlte es einfach nur an entsprechend potenter Hardware. Damals hat man noch die Rechenzeit des Compilings recht teuer bezahlt und entsprechend kurz gehalten. Solche Prioritäten setzt heute ja niemand mehr.

[Coda]

Das hatten wir schonmal und du hast mir nicht mehr geantwortet.

Was ist denn nach deiner Definition eine solche "Datenbeschreibungssprache"? Wikipedia meint sowas wie SQL fällt darunter, was du ja sicher nicht im Sinn hast.

[Spirou]

SQL ist ja vorrangig nur eine prozedurale Substitution, die zwar Daten und ihre Beziehungen untereinander abbildet, aber in einem eng begrenzten Kontext, nämlich der Interaktion zu einem Handler, der als Interpreter zwischen Anwendungsebene und Daten vermittelt. Die Anwendungsebene wird dadurch ja nicht ersetzt.

Ich habe Ende der 80er bei Siemens experimentell an Metacompilern gearbeitet, für die Datenstrukturen über prozedurale Sprachelemente abgebildet wurden, um Methoden in einer 1:1 Beziehung zu halten. In der Praxis habe ich dafür eine Kombination von Makros und Runtime-Modulen eingesetzt. Objektbibliotheken wenn man so will.

Es gab ein OS, das auf BCPL basierend eine heute kaum noch vorstellbare Effizienz erreichte, weil seine gesamte Ressoucenverwaltung relational ausgerichtet war und das gesamte Eventhandling auf simplen Controlblocks und Listen beruhte, über die Attribute als Trigger abgearbeitet wurden. BCPL bot sich dafür regelrecht an.

Dass ich in dem anderen Thread das Thema nicht weiter vertiefe, liegt daran daß es ausufert, wenn man erst in die Geschichte der Methodenentwicklung des SE einsteigen muß, und dabei auf Techniken eingehen, die heute keine Rolle mehr spielen. Ich unterrichte in dem Bereich auch schon lange nicht mehr, und müsste reichlich Zeit investieren, das aufzubereiten, um hier ein riesiges Fass aufzumachen und am Ende UMLgerecht darzustellen, was ich eigentlich sagen will.

Prozedurale Abhängigkeiten als Attribute zu verwalten ermöglicht jedenfalls Parallellisierung vollständig zu automatisieren, ohne daß man nach der Modellierung seiner Daten noch Zeit investieren müsste.

[Coda]

Ich versteh kein Wort. Die Nomenklatur hat sich wohl radikal verändert. Ich kann es deshalb leider nicht beurteilen.

[Aquaschaf]

Bei "Parallelisierung vollständig automatisieren" werde ich in jedem Fall schon sehr skeptisch.

[Shink]

Bei "Parallelisierung vollständig automatisieren" werde ich in jedem Fall schon sehr skeptisch.
Naja, wenn ich "prozedurale Abhängigkeiten" irgendwie abbilde, sag ich doch auch, bei welchem Code es egal ist, wenn er parallel läuft bzw. wann ich auf welche Daten warten muss. Der Rest passiert dann natürlich automatisch.

@Topic:
Mit etwas ala Co-Array Fortran bekäme man so etwas auch "quasi gratis" hin: Damit ist es prinzipiell egal ob man sein Zeug für UMA oder Message Passing-Architekturen parallelisiert.
Davon abgesehen ist das Ziel Supercomputer - da hat man oft entweder Batchabläufe oder Parameterstudien (die man ohnehin ohne Datenabhängigkeiten parallell laufen lassen kann) oder setzt ohnehin schon auf MPI (oder CAF:freak:).