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

Parallelisierung statt Verkleinerung

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Parallelisierung statt Verkleinerung

    Autor: Heintje 02.09.13 - 17:36

    Der Rüstungswahn bei den Gamern hat aber imho einen anderen Hauptgrund. Und zwar die uralt Hardware der drecks Konsolen. Es gibt doch kaum noch reine PC-Games, nein alles muss auf 7-8 Jahre alte Hardware portiert werden können.

    Mal sehen obs mit der neuen Konsolen-Gen mal nen ordentlichen Schub gibt.

  2. Re: Parallelisierung statt Verkleinerung

    Autor: motzerator 02.09.13 - 17:42

    hackCrack schrieb:
    -------------------------------
    > 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?

    Bei 30 Kernen? Ganz einfach...

    3 Minuten Stereo = 6 Min Mono = 360 Sekunden

    360 Sekunden geteilt durch 30 kerne sind 12 Sekunden Musik pro Kern. Das müsste machbar sein :)

  3. Re: Parallelisierung macht die Chips aber nicht kleiner

    Autor: motzerator 02.09.13 - 17:44

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

    Richtig, aber wenn die Prozesse mit 5 nm laufen wird
    man die eben weiter optimieren wenn man an der
    Strukturbreite nix mehr machen kann. Wenn man dann
    den gleichen 5 nm Chip zum halben Preis hinbekommt,
    hat man die Leistung bei gleichem Preis auch wieder
    verdoppelt.

  4. Re: Parallelisierung statt Verkleinerung

    Autor: Nephtys 02.09.13 - 17:45

    motzerator schrieb:
    --------------------------------------------------------------------------------
    > hackCrack schrieb:
    > -------------------------------
    > > 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?
    >
    > Bei 30 Kernen? Ganz einfach...
    >
    > 3 Minuten Stereo = 6 Min Mono = 360 Sekunden
    >
    > 360 Sekunden geteilt durch 30 kerne sind 12 Sekunden Musik pro Kern. Das
    > müsste machbar sein :)


    Schlechteste Parallelisierung EVER.
    Es sollte stets das Ziel sein, dass das Ergebnis nicht verfälscht wird, in dem Fall wird es das.

  5. Re: Parallelisierung statt Verkleinerung

    Autor: mnementh 02.09.13 - 18:22

    motzerator schrieb:
    --------------------------------------------------------------------------------
    > hackCrack schrieb:
    > -------------------------------
    > > 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?
    >
    > Bei 30 Kernen? Ganz einfach...
    >
    > 3 Minuten Stereo = 6 Min Mono = 360 Sekunden
    >
    > 360 Sekunden geteilt durch 30 kerne sind 12 Sekunden Musik pro Kern. Das
    > müsste machbar sein :)
    Schon mit der Trennung von rechts und links verzichtest Du auf Joint Stereo und damit für viele Aufnahmen auf immensen Kompressionspotential. Außerdem sidn die Frames wohl nicht unabhängig voneinander, das wird bei der Kompression beachtet. Wenn Du die Stücke zerhackst, dann hast Du an den Bruchstellen jeweils eine verschlechterte Qualität. Außer Du nimmst immer noch eine halbe Sekunde von dem Kram, den der andere Kern bearbeitet. Also sind es schon einmal 12,5 Sekunden. Nun sind nicht alle Kerne immer gleich schnell, ein Kern kann durch andere Prozesse oder Systemaufgaben gestört werden. Sinnvollerweise zerlegt man also bei 30 Kernen die Aufgabe in mehr Teile, sagen wir 120 und gibt jedem Kern eine Aufgabe, sobald er sich verfügbar meldet. Dann sind es schon 3,5 Sekunden für jedes Arbeitspaket, wovon 0,5 Sekunden Overhead sind. Wenn wir nun Leistungssteigerung durch fortdauernde Parallelisierung erreichen wollen sprechen wir langfristig von 1000 Kernen. Überlege Dir da den entsprechenden Overhead des Encoders.

    Grundsätzlich hat der Threadstarter aber völlig vergessen, dass wir für Parallelisierung zwingend die Strukturverkleinerung brauchen. Also statt 'Parallelisierung statt Verkleinerung' heißt es ja heute schon 'Verkleinerung für Parallelisierung'. Oder wie sonst passen Hunderte Shader in eine Grafikkarte, die nicht Dein ganzes Wohnzimmer an Platz einnimmt.

  6. Re: Parallelisierung macht die Chips aber nicht kleiner

    Autor: mnementh 02.09.13 - 18:23

    motzerator schrieb:
    --------------------------------------------------------------------------------
    > Xstream schrieb:
    > ---------------------------
    > > Parallelisierung hilft gegen die Notwendigkeit immer
    > > höherer Taktraten aber nicht dabei mehr Performance
    > > für das gleiche Geld zu erzielen
    >
    > Richtig, aber wenn die Prozesse mit 5 nm laufen wird
    > man die eben weiter optimieren wenn man an der
    > Strukturbreite nix mehr machen kann. Wenn man dann
    > den gleichen 5 nm Chip zum halben Preis hinbekommt,
    > hat man die Leistung bei gleichem Preis auch wieder
    > verdoppelt.
    das hat aber nichts mehr mit Parallelisierung zu tun. Und ehrlich, man hat da schon sehr wesentlich an der Ecke optimiert, mit möglichst wenigen Bauteilen möglichst viel Performance rauszukriegen. Ich bezweifle dass da noch so viel zu holen ist.

  7. Re: Parallelisierung statt Verkleinerung

    Autor: MarkusXXX 02.09.13 - 18:31

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Ob man das als Parallelisierung betrachten kann?

    Wenn Du 4 Multiplikationen gleichzeitig machst, dann ist das doch parallelisiert. Genau das macht SSE.

    > 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.

    Nein, die Anbindung an den L1-Cache ist 128 bit breit. Da findet ein einzelnes load statt. Deswegen müssen die SSE-Variablen auch 128bit aligned sein.

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

    Es gibt ja Sprachen wie zB matlab, die mit Matrizen umgehen können. Aber ob das wirklich ein Vorteil bei der Parallesierung ist? Compiler können Schleifen schon sehr lange aufdröseln und parallelisieren.

  8. Re: Parallelisierung statt Verkleinerung

    Autor: mnementh 02.09.13 - 18:37

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Aber wie stellst du dir bitte eine Parallelisierung von Datentypen vor? Ein
    > 32Bit Integer kann nicht parallelisiert werden ;)
    >
    Im Prinzip sind sie auf Hardwareebene parallelisiert. Bei einer Addition zweier Integers werden die Bits werden nicht einzeln addiert, sondern alle auf einmal (auf modernen Prozessoren). Aber da ist Schluss. Die Bits kann man nicht mehr parallelisieren.

  9. Re: Parallelisierung statt Verkleinerung

    Autor: Anonymer Nutzer 02.09.13 - 18:39

    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.
    >
    > 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.

    +1

    Paßt nicht ganz zum Thema.... aber hier weitere interessante Infos:

    Text
    http://www.fraunhofer.de/de/presse/presseinformationen/2013/juni/programmiermodell-fuer-zukuenftige-supercomputer.html

    Video
    http://www.fraunhofer.de/de/presse/filme/filme-2013/video-programmiermodell-supercomputer.html

  10. Re: Parallelisierung statt Verkleinerung

    Autor: MarkusXXX 02.09.13 - 18:51

    mnementh schrieb:

    > Wenn Du die Stücke zerhackst, dann hast Du an den
    > Bruchstellen jeweils eine verschlechterte Qualität.

    Das glaub ich nicht. Bei Video ist es definitiv so, dass regelmäßig neu aufgesetzt wird, z.B bei einem Szenenwechsel, aber auch einfach so; typischerweise alle paar Sekunden.

    Bei MP3 weiß ich nicht wie es ist, aber die Indizien deuten stark darauf hin, dass es ähnlich ist. Denn wenn es keine regelmäßigen Neustarts gibt, dann kann man a) nicht zu einer anderen Stelle springen ohne alles zwischendurch zu dekodieren und b) würde dann ein gekipptes Bit die gesamte Datei ruinieren.

  11. Re: Parallelisierung statt Verkleinerung

    Autor: h1j4ck3r 03.09.13 - 09:03

    Da helfen fehlerkorrigierende Codes

  12. Re: Parallelisierung statt Verkleinerung

    Autor: MarkusXXX 03.09.13 - 18:28

    h1j4ck3r schrieb:
    --------------------------------------------------------------------------------
    > Da helfen fehlerkorrigierende Codes

    Nein, da man die ja nicht nachträglich reinfügen kann. Man hätte das bei der Spezifikation des Protokolls machen müssen.

  13. Re: Parallelisierung statt Verkleinerung

    Autor: YoungManKlaus 03.09.13 - 21:08

    http://de.wikipedia.org/wiki/Amdahlsches_Gesetz

  14. Re: Parallelisierung statt Verkleinerung

    Autor: xioxios 23.01.14 - 12:10

    muss doch garnicht mehr verkleinert werden wenn die entstehende währme abgeleitet weden kann kann höher getaktet werden.
    Zur Zeit wird mit Diamant statt silizium experimentiert...
    soweit ich weiss gibt es schon hochleistungs Transistoren auf dieser Basis.
    Da Diamant ein herforragender Währmeleiter ist sind extreme Leistungssteigerungen möglich. Das ganze steckt noch in den Kinderschuhen, etwa so wie vor 60 Jahren die ersten Transistoren.
    Und anhand von Meteoriten kann man nun auch Diamant auf Silizium Aufdampfen.
    mal sehn was da noch geschieht.....

  15. Re: Parallelisierung statt Verkleinerung

    Autor: hackCrack 23.01.14 - 13:34

    Musst du so alte thread-leichen ausgraben? ^^

  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. Materna Information & Communications SE, Berlin, Dortmund, Dresden, Köln, Düsseldorf
  2. Condor Flugdienst GmbH / FRA HP/B, Neu-Isenburg
  3. Allianz Deutschland AG, München Unterföhring
  4. ifap GmbH, Martinsried

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Toshiba N300 8 TB für 149,90€ und Gehäuselüfter von NZXT)
  2. (u. a. Battlefield V PC Download für 14,99€ und Battlefield 1 PC Download für 7,99€)
  3. (u. a. Battlefield Promo mit Battlefield V Definitive Edition für 24,99€, Star Wars Battlefront...
  4. 382,69€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de