1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Prozessoren: Bei 5 Nanometern ist…

Parallelisierung statt Verkleinerung

Über PC-Games lässt sich am besten ohne nerviges Gedöns oder Flamewar labern! Dafür gibt's den Freiraum!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Parallelisierung statt Verkleinerung

    Autor: elgooG 02.09.13 - 13:50

    Parallelisierung statt Verkleinerung, sowie spezialisierte Kerne statt universelle Kerne ist das Stichwort. Hier lässt sich noch Unmengen an Leistung herausquetschen. Außerdem könnte man das Bussystem überarbeiten und vor allem bei der Speicheranbindung verbessern.

    Programmiersprachen sollten zudem Parallelisierung von Grund auf unterstützen und transparenter gestalten um Fehler zu vermeiden bzw. das Debugging zu verbessern. Auch Datentypen sollten von Grund auf Parallelisierung unterstützen. Hier gab es ja in den letzten Jahren schon sehr viel Bewegung, aber es wäre noch sehr viel mehr möglich.

    Allerdings betrifft der Leistungshunger immer weniger Anwendungsfälle. Wir sind schon länger auf einem Technologiestand bei dem meist gar nicht mehr die neuste Technik benötigt wird. Das ist selbst bei den Spielen zu sehen, wo eigentlich der Rüstungskrieg bisher am stärksten vertreten war. Auch bei Servern in Unternehmen denkt man inzwischen sehr viel pragmatischer als früher und mit Virtualisierung lassen sich viele Ressourcen viel einfacher nutzen und verteilen.

    Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

  2. Re: Parallelisierung statt Verkleinerung

    Autor: hackCrack 02.09.13 - 13:56

    Aber für simple stupide aufgaben kannst du auch nicht auf 30 cpu kerne verteilen, das ist einfach nicht umsetzbar.

    z.B. eine MP3 zu codieren. Da kannst du doch maximal noch die 2 audio spuren auf 2 kerne verlagern, aber was willst du da noch verteilen?

    Auserdem wird es extrem schwierig für jedes anwendungsszenario extra den passenden chip zu produzieren.

  3. Parallelisierung macht die Chips aber nicht kleiner

    Autor: Xstream 02.09.13 - 14:03

    Parallelisierung hilft gegen die Notwendigkeit immer höherer Taktraten aber nicht dabei mehr Performance für das gleiche Geld zu erzielen

  4. Re: Parallelisierung statt Verkleinerung

    Autor: körner 02.09.13 - 14:05

    Dann schneidet man die MP3 eben in 30 Teile und kodiert jeweils mit einem Kern. Die Nahtstellen werden extra kodiert, so dass das alles zusammen passt.

  5. Re: Parallelisierung statt Verkleinerung

    Autor: Lala Satalin Deviluke 02.09.13 - 14:07

    Eben. Es gibt ja schon Multi-Threading LAME-Implementationen.

    Grüße vom Planeten Deviluke!

  6. Re: Parallelisierung statt Verkleinerung

    Autor: hackCrack 02.09.13 - 14:08

    körner schrieb:
    --------------------------------------------------------------------------------
    > Dann schneidet man die MP3 eben in 30 Teile und kodiert jeweils mit einem
    > Kern. Die Nahtstellen werden extra kodiert, so dass das alles zusammen
    > passt.

    wenns nur so einfach wäre...
    Dann bewirb dich doch mal bei microsoft, ich glaube die würden die milliarden zahlen wenn du das so einfach machen kannst.

  7. Re: Parallelisierung statt Verkleinerung

    Autor: DaTebe 02.09.13 - 14:09

    MP3 Codierung funktioniert unter anderem mit Vorhersagen auf Tonhöhenänderungen. Das Zerscheiden könnte problematisch sein. Aber wie dem auch sei. Es gibt Studien, die belegen, dass der mehrnutzen von Parallelisierung ab 16 CPU Kernen zu gering ist. Es gibt eben Operationen die nur seriell abarbeitbar sind. Mal gucken was die Zukunft bringt

  8. Re: Parallelisierung statt Verkleinerung

    Autor: webbi87 02.09.13 - 14:17

    Grundsätzlich hast Du absolut recht mit der Parallelisierung, nur wird uns das mittel- langfristig nicht weiter helfen können. Dabei tritt nämlich wie oben schon einige gemeint hatte, das Problem auf, dass viele Anwendungen sich überhaupt nicht effizient parallelisieren lassen. Das mag in dem genannten MP3 Beispiel noch gar nicht wirklich das Problem sein, aber bestimmte Dinge sind einfach in sich abhängig von (Vor-) Ergebnissen, da kannst Du nur bis zu einem Bestimmten Punkt parallelisieren, ab dem Du nur noch performance verlierst. Es gibt zum Beispiel Vorhersagen, dass für unterschiedliche Anteile an Parallelisierbarkeit, bei ca. 30 Cores Schluss ist mit dem Performancegewinn. Eine weitere Parallelisierung bringt dir dann nur noch Nachteile (Mehr Stromverbrauch, keinen Zugewinn an Performance).

    Ich spreche z.B. von diesem Paper hier: Esmaeilzadeh, H., Blem, E., St. Amant, R., Sankaralingam, K., & Burger, D. (2011). Dark silicon and the end of multicore scaling. Proceeding of the 38th annual international symposium on Computer architecture - ISCA ’11, 365. doi:10.1145/2000064.2000108

    Ein weiteres Problem was bei diesen Ansätzen auftritt, ist die Zunahme an "Dark Silicon", also Bereichen deines Chips, die ausgeschaltet oder gedimmt werden müssen um innerhalb von thermischen Limits zu bleiben.
    Schonmal drüber nachgedacht warum Intel eigentlich "TurboBoost" erfunden haben? Das ist keine Spaß-Technik, die einfach nur ein paar Prozent rausquetscht, sondern einfach eine Möglichkeit noch etwas mehr rauszuholen, obwohl man bereits knapp unter den physikalischen Möglichkeiten der Chips liegt.

    Einfach nur mehr parallelisieren heißt nur, dass wir das Problem "verschieben", also uns später darum kümmern müssen. Andere Ansätze (z.B. der Einsatz reprogrammierbarer Hardwarebeschleuniger, die auf Energieeffizienz getrimmt sind), sind da wesentlich besser, wenn auch nicht so einfach auf den ersten Blick erkennbar. Beispiele dafür gibts auch einige, siehe z.B. http://greendroid.ucsd.edu/

  9. Re: Parallelisierung statt Verkleinerung

    Autor: mnementh 02.09.13 - 14:40

    elgooG schrieb:
    --------------------------------------------------------------------------------
    > [Parallelisierung]
    Auch für Paralellisierung brauchst Du die hier angesprochenen Transistoren. zwei Kerne brauchen (fast) doppelt so viele Transistoren (ohne Cache). Vier dann das vierfache usw.

    Wenn Du die Architektur nicht gleichzeitig änderst (beispielsweise die Zusatzkerne sehr einfach gestaltest), dann betrifft das Moores Gesetz genauso.

    Wir können natürlich in Zukunft zurück zu den Computern in Schrankform, mit einer netten Sitzbank drumherum.

  10. Re: Parallelisierung statt Verkleinerung

    Autor: non_sense 02.09.13 - 14:42

    DaTebe schrieb:
    --------------------------------------------------------------------------------
    > MP3 Codierung funktioniert unter anderem mit Vorhersagen auf
    > Tonhöhenänderungen. Das Zerscheiden könnte problematisch sein. Aber wie dem
    > auch sei. Es gibt Studien, die belegen, dass der mehrnutzen von
    > Parallelisierung ab 16 CPU Kernen zu gering ist. Es gibt eben Operationen
    > die nur seriell abarbeitbar sind. Mal gucken was die Zukunft bringt

    Eben.
    Parallelisierung ist zwar schön und gut, aber es ist auch nicht die eierlegende Wollmilchsau. Unter gewissen Umständen kann Parallelisierung sogar zum Nachteil werden, und sogar inperformanter sein, und verkompliziert die Entwicklung, wenn z.B. die Threads/Prozesse miteinander kommunizieren müssen. (Stichwort: Deadlocks)

  11. Re: Parallelisierung statt Verkleinerung

    Autor: tingelchen 02.09.13 - 15:11

    elgooG schrieb:
    --------------------------------------------------------------------------------
    > Parallelisierung statt Verkleinerung, sowie spezialisierte Kerne statt
    > universelle Kerne ist das Stichwort. Hier lässt sich noch Unmengen an
    > Leistung herausquetschen. Außerdem könnte man das Bussystem überarbeiten
    > und vor allem bei der Speicheranbindung verbessern.
    >
    Zu Parallelisierung wurde ja schon einiges gesagt. Im wesentlichen hängt der Grad an Nutzen stark vom Anwendungsfall ab. Spezialisierte Kerne haben wir bereits massenhaft. Darunter diverse Sound Prozessoren, Controler Chip, GPU's und natürlich Chip für die Physikberechnungen.
    Für den heutigen typischen Computer wird aber ein Hauptprozessor benötigt, welcher die Software ausführt, die alle diese speziellen Chips verwaltet.

    > Programmiersprachen sollten zudem Parallelisierung von Grund auf
    > unterstützen und transparenter gestalten um Fehler zu vermeiden bzw. das
    > Debugging zu verbessern. Auch Datentypen sollten von Grund auf
    > Parallelisierung unterstützen. Hier gab es ja in den letzten Jahren schon
    > sehr viel Bewegung, aber es wäre noch sehr viel mehr möglich.
    >
    Es gibt hier Ansätze bei diversen Hochsprachen. Eine CPU kann man aber nicht mit einer Hochsprache direkt programmieren. Es bedarf eines Zwischenschrittes und dieser muss auch mit irgend einer Sprache geschrieben werden.
    Wobei der Grad an Möglichkeiten essentiell nicht von der verwendeten Sprache abhängt, sondern von der API welche einem das OS bereit stellt.

    Aber wie stellst du dir bitte eine Parallelisierung von Datentypen vor? Ein 32Bit Integer kann nicht parallelisiert werden ;)

    > Allerdings betrifft der Leistungshunger immer weniger Anwendungsfälle. Wir
    > sind schon länger auf einem Technologiestand bei dem meist gar nicht mehr
    > die neuste Technik benötigt wird. Das ist selbst bei den Spielen zu sehen,
    > wo eigentlich der Rüstungskrieg bisher am stärksten vertreten war. Auch bei
    > Servern in Unternehmen denkt man inzwischen sehr viel pragmatischer als
    > früher und mit Virtualisierung lassen sich viele Ressourcen viel einfacher
    > nutzen und verteilen.
    >
    Die neuste Technik wird nicht mehr zwingend benötigt, weil die Software technologisch nicht mehr der Hardware hinter her kommt. Um hier einen Ausgleich zu schaffen, müssten die Hardwarehersteller hergehen und die Entwicklung neuer Chips für gut und gern 7 bis 10 Jahre einstellen.
    Sie könnten dann die Chips höchstens kleiner und sparsamer machen oder optimieren. Aber nicht die grundlegende Architektur verändern.

  12. Re: Parallelisierung statt Verkleinerung

    Autor: WhyLee 02.09.13 - 15:35

    DaTebe schrieb:
    --------------------------------------------------------------------------------
    > MP3 Codierung funktioniert unter anderem mit Vorhersagen auf
    > Tonhöhenänderungen. Das Zerscheiden könnte problematisch sein. Aber wie dem
    > auch sei. Es gibt Studien, die belegen, dass der mehrnutzen von
    > Parallelisierung ab 16 CPU Kernen zu gering ist. Es gibt eben Operationen
    > die nur seriell abarbeitbar sind. Mal gucken was die Zukunft bringt
    bei mp3 wird eine frequenzanalyse gemacht - vermutlich mit einer gefensterten fft - dieses fenster umfasst x werte, d.h. das material wird schon in fenster der größe x unterteilt, die dann getrennt voneinander vom zeitbereich in den frequenzbereich umgerechnet werden können. damit ist zumindest dieser teil von mp3 stark parallelisierbar. die nächste stufe ist dann das psychoakustische modell, daß dann frequenzen wegschmeisst - das ist möglicherweise nicht mehr so gut parallelisierbar. in weiterer folge erfolgt dann eine kodierung mit möglichst wenig bit - vielleicht auch wieder parallelisierbar. codiert man mit einem qualitätsfaktor müssen unterschieldiche kodierungen probiert und der resultierende fehler bewertet werden ==> wegen fensterung auch wieder parallelisierbar.
    allgemein kann man sagen, daß in der Signalverarbeitungspraxis (ob audio oder video) viele teile der berechnungen gut parallelisiserbar sind.

  13. Re: Parallelisierung statt Verkleinerung

    Autor: Snoozel 02.09.13 - 15:57

    Anständige Parallelisierung wäre wirklich endlich mal toll.
    Selbst SAP bekommt das nicht auf die Reihe - da hat man schon ein 16-Kern Blade, und ein dicker Langläufer-Job nutzt nur 1 davon weil die einzelnen Workprozesse nur je 1 Kern nutzen können - und die anderen 15 Kerne langweilen sich.



    1 mal bearbeitet, zuletzt am 02.09.13 15:57 durch Snoozel.

  14. Re: Parallelisierung statt Verkleinerung

    Autor: DaTebe 02.09.13 - 16:23

    WhyLee schrieb:
    --------------------------------------------------------------------------------
    > DaTebe schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > MP3 Codierung funktioniert unter anderem mit Vorhersagen auf
    > > Tonhöhenänderungen. Das Zerscheiden könnte problematisch sein. Aber wie
    > dem
    > > auch sei. Es gibt Studien, die belegen, dass der mehrnutzen von
    > > Parallelisierung ab 16 CPU Kernen zu gering ist. Es gibt eben
    > Operationen
    > > die nur seriell abarbeitbar sind. Mal gucken was die Zukunft bringt
    > bei mp3 wird eine frequenzanalyse gemacht - vermutlich mit einer
    > gefensterten fft - dieses fenster umfasst x werte, d.h. das material wird
    > schon in fenster der größe x unterteilt, die dann getrennt voneinander vom
    > zeitbereich in den frequenzbereich umgerechnet werden können. damit ist
    > zumindest dieser teil von mp3 stark parallelisierbar. die nächste stufe ist
    > dann das psychoakustische modell, daß dann frequenzen wegschmeisst - das
    > ist möglicherweise nicht mehr so gut parallelisierbar. in weiterer folge
    > erfolgt dann eine kodierung mit möglichst wenig bit - vielleicht auch
    > wieder parallelisierbar. codiert man mit einem qualitätsfaktor müssen
    > unterschieldiche kodierungen probiert und der resultierende fehler bewertet
    > werden ==> wegen fensterung auch wieder parallelisierbar.
    > allgemein kann man sagen, daß in der Signalverarbeitungspraxis (ob audio
    > oder video) viele teile der berechnungen gut parallelisiserbar sind.

    Was ist mit den Redundanzreduktionen am Ende? MP3 nutzt soweit ich weis Deflate, also Huffman + LZW. Würde sich das auch gut parallelisieren lassen (bin da gerade nicht mehr drinnen)

    Zu dem unterteilen der MP3 -> Da hast du vollkommen recht. mp3 besteht sowieso schon aus Frames, was das ganze streaming fähig macht. Interessant ist nicht umbedingt ob man es parallelisieren kann, sondern wie weit man es zerstückeln könnte ohne Kompressionsfaktoren zu verschlechtern (wie die von mir angeführte Prädiktive Kodierung).

    mfG =)

  15. Re: Parallelisierung statt Verkleinerung

    Autor: S0M30N3 02.09.13 - 16:32

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Spezialisierte Kerne haben
    > wir bereits massenhaft. Darunter diverse Sound Prozessoren, Controler Chip,
    > GPU's und natürlich Chip für die Physikberechnungen.

    Ich würde da eher an Befehlssatzerweiterungen wie AES-NI denken. Ich könnte mir ähnliches z.B. für LZMA vorstellen (keine Ahnung ob das technisch möglich wäre).



    1 mal bearbeitet, zuletzt am 02.09.13 16:33 durch S0M30N3.

  16. Re: Parallelisierung statt Verkleinerung

    Autor: Snoozel 02.09.13 - 16:41

    Und warum werden dann nicht die z.B. 16 Kerne Virtualisiert und als 1 CPU dem OS zur Verfügung gestellt?

  17. Re: Parallelisierung statt Verkleinerung

    Autor: narea 02.09.13 - 16:45

    Snoozel schrieb:
    --------------------------------------------------------------------------------
    > Und warum werden dann nicht die z.B. 16 Kerne Virtualisiert und als 1 CPU
    > dem OS zur Verfügung gestellt?

    Und was genau hilft es, wenn man die parallelisierung von der softwareebene in die hardware verschiebt? Die probleme bleiben die selben.

  18. Re: Parallelisierung statt Verkleinerung

    Autor: MarkusXXX 02.09.13 - 17:01

    tingelchen schrieb:

    > Aber wie stellst du dir bitte eine Parallelisierung von Datentypen vor? Ein
    > 32Bit Integer kann nicht parallelisiert werden ;)

    Der nicht, aber Du könntest zB 4 Stück davon in eine 128 Bit Variable packen. Das ist das, was bei den ganzen SIMD-Architekturen gemacht wird. Auf dem PC zB in Form von SSE. Die Frage ist aber natürlich, ob man das wirklich in der Programmiersprache haben will und nicht dem Compiler überlassen möchte.

  19. Re: Parallelisierung statt Verkleinerung

    Autor: tingelchen 02.09.13 - 17:07

    Derartige Erweiterungen gibt es ja bereits. Wobei man das immer auch Allgemein halten muss. Sonst hat man nachher Probleme, wenn Fehler enthalten sind. Je komplexer die Aufgaben des Befehlssatzes werden, desto wahrscheinlicher werden Fehler.

    Daher bin ich eher dafür das Prozessor entweder vollständig spezialisiert wird oder nur allgemein gehaltene Befehlssätze unterstützt.

  20. Re: Parallelisierung statt Verkleinerung

    Autor: tingelchen 02.09.13 - 17:17

    Ob man das als Parallelisierung betrachten kann? Die SIMD Instruktionen und Register gibt es ja schon ewig. Damals noch bekannt unter dem Namen MMX :) Bevor jedoch die Befehlssätze aktiv werden können, müssen die Register erst einmal geladen werden. Es sind nach wie vor mehrere Ladevorgänge nötig um 4 32Bit Werte in ein großes 128Bit Register zu laden.

    Zum einen lohnt sich das nicht bei allen Operationen und auch nicht alle Operationen, die man ausführen möchte, erlauben so eine Nutzung. Zumal diese Erweiterung mittlerweile so alt ist, das diese schon von den Compilern automatisch eingearbeitet wird. Wenn man dem Compiler auch sagt, das er das soll.


    Ich denke jedoch das er die Datentypen nicht auf Registerebene meinte, sondern auf Sprachebene.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. WWB Weser-Wohnbau Holding GmbH & Co. KG, Bremen
  2. Fiducia & GAD IT AG, Karlsruhe, München, Münster
  3. Melitta Business Service Center GmbH & Co. KG, Minden
  4. AUSY Technologies Germany AG, verschiedene Standorte

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 89,90€
  2. 179€ (Bestpreis)
  3. (u. a. Rocketman für 8,99€, Ready Player One für 8,79€, Atomic Blondie für 9,49€)
  4. (u. a. EA Promo (u. a. Unravel für 8,99€, Anthem für 8,99€), Tiny and Big: Grandpa's...


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme