1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Erste Demo von…

Wenn die CPU limitert

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. Wenn die CPU limitert

    Autor: DooMMasteR 14.08.14 - 12:55

    Dann mag daraus ja auch ein FPS gwinn entstehen, aber die CPU ürfte heute in den seltensten Fällen limitierender Faktor sein.

    Die Intel GPUs sind hingegen noch immer Schnecken lahm weshalb eine recht schwache AMD APU meist deutlich bessere Spieleperformance bietet.
    Wird nun das CPU bottleneck kleiner, sollte das sogar noch AMD, deren CPUs ja schon schwächer sind, weitere Vorteile bringen.

  2. Re: Wenn die CPU limitert

    Autor: EnemyArea 14.08.14 - 13:07

    kaum noch? spiel mal wow in ner 25 raid. die cpu ist und bleibt das problem. solange man keine vernünftige multicore rendering engine hat, wird das auch so bleiben.

  3. Re: Wenn die CPU limitert

    Autor: Eheran 14.08.14 - 13:14

    >aber die CPU ürfte heute in den seltensten Fällen limitierender Faktor sein.
    Da hier erst kürzlich mehrere Beiträge mit DayZ/Bohemia/... waren:
    Man krebst dann in DayZ/ArmA bei 20fps rum, obwohl GPU und CPU nur 30% Auslastung haben.
    Weil irgend ein einzelner Thread, der für irgendwas verantwortlich ist (z.B. AI) alles andere ausbremst. Bei 4 Kernen heißt das dann maximal 25% CPU-Auslastung...
    Witzig ist auch, dass der eine Thread dennoch auf allen 4 Kernen ausgeführt wird - nur halt insgesammt trozdem auf die 25% limitiert ist. Alle 4 Kerne sind gleichmäßig ~30% Ausgelastet.

  4. Re: Wenn die CPU limitert

    Autor: Auf 'ne Cola 14.08.14 - 13:24

    Tatsächlich ist in einem Moment nur ein Kern zu 100% ausgelastet.
    Windows schiebt jedoch die Threads herum, sodass letztendlich im Durchschnitt 25% (plus andere Prozesse 30%) herauskommen.

  5. Re: Wenn die CPU limitert

    Autor: Eheran 14.08.14 - 13:35

    Ja, aber wenn das geht, wieso dann noch die Limitierung auf 25%?
    Egal wie rum - das macht keinen Sinn.

  6. Re: Wenn die CPU limitert

    Autor: muh3 14.08.14 - 13:56

    Immer dieses Gerede vonwegen, welcher CPU das was bringt und welcher nicht.

    Vorhandene Rechenleistung wird effizienter ausgenutzt! Das bringt jeder CPU etwas!

    Dadurch spart man Strom und/oder kriegt mehr FPS.

    Als ob es irgendeine CPU auf der Welt gibt, welche nicht davon profitiert wenn man Programmteile effizienter macht.

  7. Re: Wenn die CPU limitert

    Autor: Sebbi 14.08.14 - 14:01

    Eheran schrieb:
    --------------------------------------------------------------------------------
    > Ja, aber wenn das geht, wieso dann noch die Limitierung auf 25%?
    > Egal wie rum - das macht keinen Sinn.

    Ein Thread, eine CPU. So weit verstanden?

    Vermutlich wird der in jedem Zyklus neu gestartet oder hat irgendwann einmal ein "wait" eingebaut, das ihn schlafen legt. Dann wandert er reihum durch die vorhandenen CPUs.

    Das geht so schnell, dass es aussieht als seien alle Kerne gleich schwach ausgelastet. Real ist aber immer nur einer voll ausgelastet.

  8. Re: Wenn die CPU limitert

    Autor: Eheran 14.08.14 - 14:06

    >Ein Thread, eine CPU. So weit verstanden?
    Ein Thread, ein Kern...?

    >Das geht so schnell, dass es aussieht als seien alle Kerne gleich schwach ausgelastet. Real ist aber immer nur einer voll ausgelastet.

    Auch wenn das eine Erklärung wäre, ich bleibe bei der Aussage:
    > Egal wie rum - das macht keinen Sinn.
    Denn so müssen alle Kerne die ganze Zeit voll hochgetaktet sein - die andern 3 können nie Energie sparen. Vom zustätzlichen Overhead mal ganz abgesehen.
    Dazu kommt, dass es keine Vorteile bringen würde pausenlos zu rotieren.
    Alles zusammen: Ich glaube das nicht.
    Kannst du das irgendwie untermauern bzw. weiter ausführen warum man soetwas machen sollte?

  9. Re: Wenn die CPU limitert

    Autor: KarlaHungus 14.08.14 - 15:06

    EnemyArea schrieb:
    --------------------------------------------------------------------------------
    > kaum noch? spiel mal wow in ner 25 raid. die cpu ist und bleibt das
    > problem. solange man keine vernünftige multicore rendering engine hat, wird
    > das auch so bleiben.

    Also ich hab neulich auf meinem Intel mit ner 30er Raid locker 50 fps / s gehabt. Selbst ohne Magic Touch Erweiterung. Nur ab 45 Priest wurde es dann ein bißchen eng. Ich denke nicht, dass das an multicore liegt. Schließlich hat der i7 ne Rendering Engine vom feinsten!

    wερ δας λιεστ wιρδ δοοφ.

  10. Re: Wenn die CPU limitert

    Autor: check0790 14.08.14 - 16:12

    KarlaHungus schrieb:
    --------------------------------------------------------------------------------
    > EnemyArea schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > kaum noch? spiel mal wow in ner 25 raid. die cpu ist und bleibt das
    > > problem. solange man keine vernünftige multicore rendering engine hat,
    > wird
    > > das auch so bleiben.
    >
    > Also ich hab neulich auf meinem Intel mit ner 30er Raid locker 50 fps / s
    > gehabt. Selbst ohne Magic Touch Erweiterung. Nur ab 45 Priest wurde es dann
    > ein bißchen eng. Ich denke nicht, dass das an multicore liegt. Schließlich
    > hat der i7 ne Rendering Engine vom feinsten!

    Don´t kow if troll or flame in disguise

    EnemyArea hat schon grundsätzlich recht mit der Aussage, dass WoW in bestimmten Situationen CPU-limitiert ist. Das liegt aber v.a. an der grausigen Umsetzung einer Multi-Core-Unterstützung seitens WoW, bei der gefühlt 80% der Arbeit von einem Kern gemacht wird, während die anderen fröhlich weiter ideln. Natürlich sorgt hier auch ne dickere CPU für Abhilfe, weil meist auch der Basistakt steigt und der Löwenanteil somit besser durch einen Kern verarbeitet werden kann. Ob da jetzt ne CPU-schonendere API oder einfach eine Aufarbeitung seitens der Entwickler mehr bringen würde, wäre interessant zu erfahren.

  11. Re: Wenn die CPU limitert

    Autor: Satan 14.08.14 - 16:52

    Naja, die Kerne können auch mehrmals pro Sekunde ihren Takt wechseln. Natürlich ist das alles Mist und bringt nur Nachteile. Aber spätestens, wenn 2-3 Threads *existieren* und ab und zu mal rechnen wollen, gleichzeitig aber Kerne in den Schlafmodus geschickt werden, gibt es Konflikte beim Scheduling - so etwas passiert recht häufig, da verteilt sich die Last auch gerne mal recht gleichmäßig auf sechs Kerne.

    Ganz gut beobachten kann man das auch am Brainfuck-Scheduler unter Linux. Der ist in der Hinsicht nicht gut optimiert, hat aber andere Vorteile. KDE-Desktop mit ner Hintergrund-Last von vielleicht 2, 3% und nen Single Thread-Task wie ein FLAC-Encoding und schon hopst letzterer munter zwischen den Kernen hin und her, bevorzugt zwischen den ersten beiden.



    1 mal bearbeitet, zuletzt am 14.08.14 16:56 durch Satan.

  12. Re: Wenn die CPU limitert

    Autor: Eheran 14.08.14 - 17:30

    >so etwas passiert recht häufig
    Bei mir muss der Kern 2000ms warten, bevor er einen p-state runter schalten darf.
    Ich kann dir daher versichern, dass es nicht daran liegt.
    Und würde der Thread auch nur wenige ms brauchen für den Wechsel von Kern zu Kern (und damit für einen Zyklus durch alle 4 Kerne entsprechend *4), dann würde ich die Ausschläge in der CPU-Auslastung der einzelnen Kerne beobachten können. Sie sind aber solide bei den ~30% ganz ohne Ausschläge.

    Wie gesagt:
    > Egal wie rum - das macht keinen Sinn.

  13. Re: Wenn die CPU limitert

    Autor: Quantium40 14.08.14 - 17:53

    Eheran schrieb:
    --------------------------------------------------------------------------------
    > Ja, aber wenn das geht, wieso dann noch die Limitierung auf 25%?

    Der Taskmanager zeigt nunmal nur Durchschnittswerte über sein Meßintervall an.
    Bei einem 4 Kerner, der einen Prozess hat, der 100% Rechenleistung eines Kernes benötigt, wird dieser Prozess aber ständig von Kern zu Kern verschoben, so daß man statt 1x100% und 3x0% dann bei 4x25% Auslastung landet.
    Man kann aber entsprechende Prozesse auch z.B. mit Hilfe des Taskmanagers auf einen bestimmten Kern festpinnen - dann entfällt die Rumspringerei von Kern zu Kern und man hat ohne Leistungseinbußen ein realistischeres Bild der Prozessorlast.
    Für die Hardware besser ist es allerdings, wenn man den Scheduler den Prozess regelmäßig umquartieren lässt. Dadurch ist die Wärmeerzeugung auf dem Die besser verteilt, was der Lebensdauer der CPU zugute kommt.

  14. Re: Wenn die CPU limitert

    Autor: Eheran 14.08.14 - 18:30

    Da der Thread mind. 4x pro Sekunde den Kern wechselt schont das die CPU nicht im geringsten, da keiner der Kerne so schnell runter taktet.

    Wie schnell takten denn die aktuellen CPUs hoch und runter, dass das dort Vorteile bringt?

  15. Re: Wenn die CPU limitert

    Autor: nille02 14.08.14 - 20:10

    DooMMasteR schrieb:
    --------------------------------------------------------------------------------
    > Dann mag daraus ja auch ein FPS gwinn entstehen, aber die CPU ürfte heute
    > in den seltensten Fällen limitierender Faktor sein.

    Bei den Mantle Benchmarks, sieht man auch einen Übertatketten i7 als leicht limitierend.

    Nur in Szenarien wo die GPU überfordert war, brachte Mantle nichts mehr.

    Ich hoffe mal, dass AMD mit Mantle mal Gas gibt und die API von dem HLSL zwang befreit und Intel mit ins Boot holt.

    Wenn die API unter Windows/Linux dann von AMD, Intel und AMD-FOSS(Linux) unterstützt werden sollte, muss Nvidia irgendwann nachziehen.

  1. Thema

