Abo
  1. Foren
  2. Kommentare
  3. PC-Hardware
  4. Alle Kommentare zum Artikel
  5. › Intel vs. AMD: Vier-Kern-Schlacht…

Bin mal gespannt...

  1. Thema

Neues Thema Ansicht wechseln


  1. Bin mal gespannt...

    Autor: LeMurmel 02.11.06 - 17:58

    ...wieviel schlecht informierte "Zocker" sich das Teil kaufen werden - in der Hoffnung dass diese Doppel-Doppel-Kern-Konstrukt die Framerate hochtreibt :D

    Blöd nur, dass Games keine Multithread-Anwendungen sind.
    Mehr als 2 Cores können aktuelle Games nicht nutzen. Und das wird auch noch 'ne Weile so bleiben :>

  2. Re: Bin mal gespannt...

    Autor: Frage. 03.11.06 - 06:48

    LeMurmel schrieb:
    -------------------------------------------------------
    > ...wieviel schlecht informierte "Zocker" sich das
    > Teil kaufen werden - in der Hoffnung dass diese
    > Doppel-Doppel-Kern-Konstrukt die Framerate
    > hochtreibt :D
    >

    Hier scheint es, als würdest du dich mit uns anderen, scheinbar informierten verbrüdern...

    > Blöd nur, dass Games keine Multithread-Anwendungen
    > sind.
    > Mehr als 2 Cores können aktuelle Games nicht
    > nutzen. Und das wird auch noch 'ne Weile so
    > bleiben :>

    ...um uns hier zu zeigen, dass wir trotzdem keine Ahnung haben.

    ;-)

  3. Re: Bin mal gespannt...

    Autor: Frau_Holle 03.11.06 - 09:35

    LeMurmel schrieb:
    -------------------------------------------------------
    > ...wieviel schlecht informierte "Zocker" sich das
    > Teil kaufen werden - in der Hoffnung dass diese
    > Doppel-Doppel-Kern-Konstrukt die Framerate
    > hochtreibt :D
    >
    > Blöd nur, dass Games keine Multithread-Anwendungen
    > sind.
    > Mehr als 2 Cores können aktuelle Games nicht
    > nutzen. Und das wird auch noch 'ne Weile so
    > bleiben :>

    Also, mal nebenbei bemerkt, wenn ich ein 'multithreaded' Programm erstelle, dann limitiere ich nicht die Zahl der Prozessoren (MAX_ALLOWED_CPU). Woher hast Du diese spektakuläre Information?

    Wenn eine Software, thread-orientiert programmiert vorausgesetzt, 2 CPUs nutzen kann, dann impliziert dies (mit einschränkungen), daß sie auch n oder 2n oder n+1 oder 2(n+1) CPUs nutzen kann! Es sei denn Windoof verwendet keine POSIX threads oder daran angelehnte Modelle.

  4. Re: Bin mal gespannt...

    Autor: LeMurmel 03.11.06 - 18:02

    Frau_Holle schrieb:
    -------------------------------------------------------
    > Wenn eine Software, thread-orientiert programmiert
    > vorausgesetzt, 2 CPUs nutzen kann, dann impliziert
    > dies (mit einschränkungen), daß sie auch n oder 2n
    > oder n+1 oder 2(n+1) CPUs nutzen kann! Es sei denn
    > Windoof verwendet keine POSIX threads oder daran
    > angelehnte Modelle.

    Soweit ich informiert bin, unterstützen gerade mal eine handvoll Spiele Multiprozessing. Schön und gut, es werden mehr.
    Werden die Daten dadurch schneller aufbereitet? Ein SingleCore ist mit so einem Game brauchbar ausgelastet, aber noch weit von voller Auslastung entfernt.
    Und bei 'nem DualCore? Soviel private Rechenarbeit für den zweiten Core wirft Multiprozessing auch nicht ab.
    Was machen dann 4 Cores wenn der User zockt? Noch mehr Langeweile!

    Warum ist das so?
    Naja, aus einem Game mehrere Prozesse zu machen ist schwierig. Auch wenn man weitere Features wie Physik und richtig aufwändige KI in die GameEngine implementiert, die Prozesse müssen erstmal auf den Hauptprozess warten, bis der seine Infos rausrückt.

    Zocken mit QuadCore stell ich mir so vor: (stark vereinfacht!)
    Core 1 übernimmt den grundsätzllichen Spielablauf und kümmert sich um die I/Os.
    Core 2 wartet darauf, dass Core 1 endlich die Daten zur KI-Berechnung freigibt, rechnet bissl rum und stellt die Daten wieder Core 1 zur Verfügung.
    Core 3 würde gerne die Physikberechnung durchführen, muss aber erstmal abwarten bis Core 1 mit den Daten von Core 2 den Spielablauf soweit komplettiert hat.
    Core 4 langweilt sich, administriert bissl rum.
    GPU wartet auf CPU, wann's denn endlich weitergeht.

    Und der Spieler? Der wartet auf ein Bild.

    Das Problem bei Spielen liegt einfach in der fehlenden Parallelisierung der Prozesse. Die einzelen Abteilungen sind zu sehr voneinander abhängig.
    Ich betone nochmal, das gilt nur für Games!

    Es gibt genügend Multipozessingähige Anwendersoftware, die von MultiCore-CPUs durchaus profitiern würden. Nur für Spiele-PCs sind QuadCores so sinnvoll wie 2 Mittelklasse-Grafikkarten im SLI/CF statt einer Topkarte...

  5. Re: Bin mal gespannt...

    Autor: Schneewittchen 04.11.06 - 17:07

    LeMurmel schrieb:
    -------------------------------------------------------
    > Frau_Holle schrieb:
    > --------------------------------------------------
    > -----
    > > Wenn eine Software, thread-orientiert
    > programmiert
    > vorausgesetzt, 2 CPUs nutzen
    > kann, dann impliziert
    > dies (mit
    > einschränkungen), daß sie auch n oder 2n
    > oder
    > n+1 oder 2(n+1) CPUs nutzen kann! Es sei denn
    >
    > Windoof verwendet keine POSIX threads oder
    > daran
    > angelehnte Modelle.
    >
    > Soweit ich informiert bin, unterstützen gerade mal
    > eine handvoll Spiele Multiprozessing. Schön und
    > gut, es werden mehr.
    > Werden die Daten dadurch schneller aufbereitet?
    > Ein SingleCore ist mit so einem Game brauchbar
    > ausgelastet, aber noch weit von voller Auslastung
    > entfernt.
    > Und bei 'nem DualCore? Soviel private Rechenarbeit
    > für den zweiten Core wirft Multiprozessing auch
    > nicht ab.
    > Was machen dann 4 Cores wenn der User zockt? Noch
    > mehr Langeweile!
    >
    > Warum ist das so?
    > Naja, aus einem Game mehrere Prozesse zu machen
    > ist schwierig. Auch wenn man weitere Features wie
    > Physik und richtig aufwändige KI in die GameEngine
    > implementiert, die Prozesse müssen erstmal auf den
    > Hauptprozess warten, bis der seine Infos
    > rausrückt.
    >
    > Zocken mit QuadCore stell ich mir so vor: (stark
    > vereinfacht!)
    > Core 1 übernimmt den grundsätzllichen Spielablauf
    > und kümmert sich um die I/Os.
    > Core 2 wartet darauf, dass Core 1 endlich die
    > Daten zur KI-Berechnung freigibt, rechnet bissl
    > rum und stellt die Daten wieder Core 1 zur
    > Verfügung.
    > Core 3 würde gerne die Physikberechnung
    > durchführen, muss aber erstmal abwarten bis Core 1
    > mit den Daten von Core 2 den Spielablauf soweit
    > komplettiert hat.
    > Core 4 langweilt sich, administriert bissl rum.
    > GPU wartet auf CPU, wann's denn endlich
    > weitergeht.
    >
    > Und der Spieler? Der wartet auf ein Bild.
    >
    > Das Problem bei Spielen liegt einfach in der
    > fehlenden Parallelisierung der Prozesse. Die
    > einzelen Abteilungen sind zu sehr voneinander
    > abhängig.
    > Ich betone nochmal, das gilt nur für Games!
    >
    > Es gibt genügend Multipozessingähige
    > Anwendersoftware, die von MultiCore-CPUs durchaus
    > profitiern würden. Nur für Spiele-PCs sind
    > QuadCores so sinnvoll wie 2
    > Mittelklasse-Grafikkarten im SLI/CF statt einer
    > Topkarte...



    Ergänzend dazu:
    Parallel zu den Hauptprozessore(n) rendert die Grafikkarte.
    Wohl alle Spiele heutzutage reizen die GK aus, den Prozessor aber nicht. IdR. ist der Prozessor also damit beschäftigt, auf die GK zu warten, wenn er mit den für diesen Frame nötigen Rechenoperationen fertig ist.
    Das Gelaber mit rechenaufwendiger KI ist nur Schnee.
    Physik wird in der Zukunft der grosse Rechenzeit-Verschlinger sein, aber auch da müssen die Daten verschiedener Objekte miteinander synchronisiert werden, ergo multithreading ade. Ausserdem geht der Trend hier Richtung für diesen Zweck spezialisierter Physikkarten.

    Wer braucht´s also?
    Alle, die Anwendungen betreiben, die rechenaufwendig und gut parallelisierbar sind. Als da wären zB aufwendige Renderings von Einzelbildern, die nicht die Grafikkartenpower nutzen, zB. in Modelling-Tools, also das Rendern von Filmen.

    Vielleicht fängt auch mal jemand wieder an, einen tollen Voxelrenderer zu schreiben. Ich weiss aber nicht, wie da die Patentlage momentan ist.









  6. Re: Bin mal gespannt...

    Autor: Mal ne Frage 04.11.06 - 18:15

    LeMurmel schrieb:
    -------------------------------------------------------

    > Soweit ich informiert bin, unterstützen gerade mal
    > eine handvoll Spiele Multiprozessing. Schön und
    > gut, es werden mehr.
    > Werden die Daten dadurch schneller aufbereitet?
    > Ein SingleCore ist mit so einem Game brauchbar
    > ausgelastet, aber noch weit von voller Auslastung
    > entfernt.

    Bedeutet das denn nicht, dass eigentlich wir eine asynchron-performante Multicorearchitektur brauchen? Also eine mit einem starken Maincore mit weniger leistungsfähigen angeschlossenen Cores - also so in etwa wie die Cellchip? Ich will weiß Gott jetzt nicht sagen, dass PS3 alles "über" ist, nur je mehr ich das Klagelied der Spieleprogrammierer höre über die Schwierigkeit von Multithreads in Spielen, desto eher glaube ich, dass der Cell Vorteile gegenüber der normalen Multicorearchitektur hat. Kann ein Weiser mal für Aufklärung sorgen? :-)

  7. Re: Bin mal gespannt...

    Autor: LeMurmel 04.11.06 - 19:42

    Schneewittchen schrieb:
    -------------------------------------------------------
    > Das Gelaber mit rechenaufwendiger KI ist nur
    > Schnee.

    Eine richtig gute KI setzt ein komplexes neuronales Netz voraus. Da "kann" schon ordentlich Rechnenleistung entstehen...

    Schneewittchen schrieb:
    -------------------------------------------------------
    > Physik wird in der Zukunft der grosse
    > Rechenzeit-Verschlinger sein, aber auch da müssen
    > die Daten verschiedener Objekte miteinander
    > synchronisiert werden, ergo multithreading ade.
    > Ausserdem geht der Trend hier Richtung für diesen
    > Zweck spezialisierter Physikkarten.

    Da bin ich aber anderer Meinung. Physik-Berechungen sind ziemlich einfach strukturiert* und benötigen alles andere als eine speziell darauf abgerichtete PPUs. Sowas lässt sich auf einem gelangweilten Core eines MultiCore-CPUs locker nebenher berechnen.

    * Es werden die selben (recht einfachen und nur selten verschachtelten) Algorithmen ausm Physikunterricht verwendet. Hohe Präzision ist bei Games nicht dringend notwendig, es geht ja im Endeffekt nur um EyeCandy. Also muss sich der Prozessor auch nicht um Nachkommastellen kümmern, was die ganze Sache noch simpler macht und zudem die Quantität steigert.

    PhysiX-Karten sind nichts weiter als ein Marketing-Gag, der zu allem Überfluss auch noch zu funktionieren scheint.

  8. Posix bei Windows?

    Autor: ixzibilix 04.11.06 - 22:33

    Frau_Holle schrieb:
    -------------------------------------------------------
    > LeMurmel schrieb:
    > --------------------------------------------------
    > -----
    > > ...wieviel schlecht informierte "Zocker" sich
    > das
    > Teil kaufen werden - in der Hoffnung dass
    > diese
    > Doppel-Doppel-Kern-Konstrukt die
    > Framerate
    > hochtreibt :D
    >
    > Blöd nur,
    > dass Games keine Multithread-Anwendungen
    >
    > sind.
    > Mehr als 2 Cores können aktuelle Games
    > nicht
    > nutzen. Und das wird auch noch 'ne
    > Weile so
    > bleiben :>
    >
    > Also, mal nebenbei bemerkt, wenn ich ein
    > 'multithreaded' Programm erstelle, dann limitiere
    > ich nicht die Zahl der Prozessoren
    > (MAX_ALLOWED_CPU). Woher hast Du diese
    > spektakuläre Information?
    >
    > Wenn eine Software, thread-orientiert programmiert
    > vorausgesetzt, 2 CPUs nutzen kann, dann impliziert
    > dies (mit einschränkungen), daß sie auch n oder 2n
    > oder n+1 oder 2(n+1) CPUs nutzen kann! Es sei denn
    > Windoof verwendet keine POSIX threads oder daran
    > angelehnte Modelle.
    >
    >
    Ah ja, Posix und Windows. Alles klar. *rolleye*

  9. Re: Posix bei Windows?

    Autor: awk-user 04.11.06 - 23:09


    > Ah ja, Posix und Windows. Alles klar. *rolleye*

    im gegensatz zu linux wurde windows nt immerhin posix zertifiziert

  10. Re: Posix bei Windows?

    Autor: ixzibilix 05.11.06 - 01:00

    awk-user schrieb:
    -------------------------------------------------------
    > > > Ah ja, Posix und Windows. Alles klar.
    > *rolleye*
    >
    > im gegensatz zu linux wurde windows nt immerhin
    > posix zertifiziert


    http://support.microsoft.com/kb/308259/de

    Alleine die Überschrift sagt schon alles: "
    POSIX und OS/2 werden nicht unter Windows XP oder Windows Server 2003 unterstützt"

  11. Re: Bin mal gespannt...

    Autor: me_ 05.11.06 - 01:47

    Frau_Holle schrieb:
    -------------------------------------------------------
    > Es sei denn
    > Windoof verwendet keine POSIX threads oder daran
    > angelehnte Modelle.
    >
    >

    Windows verwendet die Posix-Thread-API für Multithreading wirklich nicht weil es sich dabei eben um eine API handelt, die von Kompiler zu Kompiler verschieden sein kann und Visual Studio eben nicht Posix-Threads implementiert hat. Nutzt Du allerdings GCC unter Windows, hast Du sie wieder.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Capgemini Deutschland GmbH, Stuttgart
  2. Institut für Arbeitswissenschaft und Technologiemanagement der Universität Stuttgart, Stuttgart
  3. ING-DiBa AG, Frankfurt
  4. Diemar Jung Zapfe Gruppe, Erfurt, Leipzig

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Blu-ray-Angebote
  1. (u. a. John Wick, Sicario, Deepwater Horizon, Die große Asterix Edition, Die Tribute von Panem)
  2. (u. a. 3 Blu-rays für 15€, 2 Neuheiten für 15€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Pixel 3 und Pixel 3 XL im Hands on: Googles Smartphones mit verbesserten Kamerafunktionen
Pixel 3 und Pixel 3 XL im Hands on
Googles Smartphones mit verbesserten Kamerafunktionen

Google hat das Pixel 3 und das Pixel 3 XL vorgestellt. Bei beiden neuen Smartphones legt das Unternehmen besonders hohen Wert auf die Kamerafunktionen. Mit viel Software-Raffinessen sollen gute Bilder auch unter widrigen Umständen entstehen. Die ersten Eindrücke sind vielversprechend.
Ein Hands on von Ingo Pakalski

  1. BQ Aquaris X2 Pro im Hands on Ein gelungenes Gesamtpaket mit Highend-Funktionen

Shine 3: Neuer Tolino-Reader bringt mehr Lesekomfort
Shine 3
Neuer Tolino-Reader bringt mehr Lesekomfort

Die Tolino-Allianz bringt das Nachfolgemodell des Shine 2 HD auf den Markt. Das Shine 3 erhält mehr Ausstattungsdetails aus der E-Book-Reader-Oberklasse. Vor allem beim Lesen macht sich das positiv bemerkbar.
Ein Hands on von Ingo Pakalski

  1. E-Book-Reader Update macht Tolino-Geräte unbrauchbar

Neuer Echo Dot im Test: Amazon kann doch gute Mini-Lautsprecher bauen
Neuer Echo Dot im Test
Amazon kann doch gute Mini-Lautsprecher bauen

Echo Dot steht bisher für muffigen, schlechten Klang. Mit dem neuen Modell zeigt Amazon, dass es doch gute smarte Mini-Lautsprecher mit dem Alexa-Sprachassistenten bauen kann, die sogar gegen die Konkurrenz von Google ankommen.
Ein Test von Ingo Pakalski


    1. BVG: Mit bis zu 500 MBit/s im Bus-WLAN unterwegs
      BVG
      Mit bis zu 500 MBit/s im Bus-WLAN unterwegs

      Berliner Linienbusse werden über LTE Advanced mit WLAN angebunden. Der Fahrgast könne damit 100 und 150 MBit/s erwarten, meint die BVG.

    2. Europäischer Gerichtshof: Kein schwarzer Tag für alle Filesharing-Abgemahnten
      Europäischer Gerichtshof
      Kein schwarzer Tag für alle Filesharing-Abgemahnten

      Das Urteil des Europäischen Gerichtshofs zum Filesharing ändert nichts. Es bestätigt nur die bisherige Rechtsprechung des Bundesgerichtshofs. Anschlussinhaber haben nach der grundrechtlich weiterhin besonders geschützten Familie keine näheren Nachforschungspflichten und müssen Angehörige nicht ausspionieren.

    3. Sicherheitslücke in Windows: Den Gast zum Admin machen
      Sicherheitslücke in Windows
      Den Gast zum Admin machen

      Eine Sicherheitslücke in Windows erlaubt, die Rechte von Nutzerkonten auszuweiten. Die Lücke ist seit zehn Monaten bekannt und wurde noch nicht geschlossen. Schadsoftware-Autoren dürften sich freuen.


    1. 19:03

    2. 18:40

    3. 17:44

    4. 17:29

    5. 17:17

    6. 17:00

    7. 17:00

    8. 16:48