Ich schaue mal in meine persönliche Glaskugel und diese sagt mir, dass zukünftig immer Software mehrere Kerne unterstützen wird. Warum auch nicht, Single Core Leistung kann man kaum mehr erhöhen, dazu gibts mehr Kerne und die Software dafür muss sich auch anpassen. Wenn man das Geld dazu hat, würde ich definitiv keinem mehr einen 4er empfehlen. Wenn man die CPU jährlich wechselt ist das was anderes, aber der Vorteil am neuen AM4 Sockel ist, dass es so schnell keinen Wechsel geben wird, perfekt um Das Board und die CPU auch länger zu behalten.
AMD zeigt Zen-Architektur auf der Computex
- Ersteller Don
- Erstellt am
DragonTear
Legende
Weil dies Softwareentwickler vor zusätzliche Herausforderungen stellt, entsprechend wird das nur umgesetzt wenn es auch lohnt. Das wird auch weiterhin nicht immer der Fall sein...
DerGoldeneMesia
Enthusiast
- Mitglied seit
- 21.05.2007
- Beiträge
- 4.439
was bei den smartphones zu klappen scheint, würde mich nicht über 16Kerne im smartphone wundern.
Zuletzt bearbeitet:
mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.420
Ich denke Summit Ridge wird es mit 4, 6 und 8 Kernen geben. Ähnlich wie das bei Orochi mit FX4, FX6 und FX8 gehandhabt wurde. 6-Kern Zens sind natürlich schon eine Option, nämlich indem man jeweils einen Kern in einem 4-Kern Block deaktiviert.
- - - Updated - - -
Ob man mit SMT Performance gewinnt oder gar verliert hat weniger damit zu tun, auf wie viele Kerne optimiert wird. Für gewöhnlich optimieren Anwendungen auch nicht auf eine bestimmte Anzahl an Kernen. Die nehmen einfach was sie kriegen können. Ob man mit SMT Performance gewinnt oder gar verliert liegt vor allem daran, wie gut die Ausführungseinheiten bereits mit einem Thread ausgelastet werden. Sind die Ausführungseinheiten nur mager ausgelastet, gibt's freie Ressourcen für weitere Threads. Ergebnis, mehr Performance. Sind die Ausführungseinheiten hingegen bereits ziemlich stark ausgelastet, gibt's keine freie Ressourcen mehr oder es kommt gar zu Ressourcenkonflikten. Ergebnis, Performance stagniert und verringert sich gar.
Im Laufe der Zeit hat Intel die Ausführungseinheiten aufgestockt, mit Haswell kamen sogar zwei zusätzliche Pipes (insgesamt 8) hinzu. Die Chance für stagnierende Performance oder gar Ressourcenkonflikte wurde also gesenkt. Zen soll ja 10 Pipes besitzen (6 Integer + 4 FP). SMT könnte dort sogar noch etwas besser skalieren.
Soviel ich weiß unterstützen die meisten leistungshungrigen Programme, die auch etwas Geld kosten Multicores. Bei Spielen wirds doch oft dann schon in die Engine integriert (UE4 zB) was das ganze in Zukunft einfacher gestaltet, deswegen werde ich definitiv auch zum 8 Core mit SMT greifen, bevor ich zu einem 6700k greife. So lange wirds nicht mher dauern bis mehr als 4 Kerne (vor allem in Spielen) optimal ist, dass es Word nicht benötigt ist allerdings klar
Was aber auch bedeutet das der 6 Kerner eher das Abfallprodukt eines defekter 8 Kerners ist und Designtechnisch keinerlei Vorteile bietet ohne eigenes Layout. Wenn ich mir vorstelle das noch ausgerechnet die äusseren Kerne "defekt" sind und dann als 6 Kerner verkauft wird...
DragonTear
Legende
Woran siehst du dass das klapppt?
Kaum was auf Samsungs 8kern Smartphones läuft schneller als auf den Vierkernern und Apple hat so ziemlich das beste Feeling in Sachen Responsivity trotz nur Zweikernern...
Soviel ich weiß unterstützen die meisten leistungshungrigen Programme, die auch etwas Geld kosten Multicores. Bei Spielen wirds doch oft dann schon in die Engine integriert (UE4 zB) was das ganze in Zukunft einfacher gestaltet, deswegen werde ich definitiv auch zum 8 Core mit SMT greifen, bevor ich zu einem 6700k greife. So lange wirds nicht mher dauern bis mehr als 4 Kerne (vor allem in Spielen) optimal ist, dass es Word nicht benötigt ist allerdings klar
Die professionellen Programme wie für CAD, Rendering o.ä. erzeugen zufällig sehr generische Last welche sich gut parallelisieren lässt. Der Gegenpol sind Anwendungen die in Echtzeit reagieren müssen und aus mehr Einzelkomponenten bestehen - allen Vorran sind das Games.
Zudem ist auf 8 Kerne nochmals deutlich schwerer sowas zu optimieren als auf 4 Kernen.
Eine Hoffnung ist natürlich DX12 da dies zumindest den Renderpfad einfacher paralelisieren lässt. Für die Gamelogik beibt allerdings alles beim Alten.
NasaGTR
Enthusiast
- Mitglied seit
- 12.05.2013
- Beiträge
- 7.883
Und genau das ist der Grund warum Bohemia zum Glück eingesehen hat dass DirectX 12 für Arma 3 nichts mehr bringt^^
mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.420
War bei FX6 und FX4 doch nicht anders. Ist bei i5 und Pentium/Celeron auch nicht anders. Der Vorteil ist halt, dass es solche Modelle teils deutlich preisgünstiger gibt.
angelsdecay
Enthusiast
es wird keine quads geben mit Zen
Dafür gibt es die apu
Dafür gibt es die apu
Im Grunde gibt es kein "unterstützen Multicores".
Software wird Multithreaded programmiert. Das IST gängige Praxis und nicht erst seit heute oder gestern so.
Schon die simpelsten Sachen werden Multithreaded ausgelegt. Warum? Weil nicht nur der reine (potentielle) Speed durch gleichzeitige Ausführung ein "Vorteil" davon ist, sondern auch bspw. das Abtrennen der Aufgaben voneinander ein Nebeneffekt. Stell dir vor, du willst von einem optischen Datenträger Daten lesen und die Software würde ALLE Arbeit nur ein einem einzigen Thread abarbeiten -> während der Zeit, wie der Datenträger andreht, das Filesystem gelesen wird usw. steht deine GUI. Das "nervt" als Anwender schon nach wenigen Sekunden Stillstand (ein Windows würde dir dann in der Zeit ein "no response" zurückliefern, das GUI Bild mit einem weißen/grauen Schatten überziehen und dem Anwender suggerieren, die GUI sei abgeschmiert)
Unterm Strich ist sowas nicht mehr zeitgemäß, also trennt man in so ziemlich jeglicher halbwegs durchdachter Software mindestens mal GUI von den Workern im Background (also der eigentlichen Berechnung)
Einen Leistungsvorteil hast du dadurch aber schlicht nicht... Es fühlt sich nur einfach "besser" an. Bspw. schon das simple Open Dialog Fenster, was in Windows auch standardisiert genutzt werden kann (.Net bspw.) agiert schon mit mehr wie zwei Threads bei Nutzung.
Auch programmiert man idR nicht permanent ALLES von Grund auf neu, sondern bedient sich häufig vorhandener Bibliotheken für Standardzeug. -> sind diese Bibliotheken nun auf MT ausgelegt bzw. nutzen MT, ist die Software es damit grundsätzlich ebenso. Leistung in Form von kürzeren Zeiten bei der Berechnung muss das aber auch hier nicht bedeuten.
Das Problem, was die Leute in den Foren schlicht nicht verstehen. Es existiert ein himmelweiter Unterschied zwischen der Nutzung von Multithreading in Software und der gewünschten/erhofften Leistungsskalierung über die CPU Breite. Software kann spielend mit hunderten oder tausenden Threads arbeiten, wenn man das möchte als Programmierer. Das heist lange nicht, dass diese Anzahl von Threads auch gleichzeitig A) Arbeit haben und B) die anfallende Arbeit dadurch schneller geschafft wird.
-> schau einfach mal in deinen Taskmanager, was dir das OS ausspuckt, wenn du schlicht im idle State agierst. Da stehen hunderte, vielleicht sogar tausende aktive! Threads. CPU Load ist nahe Null. Wird dadurch nun Leistung gewonnen?
DragonTear
Legende
Sonne, das hast du schon einige mal hier widerholt :PDas Problem, was die Leute in den Foren schlicht nicht verstehen. Es existiert ein himmelweiter Unterschied zwischen der Nutzung von Multithreading in Software und der gewünschten/erhofften Leistungsskalierung über die CPU Breite. Software kann spielend mit hunderten oder tausenden Threads arbeiten, wenn man das möchte als Programmierer. Das heist lange nicht, dass diese Anzahl von Threads auch gleichzeitig A) Arbeit haben und B) die anfallende Arbeit dadurch schneller geschafft wird.
-> schau einfach mal in deinen Taskmanager, was dir das OS ausspuckt, wenn du schlicht im idle State agierst. Da stehen hunderte, vielleicht sogar tausende aktive! Threads. CPU Load ist nahe Null. Wird dadurch nun Leistung gewonnen?
Du ignorierst aber dass man nunmal was anderes meint. Auch in Informatikfächern an der Hochschule meinen wir mit "diese Software unterstützt Multithreading" eigentlich immer "diese Software leistet auf Mehrkernprozessoren mehr in der selben Zeit.".
Ebenso ist es das womit UE4 u.ä. oder Libraries werben wollen wenn sie dies sagen.
Dass GUI und Aufgaben/Background getrennt voneinander ablaufen, ist inzwischen doch eher eine Selbstverständlichkeit und teils muss man als Entwickler sich nicht mal drum kümmern (z.B. wenn man eine Software mit JavaFX als GUI entwickelt).
Die Begrifflichkeit ist also eher nebensächlich, findest du nicht?
Bzw. fällt dir denn für das Gemeinte, ein besserer Begriff ein? Immer erklären wäre halt umständlich.
Zuletzt bearbeitet:
Klar ist die Begrifflichkeit nebensächlich... Aber es geht doch auch gar nicht um die Begriffe?
Es geht um den Unterschied zwischen der Nutzung von mehreren Threads und der Leistungsskalierung durch mehrere Threads. Da gibts effektiv keinen Begriff oder Floskeln, die man da nennen kann. Es ist schon rein von der Logik her ein Unterschied.
Ich kann mir vier Kaffee Maschinen hinstellen, es kommt trotzdem nicht viermal so viel Kaffee raus, wenn ich immer nur eine einzige davon anschalte.
Ist eigentlich genau so einfach wie es klingt
DragonTear
Legende
Und was spielt dieser Unterschied für eine Rolle wenn jeder, inkl. Programmierer wissen was gemeint ist wenn jemand über dieses Thema spricht?
Zuletzt bearbeitet:
Ich weis nicht, aber so recht kann ich dir nicht folgen??
Offenbar besteht doch klar ein Wissensdefizit, oder woher kommen immer die Annahmen von wegen Software und Multicore und in so und so vielen Monaten/Jahren wird man so viele Cores brauchen usw.?
Oder wie kommst du darauf, dass alle wissen würden was gemeint ist? Woher kommen dann immer diese "Wünsche"?
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.849
Das hängt sehr von der jeweiligen Software ab und es gibt genügend Beispiele wo das nicht so ist oder bis vor gar nicht langer Zeit so war.
Auch da ist meine Erfahrung aus der Praxis eine andere, die meisten Programmierer scheuen Multithreading, weil es schwerer zu handhaben und viel schwerer zu debuggen ist. Außerdem werden natürlich immer lieber bestehen Routinen übernommen oder Bibliotheken genutzt als das Rad neu zu erfinden und da ist vielfach nur alter, uralter bis steinalter Code dabei, der von Multithreading noch gar nichts wusste als er geschrieben wurde, dafür aber bewährt ist, wie Du ja auch selbst schriebst:
Code schreibt man nur neu oder auch Multithreading um, wenn ein Programm wirklich performancekritisch ist und viel Zeit in solche Routinen verbringt. Dann gibt es auch noch die Fälle wo jemand solche alten Code der z.B. wegen seiner globalen Variablen nicht multithreadingfähig ist, dann mal eben mit einem globalen Mutex schützt und dann läuft auch in einem Programm welches mehrere Thread nutzt, an der Stelle immer nur ein Thread durch die Routine.
Eben, zumal zu viele Threads auch mehr Overhead für das Betriebssystem bedeuten und jeder Kontextswitch Zeit kosten, u.a. weil die Cacheinhalten dann ungültig werden, weshalb eben auch viele Programme nachsehen wie viele Threads die CPU verarbeiten kann und sich danach richten und wenn es um Spiele für Konsolen geht bei denen die HW ja immer gleich ist, dürften sich manche das Auslesen der Anzahl an Threads sparen und gleich die Verteilung statisch so vornehmen, dass die Performance optimiert wird und die Threads auch gleich fest an bestimmte Kerne binden, um eben z.B. Kontextswitches zu vermeiden. Auf einem i5 kann ein rechenintensives Programm mit 4 Threads welches kaum auf RAM zugreift und wenig I/O macht dann nicht selten schneller laufen als wenn man 8 Threads starten und so ständige Wechsel zwischen 2 Threads auf einem Kern provozieren würde. Macht das Programm aber öfter Zugriffe auf das RAM oder gar I/O, könnten die Kernauslastung bei 8 Threads diese Nachteile kompensieren, denn wenn der eine Thread auf Daten wartet könnte der andere Thread mit seinen Daten im Cache weiterrechnen und damit hängt es dann auch noch von solchen Faktoren wie der Cachegröße und RAM Geschwindigkeit ab, welches Lösung nun konkret schneller ist. Damit hängt die richtige Antwort mit wie vielen Thread ein Programm am schnellsten läuft also auch vom System ab und geht noch weiter, denn wenn die Daten auf denen die häufig durchlaufenen Schleifen im Programm bei Ausführung nur des einen Programms gerade noch schön in den L3 Cache passen, kann dies mit anderen Daten oder wenn noch ein anderes Programm läuft welches viele Ressourcen möchte, nicht mehr der Fall sein und da geht es eben bis runter zu jeder Schleife in jedem Algorithmus und kann je nach den Parametern und Daten anderes aussehen.
Oder ein anderes Beispiel wie gut gemeint auch mal daneben gehen kann. Wenn ich z.B. eine Imagefilter anwende, was ja eine Sache ist die sich toll parallelisieren lässt indem jeder Thread den Filter auf einen Teil des Images anwendet, so kann ich im Algorithmus natürlich schauen wie viele Threads die CPU verarbeiten kann und starte auch entsprechend viele Threads. Das ganze beschleunige ich nun noch mehr, indem ich die Kontextswitches minimiere und jeden Thread an einen "Kern" festmachen, damit der Scheduler der CPU diese nicht ständig auf andere Kerne verschiebt, was die L1 und meist auch L2 Caches invalid werden lässt und bekomme die beste Performance. Nun steckt die Routine in eine Bibliothek und jedem setzt diese ein, aber ein andere hatte diese Idee mit den Anbinden des Threads seine Algorithmus der nicht parallelisierbar ist auch schon und hat den auch an einen Kern angebunden und im Programm welches diese beiden Routinen nun nutzt laufen vor allem diese beide Algorithmen und das auch noch parallel, so dass ein Kern (Thread) im Grunde immer doppelt so stark belastet wird wie die anderen. Kann es dann erst weiter gehen wenn beide Algorithmen fertig sind, so wird das eigentlich die Performance steigernd feste anpinnen der Threads an die Kerne zur Bremse, denn während die anderen Threads ihren Teil des Bildes längst fertig bearbeitet haben, muss der eine des mit den anderen Algorithmus konkurriert sich mit dem eben ständig den gleichen Kern teilen und wir dann vom Scheduler eben auch nicht auf die nun freien anderen Kerne verschoben, weshalb man gerade in Bibliotheken mit solchen Optimierungen extrem aufpassen muss, weil man eben nicht weiß wie das Programm aussehen wird, welches diese nutzt und wenn das Programm viele Bilder verarbeitet kann es am viel schneller und daher sinnvoller sein die Imagefilter nicht multithreaded zu gestalten und es dem Programm zu überlassen so viele Thread zu öffnen und Images parallel zu verarbeiten, wie die CPU Kerne (Threads) hat. Damit vermindere ich auch den Leerlauf der entsteht, weil nie alle Kerne ihren Teil gleichzeitig abgearbeitet haben, gerade wenn mehrere Imagefilter auf ein Bild angewendet werden, denn da müssen ja erst alle mit einem fertig sein, bevor der nächste angewandt werden kann und dazu eben auch Overhead des OS für den Synchronisierungsaufwand, das Starten und Stoppen von Thread (dies passiert eben nur einmal im Programm und nicht für jeden Filter erneut).
DragonTear
Legende
Es besteht jedenfalls kein Wissensdefinizit bei teiger, an dessen Beitrag du dich ja aufgehangen hast.
Er hat davon geredet das Multicores z.B. in UE4 unterstützt wird und hat damit ebenso die Leistungssteigerung gemeint wie es auch die Entwickler von UE4 meinen die damit werben.
Achso... Na dann zeig uns doch mal diese Leistungssteigerung?
Bist du sicher, dass du schonmal mit dem UE4 Editor gearbeitet hast? Ich glaube nicht Tim...
Natürlich unterstützt der UE4 Editor massiv Multithreading. Das Teil compiliert während der Bearbeitung die Shader auf dem Prozessor. Und da kommen eine ganze Menge viele Berechnungen zusammen, bei aufwendigeren Projekten mehrere tausend/zentausend, das dauert selbst bei meinem 4,2GHz Oktacore noch teils stunden bis es überhaupt ansatzweise losgehen kann. Was hat das mit Games zu tun?
Richtig, NIX... GAR NIX.
Auch du unterliegst einem gewaltigen Irrtum, das ist die Vorwärmphase. Der Editor ist keineswegs mit einem fertigen Game vergleichbar. Denn du bearbeitest dort aktiv Kontent in Echtzeit... Bei Games ist der Spaß vorkompiliert (meistens zumindest) ausgeliefert.
Was meinst du was passiert, wenn du fertig bist mit dem Erstellen und den Spaß einfach mal startest?
-> guck es dir selbst an, es gibt genügend freie Demo Levels im Netz. Die Elemental Demo erzeugt bspw. brachiale Strich! 6% Load auf meinem Prozessor. Das ist runtergebrochen ein Volllastthread. Das feiert dir jeder Dualcore mit SMT auf ner halben Arschbacke ab... Der Schnelltest mit der fixen Zuweisung vom Thread 1 + 2 -> also dem Erzwingen der Last auf einem einzigen Core samt SMT bringt keine Änderungen im FPS Bild -> es klebt im 60 FPS Limit.
EDIT: die Elemental Demo ist übrigens das hier:
https://www.youtube.com/watch?v=E3hXDxyP8nk
Also nicht das jetzt kommt, ich würde hier das billigste vom billigen rauskramen...
Immer dieses Gesabbel über Sachen, wovon man keine Ahnung hat.
Mal ganz davon ab, woher weist du, was er gemeint hat? Weil du denkst, dass er das meint?
Auch ist selbst eigentlich die Aussage, in den Engines wäre MT Support integriert, nonsens... Die Engines sind genau was? Es ist ne Ansammlung von Bibliotheken. Die Engine ist aber nicht das Spiel. Denn das Spiel besteht für gewöhnlich aus Kontent, für welches man sich der Engine als Gerüst bedient. Und der Kontent macht die Musik. Hab ich keine KI, hab ich keine Berechnungen für die KI und folgerichtig keine Threads dafür, hab ich keinen Sound, hab ich keine Berechnungen für den Sound und folgerichtig keine Threads dafür, hab ich keine Physik, hab ich keine Berechnungen dafür usw. -> sollte klar ersichtlich sein.
Am Ende bleibt weiterhin das Problem, auch xx viele Threads bringen keine MT Leistungsskalierung, wenn sie nicht gleichzeitig laufen. -> und wir sind wieder am Anfang bei der einen kleinen entscheidenden Sache, die auch du offenbar nicht verstanden zu haben scheinst.
Das sehe ich anders... Schau dir gängige Software an, was dort für Threads genutzt werden. SingleThread Anwendungen findest du fast gar nicht mehr. Bestenfalls ist das horn alter Code...
Es reicht schon mit nem halbwegs neuen Visual Studio dein Projekt zu erstellen -> schon hast du Multithreading prinzipiell erstmal "drin". Der ganze Stino .NET Stuff ist häufig MT ausgelegt usw.
Du als Programmierer musst das natürlich dann konsequent nutzen. MT hier und dort bringt wie oben gesagt genau NULL, wenn es nicht gleichzeitig laufen kann oder wird
Zuletzt bearbeitet:
fdsonne schrieb:
Natürlich gibt es das. Die reine Unterstützung von mehreren Softwarethreads ( Separierung der GUI ) ist uralt wie du ja selbst sagst.
Die Abwicklung auf mehrere CPU Kerne zu verteilen ist heutzutage meistens die Aufgabe von API´s, wenn man Games heranzieht.
Du hättest dich auch deutlich kürzer fassen können und schlicht die in Hardware vorhandenen logischen Kerne von den virtuellen Threads eines Betriebssystems trennen können.
Ein Wissendefizit gibt es hierbei offensichtlich nicht.
Software ist ein allumfassender Begriff.
Software wird zu 95% überhaupt nicht multithreaded programmiert, sondern läuft prozedural nach Schema F ab.
Die Software für die es sich lohnt ist schweineteuer. Aufwändiges Debugging und ein langer Reifungsprozess mit Inbegriffen.
Normalerweise scheut man den Aufwand.
Zuletzt bearbeitet:
Es wird aber nicht auf "Kerne" verteilt, sondern es wird Multithreaded gearbeitet. Die Verteilung auf die Hardware übernimmt idR das OS bzw. genauer, der Threadscheduler...
Mit APIs hat das nix zu tun. Eine API ist eine Schnittstelle. Wie übernimmt eine API bitte eine CPU Kernzuweisung?
Wie bereits erwähnt besteht das Defizit in der fehlenden Unterscheidung zwischen Multithreading als solches und der eigentlich idR gemeinten/erhofften Leistungsskalierung über die gleichzeitige Nutzung mehrerer Threads.
Oder wie erklärst du dir die ganzen Aussagen (auch hier im Thread)?
Die Leute gehen davon aus, wenn MT darauf steht, ist Leistungsskalierung drin -> und das ist eben idR nicht der Fall. Vor allem bei Games ist das idR absolut nicht der Fall.
Wer sprach davon, dass jegliche Bestandteile von Software MT ausgelegt sein müssen? Das war überhaupt nicht Aussage... Ich glaube, wir reden gerade massiv aneinander vorbei... Es ging keineswegs um MT im Vollumfang. Sondern es ging gerade darum, das MT eben auch bei simplen Geschichten schon drin sein kann -> und man dann mit MT "werben" kann.
Wie oben erwähnt, jedes OpenFileDialog Fenster aus einem halbwegs aktuellen .Net Portfolio ist MT. Jede Software, die sich diesem Fenster bedient, nutzt folgerichtig also MT. Und das scheint mir eine ganze Menge...
Der Java Ableger davon fabriziert das im übrigen auch so. Wären wir bei zwei gängigen Vertretern in der Windowswelt. Nagel mich bitte nicht auf die Linux Thematiken fest... Der Javateil sollte aber analog laufen.
Zuletzt bearbeitet:
mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.420
Es gibt Bulldozer CPUs und APUs mit 2 Modulen. Wieso soll es also nicht Zen CPUs und APUs mit 4 Kernen geben? Ich sehe da erst mal keinen Widerspruch.
Ausserdem kommt die Zen APU erst ein gutes Stück später, voraussichtlich mindestens ein halbes Jahr. Der AM4 Plattform bis dahin 4-Kerner vorzuenthalten, ergibt für mich wenig Sinn. Zusätzlich verbessert man mit 4-Kern Modellen die Resteverwertung des 8-Kern Dies.
Kann es sein, dass du sehr ins Detail gehst und dich an vermeintlichen Unzulänglichkeiten aufhängst?
Die workloads werden nunmal ganz klassisch an die Cu´s der Prozessoren verteilt. Threadsheduler können das Problem sogar verschlimbessern, ich erinnere hierbei a Windows 7, an Intels Hyperthreading oder an AMD´s CMT Verfahren.
Eine API ist eine Schnittstelle, für heutige Zeiten optimalerweise lowlevel also direktem Hardwarezugriff, das Betriebssystem selbst spielt hierbei eigentlich weniger eine Rolle, bzw soll in Zukunft eine immer kleinere derer spielen.
Tausche von mir aus Kern durch Pipeline, dann wird es vielleicht klarer was gemeint ist.
Hast du schonmal was von einem Trigger gehört?
Die Directx11 API konnte mit CPU´s mit mehreren Pipelines viel schlechter umgehen als die Directx12 API, bei potenziell selbigem Betriebssystem und gleichem "sheduler"
fdsonne schrieb:
Obige Aussage von teiger kann ich so voll unterschreiben.
Zuletzt bearbeitet:
Nicht wirklich...
Ursprünglich wollte ich eigentlich nur den einen User oben drauf hinweisen, dass ein Unterschied zwischen MT steht drauf und MT skaliert über die CPU Breite, existiert. Denn das ist genau der Punkt, der hier alle Nase lang in einen Topf geschmissen wird. Das ganze gepaart mit einer (hoffentlich) halbwegs verständlichen Erklärung bzw. Beispielen.
Dann kam Dragon und wollte mir und allen hier erzählen, dass die User das ja alle wissen würden und entgegen der genutzten Wortwahl doch was ganz anderes meinen würden.
PS: kann es sein, dass du dich beim Wörtchen API ziemlich stark an der DX12/Vulcan/Mantle API aufhängst? Wenn ja, dann lass dir gesagt sein, das ist nur ein Teil des Ganzen... APIs existieren auch abseits von dieser Art der Schnittstellen und das auch in Games. Mit Prozessor/Ressourcenzuweisung selbst hat das weiterhin nix zu tun. Es ist vereinfacht gesagt einfach nur ein definierter Übergabepunkt. Eben eine Schnittstelle. Links rein, rechts raus... Was genau? Völlig irrelevant...
Übrigens spielt das Betriebssystem eine ganz gewaltige Rolle bei der Thematik. Denn es ist gar nicht gewollt, das durch jede dahergelaufene Codezeile direkt bis auf die unterste Hardwareebene zugegriffen werden darf... Und das ist auch gut so.
Dann hast du es nicht verstanden... Sorry. Lies doch einfach mal den Satz weiter?
Da kommt dann ein, er würde lieber einen Oktacore dem Quadcore vorziehen, eben weil er davon ausgeht, dass es in Zukunft in Games mit mehr wie vier Cores optimal wäre.
-> das ist halt Unsinn und kommt (so denke/dachte ich) von der Annahme, dass man generellen MT Support durch einfache Nutzung von Softwarethreads mit einer Leistungsskalierung über die CPU Breite assoziiert.
Wenn du das von ihm so unterschreibst, dann mach...
Jeder darf hier denken, wie er möchte. Ich maße mir durchaus an den Background verstanden zu haben. Wenn man gern weiter mit diesen pseudo-Halbweisheiten argumentieren möchte. Kein Ding immer zu... Kauft den 16-Threader und staunt wie wenig Performance da in der Praxis bei rum kommt, trotz das MT auf der Software steht Und ja, auch das weis ich (bzw. sollte ich wohl wissen), denn ich nutze einen 16 Thread Prozessor in meiner Workstation seit geraumer Zeit für alles, was ich eben an der Büchse fabriziere...
Die Aussagen von wegen, dauert nicht mehr lang, dann sind diese und welche CPU Breiten notwendig kommen seit nunmehr 10 Jahren fast täglich in den Threads...
Aber sei es drum... Ist eh reichlich OT
Macht halt wie ihr meint.
Zuletzt bearbeitet:
passat3233
Urgestein
- Mitglied seit
- 01.05.2007
- Beiträge
- 4.405
Nein, macht man nicht.
Der Treadscheduler schaltet die CPU nur immer kurz zwischen den Threads hin und her.
Auf einem Singlecore ohne HT können deswegen auch mehrere Threads scheinbar parallel ablaufen.
Das gibts schon seit Windows 3.0.
Jeder Thread bekommt eine bestimmte CPU-Zeit zugewiesen, dann wird auf einen anderen Thread umgeschaltet.
Die Zeitfenster sind so kurz (um die 20 ms), das der Anwender meint, die Threads würden parallel abgearbeitet.
Mit der Threadpriorität kann man einzelnen Threads mehr Zeitfenster zuteilen bzw. das Zeitfenster für den Thread verlängern.
Man kann per Registryeintrag sogar die Länge des Zeitfensters einstellen.
Ich sehe irgendwie den Widerspruch nicht, den du ja scheinbar aussagen willst? Zumindest nicht in deiner Erklärung...
Oder auf was genau bezieht sich "Nein, macht man nicht."?
Ich maße mir durchaus an den Background verstanden zu haben. Wenn man gern weiter mit diesen pseudo-Halbweisheiten argumentieren möchte. Kein Ding immer zu... Kauft den 16-Threader und staunt wie wenig Performance da in der Praxis bei rum kommt, trotz das MT auf der Software steht
Dass ein 16 Threader für Games nicht notwenig sein wird, denke ich auch, ich habe mich eher an deiner Aussage aufgehangen, es gäbe im Prinzip keine Unterstützung für "Multicores".
Hier würde ich die Begrifflichkeiten schlicht anders wählen.
Holt
Legende
- Mitglied seit
- 05.07.2010
- Beiträge
- 29.849
fudzilla berichtet über die Server CPUs Naples auf Zen Basis, demnach wird es bis zu 128PCIe Lanes geben und 16 10GbE Ports im Chipsatz. Wenn auch die Desktop Zen mit 10GbE kommen, wäre AMD damit gegenüber Intel echt im Vorteil.
ja weil alle sofort 10Gb brauchen ^^ ein Riesenvorteil also!
Phantomias88
Banned
Kann deine SSD nicht über 120MByte/s lesen? Das ist das Limit bei einem 1Gbit Netztwerk.
Von daher habe ich schon Interesse an 10Gbit, wer es nicht braucht kann auch günstige OEM Boards nehmen.
Zuletzt bearbeitet:
NasaGTR
Enthusiast
- Mitglied seit
- 12.05.2013
- Beiträge
- 7.883
Das wäre aber sicherlich 128 PCIe bei 2 oder mehr Sockeln, nicht pro CPU!
Und 10Gbit wäre für Home schon Nice, SSD Preise sinken, bald kann man seine NAS mit SSDs bestücken. Allerdings wird das noch dauern. Aktuell gibt es glaub nicht mal ne Fritzbox die 10Gbit schafft, und die Consumer Mainboards haben das auch nicht onboard.
Das dauert sicherlich noch 2 Jahre mindestens!
Und 10Gbit wäre für Home schon Nice, SSD Preise sinken, bald kann man seine NAS mit SSDs bestücken. Allerdings wird das noch dauern. Aktuell gibt es glaub nicht mal ne Fritzbox die 10Gbit schafft, und die Consumer Mainboards haben das auch nicht onboard.
Das dauert sicherlich noch 2 Jahre mindestens!
Zuletzt bearbeitet:
Ähnliche Themen