Neues Thema


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. Anforderungsmanager (m/w/d)
    Volkswagen AG, Wolfsburg
  2. Team Lead Service Delivery Management (m/w/d)
    operational services GmbH & Co. KG, Frankfurt am Main
  3. Entwickler Full Stack (m/w/d)
    STEMMER IMAGING AG, Puchheim
  4. Gruppenleitung Geoinformatik (m/w/d)
    Bundesgesellschaft für Endlagerung mbH (BGE), Peine

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Spieleentwicklung: Editorial trifft Engine bei Ubisoft
Spieleentwicklung
Editorial trifft Engine bei Ubisoft

Newsletter Engines Der oberste Game Designer von Ubisoft hat mit Golem.de über Engines gesprochen. Und: aktuelle Engine-News.
Von Peter Steinlechner


    LoRa-Messaging mit Meshtastic: Notfallkommunikation für Nerds
    LoRa-Messaging mit Meshtastic
    Notfallkommunikation für Nerds

    Ins Funkloch gefallen und den Knöchel verstaucht? Mit Meshtastic lässt Hilfe rufen - ganz ohne Mobilfunk, LAN oder WLAN.
    Eine Anleitung von Dirk Koller


      Arbeit in der IT: Depression vorprogrammiert
      Arbeit in der IT
      Depression vorprogrammiert

      ITler unterschätzen oft mentale Probleme. Dabei bietet gerade ihre Arbeitswelt einen Nährboden für Depressionen und Angstzustände.
      Ein Feature von Andreas Schulte

      1. IT-Arbeit Zwei Informatikstudien und immer noch kein Programmierer
      2. Fairness am Arbeitsplatz "Das Gehalt ist ein klares Kriterium für Gerechtigkeit"
      3. Work-Life-Balance in der IT Ich will mein Leben zurück