1. Foren
  2. Kommentare
  3. Games
  4. Alle Kommentare zum Artikel
  5. › CD Projekt Red: PC-Systemanforderungen…

CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

  1. Thema

Neues Thema Ansicht wechseln


  1. CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: dragnod0 20.09.20 - 11:02

    Der Unterschied zwischen einem Ryzen 3 3200U und einem Ryzen 7 2700X ist aber schon ziemlich enorm.
    Schon allein weil der 3200U ganze 6(!) echte Kerne weniger hat als der 2700X.

    Manchmal frage ich mich wie Entwickler auf solche Empfehlungen (3200U als Empfohlen) kommen.

    Aber interessant das jetzt immer öfters AMD CPUs genannt werden und nich mehr Intel.

  2. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Impergator 20.09.20 - 11:11

    G, nicht U :)
    Der hat 4 Kerne.

  3. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: gorsch 20.09.20 - 11:27

    Der 3200G (nicht U) hat aber vergleichbar hohe Single-Thread Performance wie der 2700X.

    https://cpu.userbenchmark.com/Compare/AMD-Ryzen-7-2700X-vs-AMD-Ryzen-3-3200G/3958vsm824486

    Also nur ein geringer Unterschied, bis hoch zu vier Threads.

    Entwickler können nunmal nicht beliebig Sachen in mehrere Threads auslagern, bzw. es ist sinnlos, wenn sich zu viele Threads gegenseitig ausbremsen, weil sie sich um Zugriff auf die gleichen Daten streiten.

    Dass das jetzt wegen "Protesten in der Community" geändert wurde, ist absurd.

  4. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Vanger 20.09.20 - 12:14

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Der 3200G (nicht U) hat aber vergleichbar hohe Single-Thread Performance
    > wie der 2700X.

    Die Single-Core-Performance wird tatsächlich der Knackpunkt sein und der Grund für die doch sehr kuriose Auswahl des Ryzen 3200G.

    > cpu.userbenchmark.com

    Oh Gott, UserBenchmarks... Bitte nicht mehr diese Seite benutzen m(

    > Entwickler können nunmal nicht beliebig Sachen in mehrere Threads
    > auslagern, bzw. es ist sinnlos, wenn sich zu viele Threads gegenseitig
    > ausbremsen, weil sie sich um Zugriff auf die gleichen Daten streiten.

    Das ist eine Tautologie im Stile von "Wenn es regnet, dann regnet es". Natürlich lässt sich die Arbeit nicht auf beliebig viele Threads verteilen... Die Frage ist ob sich die Arbeit sinnvoll auf heute übliche Multi-Core-Prozessoren aufteilen lässt - und da ist die Antwort klar: Ja, selbst auf 16 Kerne / 32 Threads lässt sich die Arbeit sinnvoll aufteilen. Der Zusammenhang ist nur nicht linear, 16 Kerne liefern bei einer nicht limitierenden Grafikkarte gegenüber 8 Kernen nicht die doppelten FPS. Wenn ein Spiel nun eine überproportional höhere Single-Core-Leistung gegenüber der insgesamt zur Verfügung stehenden Multi-Core-Leistung erfordert ist das ein Zeichen für schlechte Programmierung. Der Ryzen 3200G ist so eine CPU bei der das auseinander läuft.

    > Dass das jetzt wegen "Protesten in der Community" geändert wurde, ist
    > absurd.

    Einfach eine andere CPU als Referenz zu nennen ist natürlich absurd. Die Proteste der Community bezogen sich aber eher darauf, dass die Entwickler besseres Multithreading implementieren und die andernfalls brach liegenden Leistung nutzt.

  5. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: gorsch 20.09.20 - 16:02

    > Ja, selbst auf 16 Kerne / 32 Threads lässt sich die Arbeit sinnvoll aufteilen. Der Zusammenhang ist nur nicht linear, 16 Kerne liefern bei einer nicht limitierenden Grafikkarte gegenüber 8 Kernen nicht die doppelten FPS.

    Das Stichwort ist "sinnvoll". Für viele Probleme existiert kein sinnvoller paralleler Algorithmus. Klar kannst du Jobsysteme haben, die Arbeit in Pakete aufteilen, und auf mehreren Threads abarbeiten. Ist halt nur Unsinn, weil sich dann mehrere Threads gegenseitig auf die Füße trampeln und alles am Ende ineffizienter ist, als eine Single-Thread Implementierung. Aber Hauptsache alle Cores sind auf dem Task Manager ausgelastet, damit die Leute mit ihren Drölf-Core Systemen nicht meckern...

    Alternativ hat man spezifische Threads, die spezifische Aufgaben übernehmen, wo der Cache warm bleibt, weil nicht ständig der ganze Kontext über den Haufen geworfen wird und weil nicht dauernd synchronisiert werden muss. Stichwort: Lokalität.

    > Wenn ein Spiel nun eine überproportional höhere Single-Core-Leistung gegenüber der insgesamt zur Verfügung stehenden Multi-Core-Leistung erfordert ist das ein Zeichen für schlechte Programmierung.

    Tja, das stimmt halt einfach nicht. Sowas gilt nur für "embarassingly parallel" Probleme, und dazu zählen Videospiele nicht, dafür gibt es einfach zu viele Datenabhängigkeiten.

    > Die Proteste der Community bezogen sich aber eher darauf, dass die Entwickler besseres Multithreading implementieren und die andernfalls brach liegenden Leistung nutzt.

    Ja, die gleichen Entwickler die ein bisher nicht dagewesenes System zur Darstellung einer riesigen, lebendigen Welt gebaut haben, müssen sich von den "Experten" in der Community anhören lassen dass sie doch "einfach" besseres Multithreading nutzen sollen, obgleich das in der Softwareentwicklung eines der schwierigsten Problem überhaupt ist.



    1 mal bearbeitet, zuletzt am 20.09.20 16:12 durch gorsch.

  6. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Sharra 20.09.20 - 18:18

    Schönes Beispiel ist der neue MS Flight Simulator. Der limitiert alles über den Primärkern.
    Theoretisch könnte man diese Arbeiten auf mehrere Kerne aufteilen, und einen zusätzlichen Kern zur Koordinierung benutzen. Wenn man sowieso 32 Kerne zur Verfügung hat, sind genug dafür übrig.
    Aber das ist nur die graue Theorie. Am Ende hat man Microstuttering, weil eben die Koordinierung und die Verteilung eben nicht 100% flüssig läuft. Das stört das Spielerlebnis deutlich stärker als wenn die gesamte Simulation mit weniger Frames pro Sekunde abläuft.

  7. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Vanger 20.09.20 - 18:50

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Das Stichwort ist "sinnvoll". Für viele Probleme existiert kein sinnvoller
    > paralleler Algorithmus.

    Wieder so wunderbar unbestimmt: "viele Probleme". Für "viele Probleme" existieren sehr wohl sinnvolle parallele Algorithmen. So, und jetzt?

    Recht hast du damit, dass viele seit langer Zeit in der Spielentwicklung etablierte Algorithmen tatsächlich wenig Parallelisierung erlauben - eben weil sie unter der Prämisse entwickelt wurden auf einem Core möglichst performant ein Problem zu lösen. Womit du aber absolut Unrecht hast ist, dass es keine Algorithmen gäbe mit denen das gleiche Probleme nicht auch unter Nutzung starker Parallelisierung effizienter zu lösen wäre. Sie werden nur nicht eingesetzt.

    Wieso werden diese Algorithmen nicht eingesetzt? Zum einen weil sie schlicht weniger verbreitet sind - dass die Zahl der Cores explodiert ist noch eine sehr neue Entwicklung. Zum anderen weil sie häufig nur bei vielen Cores schneller sind, bei wenigen Cores z.T. aber deutlich langsamer. In der Regel muss sich der Entwickler aber für einen Algorithmus entscheiden. Entsprechend ist das nicht nur ein Know-how-Problem der Entwickler, sondern auch schlicht eine Abwägung welche Plattformen noch unterstützt werden sollen. Gerade Intel blockiert hier den Fortschritt. Dass diese Entscheidung häufig nicht mal vom Spielentwickler sondern vom Entwickler der Engine getroffen wird, die ein noch viel größeres Interesse daran hat auf möglichst vielen Plattformen gute Ergebnisse zu liefern, macht das Ganze nicht besser.

    > Ja, die gleichen Entwickler die ein bisher nicht dagewesenes System zur
    > Darstellung einer riesigen, lebendigen Welt gebaut haben

    Oh Gott, wie ich solche Aussagen liebe... Welch ein Unsinn, als hätte das eine mit dem anderen etwas zu tun. In der Regel sind dafür sogar komplett unterschiedliche Teams verantwortlich. Aber dazu müsste der "Experte" in der Community ja was von der Thematik verstehen...

  8. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: gorsch 20.09.20 - 19:18

    > Wieder so wunderbar unbestimmt: "viele Probleme". Für "viele Probleme" existieren sehr wohl sinnvolle parallele Algorithmen. So, und jetzt?

    Was erwartest du jetzt von mir, dass ich dir die Liste der Probleme, die ein Spiel wie Cyberpunk 2077 löst, stichpunktartig aufzähle und dann für jedes Problem individuelles Assessment der Parallelisierbarkeit gebe, um dann nach Amdahl's Gesetz den maximalen Speedup zu errechnen?

    > Wieso werden diese Algorithmen nicht eingesetzt? Zum einen weil sie schlicht weniger verbreitet sind - dass die Zahl der Cores explodiert ist noch eine sehr neue Entwicklung.

    Ach komm, seit fast acht Jahren haben die Konsolen acht Kerne mit geringer Single-Core Performance. Wenn "alles multithreaden!" sinnvoll wäre, dann würden die Entwickler das auch machen.

    > Zum anderen weil sie häufig nur bei vielen Cores schneller sind, bei wenigen Cores z.T. aber deutlich langsamer.

    Ja, also quasi genau mein Punkt: Ineffizient und somit *nicht sinnvoll*. Es geht hier ja nicht nur um einzelne Algorithmen, sondern um eine ganze Architektur.
    Soll man das jetzt alles zweimal schreiben, einmal für die Leute die einen normalen PC haben, und dann nochmal für die 1%, die dann mit einem 16-Kerner 10% mehr Performance rausholen können?

    Mit dedizierten Threads sparst du dir Unmengen von Synchronisation. Und die Sachen, die trivial parallel sind, kannst du ja trotzdem auf mehreren Threads machen. Damit hast du die effizienteste Lösung, auch wenn dann nicht alle Cores immer zu 100% ausgelastet sind. Auf mobilen Geräten willst du ja auch nicht sinnlos die Batterie leer lutschen, und auf den neuen Konsolen wird auch das Power-Budget relevant.

  9. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Vanger 20.09.20 - 22:14

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Ach komm, seit fast acht Jahren haben die Konsolen acht Kerne mit geringer
    > Single-Core Performance. Wenn "alles multithreaden!" sinnvoll wäre, dann
    > würden die Entwickler das auch machen.

    Es ist ja allgemein bekannt, dass du von der Spielentwicklung mehr verstehst als Microsoft, Sony und AMD, entsprechend wurden vollkommen ungeeignete Konsolen gebaut. Eigentlich ein Wunder, dass es überhaupt aktuelle Spiele für die Konsolen gibt... Eigentlich dürfte es die nicht geben.

    Ich sprach im übrigen vom PC.

    > Ja, also quasi genau mein Punkt: Ineffizient und somit *nicht sinnvoll*.

    Ein hochgradig parallelisierter Algorithmus wird per Definition auf einer nicht zu echter Parallelisierung fähigen Hardware ineffizient ausgeführt. Den Schluss, den du daraus ziehst, ist aber kompletter Unsinn. Parallelisierte Algorithmen, die auf zu Parallelisierung fähiger Hardware ausgeführt werden, erledigen die Arbeit in der Regel weitaus ressourceneffizienter als ein nicht parallelisierter Algorithmus. Das hat einfach den Grund, dass ein nicht parallelisierter Algorithmus irgendwann an die Grenzen des Cores stößt - oder was glaubst du ist der Grund weshalb die Taktraten seit Jahren relativ konstant bleiben und vorrangig Takteffizienz und Core-Zahl gesteigert werden? Weil die Ingenieure keine Ahnung haben? Nein, weil Parallelisierung irgendwann als einzige Option übrig bleibt...

    > Soll man das jetzt alles zweimal schreiben, einmal für die Leute die einen
    > normalen PC haben, und dann nochmal für die 1%, die dann mit einem
    > 16-Kerner 10% mehr Performance rausholen können?

    Wer heute noch einen Quad-Core für Gaming kauft ist selbst Schuld. Das Problem ist Intel, die dank ihrer vollkommen veralteten Technik noch immer Quad-Cores in den Markt pumpen... Wir könnten da schon viel weiter sein.

    Dass 16-Kerner eine nur stark unterproportional höhere Leistung zeigen liegt an auf Single-Core-Performance ausgelegten Spielen, nicht daran, dass Parallelisierung nicht möglich sei. Bis heute wird Arbeit nur als Einheit auf Cores verteilt, selten Arbeit tatsächlich parallelisiert - obwohl das möglich wäre und, zu Parallelisierung fähiger Hardware vorausgesetzt, auch deutlich ressourceneffizienter wäre als die Single-Core-Leistung zu steigern. Schau dir doch einfach an welche absurden Power-Limits Intel inzwischen benötigt um die Single-Core-Leistung weiter zu steigern - und das nur um AMD überhaupt noch irgendwas entgegensetzen zu können weil sie dank ihrer veralteten Technik nicht in der Lage sind kosteneffizient die Core-Zahl zu steigern.

    > Damit hast du die effizienteste Lösung, auch wenn dann
    > nicht alle Cores immer zu 100% ausgelastet sind. Auf mobilen Geräten willst
    > du ja auch nicht sinnlos die Batterie leer lutschen, und auf den neuen
    > Konsolen wird auch das Power-Budget relevant.

    Jetzt müsstest du nur noch verstanden haben, dass zwei Cores mit niedrigem Takt weitaus energieeffizienter arbeiten als ein einzelner Core mit höheren Takt...

  10. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: gorsch 20.09.20 - 23:33

    > Es ist ja allgemein bekannt, dass du von der Spielentwicklung mehr verstehst als Microsoft, Sony und AMD, entsprechend wurden vollkommen ungeeignete Konsolen gebaut.

    Dass Hardwarehersteller für die Spielentwicklung eher ungeeignete Geräte designen, hat eine lange Tradition. Die haben nämlich die gleichen Illusionen, was Entwickler so alles mit der Hardware anstellen können, wenn sie nur "genug optimieren". Siehe CELL PPEs (kaum genutzt) und XDR-Speicher (umständlich) auf der PS3 oder EDRAM + DDR (zu klein + zu langsam) auf der Xbox One.

    Was die CPUs auf aktuellen Konsolen angeht, das hatte eher ökonomische Gründe: AMD konnte zu der Zeit noch keine Zen Cores liefern und Bulldozer war ungeeignet gewesen und Jaguar war nicht für hohe Frequenzen ausgelegt. Intel wäre zu teuer gewesen, PPC war weit abgeschlagen und ARM noch nicht auf dem Level, wo es heute ist.

    Es ist aber ja nun kein Zufall, dass die aktuelle Konsolengeneration die gleiche Anzahl Kerne hat (für Abwärtskompatibilität), aber dafür eine viel höhere Frequenz - eben weil mehr Kerne nicht sinnvoll sind.

    > Eigentlich ein Wunder, dass es überhaupt aktuelle Spiele für die Konsolen gibt... Eigentlich dürfte es die nicht geben.

    Nein, die Konsolenspiele sind halt nur limitiert, in dem was sie machen können.

    > Ein hochgradig parallelisierter Algorithmus wird per Definition auf einer nicht zu echter Parallelisierung fähigen Hardware ineffizient ausgeführt...

    Viele Algorithmen bzw. Datenstrukturen sind aber eben *nicht* hochgradig parallelisierbar, weil es Synchronisationpunkte braucht (Locks) oder weil andere Mechanismen, die die Datenintegrität gewährleisten (Atomics) Overhead haben. Außerdem sind sie komplizierter zu implementieren.

    Und wie gesagt, man muss die gesamte Architektur betrachten. Wenn du vier Kerne hast und jeder führt für sich eine Aufgabe durch, ganz ohne Synchronisierung, dann ist das wahrscheinlich schneller, als wenn du irgendwas parallel machst, was jede Menge Synchronisation braucht, wie eben ein Job-System. Du wirst es nur nicht wissen, weil du nicht beide Systeme implementierst, um sie zu vergleichen.

    > Dass 16-Kerner eine nur stark unterproportional höhere Leistung zeigen liegt an auf Single-Core-Performance ausgelegten Spielen, nicht daran, dass Parallelisierung nicht möglich sei.

    Ja, wie gesagt, sinnlose Parellelisierung ist möglich (Job Systeme). Manche Spiele-Entwickler haben das ja auch versucht. Es ergibt aber doch keinen Sinn, dass selbst in den Zeiten von Quad und Octacores viele Spiele immernoch durch *einen* Core limitiert werden, wenn das alles einfach so sinnvoll parallelisiert werden könnte. Die Probleme, die einfach parallelisiert werden könnten, sind es bereits. Das sind aber nicht 100%, demenstprechend siehst du auch nicht 100% Auslastung im Task-Manager.

    Wenn deine Vorstellungen zutreffen würden, dann wären doch Architekturen wie Larrabee/Xeon-Phi das Erfolgsmodell gewesen. Mehr Kerne in die Hardware zu bringen ist ja einfacher, als den Takt zu erhöhen. Sind die Entwickler wirklich alle durch die Bank weg derart unfähig und faul?

    > Jetzt müsstest du nur noch verstanden haben, dass zwei Cores mit niedrigem Takt weitaus energieeffizienter arbeiten als ein einzelner Core mit höheren Takt...

    Ich bin jetzt zwar von "höchstmöglicher" Frequenz ausgegangen, aber wenn du mit zwei niedrig getakteten Kernen sinnlosen Overhead bedienst anstatt mit einem hochgetakteten Kern nur das Notwendige zu berechnen, dann ist das nicht unbedingt effizienter.

  11. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Dystopinator 21.09.20 - 07:49

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Sind die Entwickler wirklich alle durch die Bank weg derart unfähig und faul?

    Es gibt sicher ausnahmen welche die Regel bestätigen, nur die bestimmen nicht was geht und was nicht ... es geht ja auch bzw. vor allem darum wettbewerbsfähige Ergebnisse möglichst bald vorzeigen zu können und nicht ewig unverkäufliches abzuliefern.

  12. Mehr Kerne: gut

    Autor: yumiko 21.09.20 - 10:11

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Das Stichwort ist "sinnvoll". Für viele Probleme existiert kein sinnvoller
    > paralleler Algorithmus. Klar kannst du Jobsysteme haben, die Arbeit in
    > Pakete aufteilen, und auf mehreren Threads abarbeiten. Ist halt nur Unsinn,
    > weil sich dann mehrere Threads gegenseitig auf die Füße trampeln und alles
    > am Ende ineffizienter ist, als eine Single-Thread Implementierung. Aber
    > Hauptsache alle Cores sind auf dem Task Manager ausgelastet, damit die
    > Leute mit ihren Drölf-Core Systemen nicht meckern...
    Das ist doch zu kurz gedacht - kein Programm existiert im datenleeren Raum auf dem PC.
    Zum einen sind die Spiele alleine schon durch die XBox One und PS4 seit 2013 daran gewohnt bis zu 7 Kerne exklusiv zu nutzen (die Engines skalieren in einigen Aufgaben entsprechend bzw. verteilen die einzelnen Aufgaben).
    Zum anderen macht es sehr wohl eien Unterschied auf dem PC, ob die wenigen Kerne nicht nur das Spiel, sondern auch noch hunderte OS-Prozesse sowei Browser/Temspeak/Discord usw. bewirtschaften müssen. Bei vielen Kernen bekommen die zum Speil gehörigen nahezu exklusiven Zugriff - und können hier jeweils die vorhandene IPC ausreizen. Daher kommt auch die ursprüngliche Aussage "mehr Kerne bringen messbar etwas".

  13. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: gorsch 21.09.20 - 10:20

    Ist schon klar, aber mehrere Cores sinnvoll auszunutzen ist doch ein Wettbewerbsvorteil. Wenn es also nur *theoretisch* machbar ist, weil es mit zu viel Aufwand verbunden ist, dann kann man den Entwicklern auch nicht vorwerfen, es nicht zu machen. Dann kann man nicht von "schlecht programmiert" reden, wenn letztlich niemand das erreicht, was den Forenexperten mit ihren Drölfcores in der Fantasie so vorschwebt.

  14. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: wurstdings 21.09.20 - 13:30

    Paralellisierung bei Spielen wäre eigentlich sehr gut machbar das Problem ist aber, das es extrem schwierig ist sowas fehlerfrei zu implementieren und im Fehlerfall ist die Suche nach dem Fehler ungleich aufwändiger als bei Singlethread.

    Aus genau diesem Grund hat Mozilla damals Rust entwickelt, um Dinge zu paralelisieren ohne dabei grobe, unlösbare Fehler zu erzeugen.

  15. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Prypjat 21.09.20 - 13:30

    dragnod0 schrieb:
    --------------------------------------------------------------------------------
    > Manchmal frage ich mich wie Entwickler auf solche Empfehlungen (3200U als
    > Empfohlen) kommen.

    Nicht empfohlen, sondern minimal.
    Das heißt, dass so ziemlich alles an Grafiverbesserung deaktiviert ist und das Spiel mit dieser CPU unter FHD trotzdem noch gut arbeiten kann.

    Dieser Fakt ist nicht unerheblich. Es gibt viele Zocker, die nur einen Laptop haben und die dürften froh sein, dass die CPU das noch stemmen kann.

    Ich verstehe auch die Aufregung nicht.
    Mein Rechner liegt irgendwo zwischen den Minimalen- und den Empfohlenen Systemanforderungen. Was schert mich also, dass im Minimum der 3200G angegeben wird?
    Und wenn das Spiel auf Zwieback laufen würfen, wäre es auch egal.
    Hab ich eben Keks aufm Board und kein Zwieback. Hauptsache das Spiel schmeckt mir am Ende.

  16. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: yumiko 21.09.20 - 15:42

    gorsch schrieb:
    --------------------------------------------------------------------------------
    > Es ist aber ja nun kein Zufall, dass die aktuelle Konsolengeneration die
    > gleiche Anzahl Kerne hat (für Abwärtskompatibilität), aber dafür eine viel
    > höhere Frequenz - eben weil mehr Kerne nicht sinnvoll sind.
    Das stimmt so nicht. Durch das SMT (gerne "virtuelle Kerne" genannt) kommt man auf dem PC auf Steigerungen von bis zu 20% (Spiele) und 70% (Berechnungen).
    Inwieweit man das "manuell" als Entwickler auf Konsolen nutzen kann ist schwer zu sagen, aber bei PCs durch die häufigen Task-Wechsel sind die quasi Gold wert.

  17. Re: CPU Angabe mit krassem Unterschied (R. 3 vs R. 7)

    Autor: Andrej553 21.09.20 - 16:46

    Bei The Witcher 3 haben sie Multiprocessing doch ganz gut hinbekommen. Zumindest mein Phenom II x6 wurde damals durchweg ausgelastet.

  1. Thema

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. EnBW Energie Baden-Württemberg AG, Köln
  2. Schaeffler Digital Solutions GmbH, Chemnitz
  3. ALTE LEIPZIGER Lebensversicherung a. G, Oberursel
  4. KWS SAAT SE & Co. KGaA, Einbeck

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Mobile-Angebote
  1. Apple iPad Air 10,9 Zoll Wi-Fi 64GB für 632,60€, Apple iPad Air 10,9 Zoll Cellular 64GB für 769...
  2. 274,49€ (mit Rabattcode "PFIFFIGER" - Bestpreis!)
  3. 689€ (mit Rabattcode "PRIMA10" - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de