ZeroZerp schrieb:
Ja- Aber auch bei Anwendungen wartest Du auf Zwischenergebnisse, ohne die Du andere Berechnungen eben nicht parallel anstoßen kannst.
Es ist trotzdem eine Beschränkung, die wegfällt. Wenn bei einer normalen Anwendung eine Operation 10 ms dauert, wirst du sie ohnehin nicht parallelisieren.
Nicht ausgereizt, aber bereits im ökonomisch Sinnvollen Bereichen durchgeführt.
Und woher weißt du das? In C++ werden erst seit C++11 Threads überhaupt unterstützt und die Umstellung auf C++11 wird gerade jetzt erst in Projekten durchgeführt. Bei größeren Projekten ist teilweise noch nicht mal C++14 geschweige denn C++17 in den Optionen des Compilers aktiviert und damit ist man noch weit davon entfernt aktuelle Sprachfeatures zu verwenden. Vor C++11 war immer die Verwendung von Third-Party-Libraries notwendig.
Bis heute erscheinen immer wieder neue Sprachen, die die Verwendung von mehreren Threads vereinfachen wollen (X10, Go, Rust) und es ist immer noch ein aktuelles Forschungsthema. Da ist man weit ab von ökonomisch ausgereizt.
Es wäre völlig Sinnfrei das Datenpolling vom Datenträger über mehrere Kerne zu paralellisieren, weil der Flaschenhals dort nicht in der Rechenkapazität oder Aufbereitung der Daten sondern an der Übertragungsbandbreite und den Zugriffszeiten des Datenträgers hängt.
Nein, ist es nicht. Wäre tatsächlich der Datenträger der Flaschenhals, wäre nicht genau ein Thread ausgelastet. Dann würde das Betriebssystem dem Prozess keine Rechenzeit mehr zuweisen solange er auf die Daten wartet und der Prozess würde somit auch nicht für eine Auslastung sorgen.
Textdatei? -Zeig mir den CAD- Container, der seine Daten über eine Textdatei zur Verfügung stellt....
Es ging in dem Beispiel um STEP-Dateien und diese sind eben in ASCII codiert.
Gerade in der Bildverarbeitung wird immer gerne alles in einen Topf geworfen. Unterschiedliche Operationen sind auch unterschiedlich Multicore- tauglich zu machen.
Hast du Beispiele für Operationen, die nicht gut parallelisierbar sind?
Die Aussage ist insofern falsch, als dass es genug Probleme gibt, die auch nicht trivial nicht parallelisierbar sind.
Ich habe nie behauptet, dass jedes Problem trivial parallelisierbar ist. Allerdings ist das meistens eine Frage der Betrachtungsweise. Das Anwenden einer Funktion auf einen einzelnen Pixel mag nicht parallelisierbar sein. Wenn man diese Operation auf mehrere Pixel eines Bildes ausführt, ist das wiederum parallelisierbar.
Alle moderne Software am Markt ist inzwischen Multicore- optimiert und das schon in hohem Maße.
Warum wird dann immer noch so stark daran geforscht und entwickelt, wenn das Problem doch eigentlich schon gelöst ist?
Welche Software, die überhaupt noch nicht parallelisiert ist sollte das sein?
Wie hier bereits geschrieben z.B. das Laden von STEP-Dateien in Inventor.
Aber nur in den Grenzen Mathematischer Gesetzmäßigkeiten und Abläufen. Und die lassen sich nicht einfach dadurch wegdiskutieren indem man sich hinstellt und fordert, dass sich die Programmierer mehr Mühe geben müssen
Ja, wenn man die Parallelisierung ausgereizt hat, wird es eng. Aber an dem Punkt sind wir sicherlich noch nicht angekommen.
So ist derzeit der Stand- Aussicht auf große Leistungssteigerungen gibt es nur durch Designänderungen der Prozessoren bzw. der Wahl der Fertigungsmaterialien. Graphen etc...
Welche Designänderungen sollten das denn sein? Und warum investieren Forschungseinrichtungen Millionen in Parallelrechner mit mehreren Millionen Kernen, wenn man damit keine großen Leistungssteigerung mehr erzielen kann. Auch wenn diese für gewöhnlich nur durch mehrere Anwendungen vollständig ausgelastet werden, ist es keine Seltenheit, wenn eine einzelne Anwendung mehrere tausend Kerne verwendet.
