Woher kommt das Zitat
Es fehlt soo viel an Daten.
Ich mein falsch ist es nicht
Aber wirklich Richtig ebenso nicht.
"Ausführungseinheit"
Die Bufferqueue ist riesig.
Und coreclock heißt im Grundegenommen garnichts.
Load balanced.
Das ist leider nicht der Fall
Der CoreCLK ist quasy unwichtig
Es ist ein summierter Wert (placeholder)
Wie oft der angegebene (virtuelle) Wert , im weiteren Placeholder Wert (mhz/sec) gesendet werden darf.
Zu dieser Rechnung nun gehören, dass die BufferQueue nur so voll werden kann, wie der opcache die jeweiligen Instructionsets (größe und art) , in kleinen Chunks/Happen unterteilt werden können.
Somit bei kleinen FFT "Päckchen" füllt es die Bufferqueue schneller, und somit wird mehr hitze erstellt, da die gesammtlast höher ist.
// sehr simplifiziert
Manche SKUs können zb AVX2 nativ innerhalb eines Cycles bearbeiten
Andere ehmalige zersetzen den AVX256 blob in doppelte AVX128 päckchen und brauchen 2 clockcycles.
Usw und so fort
Im Grundegenommen, bedeutet die Kernfrequenz garnichts.
Was reale Leistung ausmacht, ist die größe der Bufferqueue (backend)
Die effektivität des Branchpredictors & OPCache (wie gut es "loadtypes" erkennen und in kleine Happen zersetzen kann)
Und dann zu welcher Leistung der gesammte Transfer stattfinden kann
QCLK, RINGCLK, FCLK, CoreCLK
Auf diesem dann die effektivität des IVR (MHz) & DVFS design
Sprich innerhalb wie vielen cycles darf es die Spannung regulieren, bis die Kerne nicht mehr die Frequenz halten können und nochmal ein chunk spannung sich nehmen müssen.
Diese effektivität des designs, gibt im Grundegenommen den maximalen Takt des Samples an.
Manche sind leaky manche weniger.
Alles so simplifiziert wie möglich.
Doch eigentlich bei "roher leistung" spielt nur die Cache geschwindigkeit eine Rolle und die interne latenz wie sehr kerne nach derren L1Data, L1Instruction
Zu L2 und dann runter zu dem globalen L3 cache, daten ablagern
Da jeder Kern Zugriff, wie bei der GPU vom VRAM
Muss runter zu dem cache, bevor entschieden wird ob man Daten vom Ram hin-und-her laden muss
Oder es Intern schneller ist mit niedriger Latenz, um Daten hin und her zu tauschen.
Beitrag automatisch zusammengeführt:
Oft braucht es weder eine schnelle abtastrate (niedriger coreclk ist ok), noch spannung oder leistung um das Datenpäckchen zu bearbeiten.
Oft haakt es auch an der Application selbst, welche Art von Daten sie versendet und ob ihr überhaupt bekannt ist wie viele Threads im system sind.
Der application interessiert es nicht wie viele Threads existieren.
Sie muss nur wissen wohin sie es laden soll.
Je nachdem was die CPU dem Betriebssystem mitteilt
Welcher kern weitere commands erwarten kann, und was "noch in stau ist" und gerade bearbeitet wird.
Alles eine kurzfassung.
Am handy schreibt es sich schwer
Beitrag automatisch zusammengeführt:
Mit anderen Worten, stört es nicht ob 2 oder 4 threads pro Kern existieren
Die Bufferqueue ist global
Welche Kerne reinladen, ist unwichtig.
Und nein jeder Kern kann mehr als einen Command bearbeiten : ')
Im Grundegenommen ist es weitaus schneller Daten innerhalb des Virtuellen Kerns zu bearbeiten , damit die Bufferqueue effizienter von "schwachen" Lasten gefült wird.
Als zwischen weit entfernten Kernen zu springen, durch den Cache zu müssen und dann dadurch weitaus mehr Spannung reinladen muss, um mehr als einen Kern zu versorgen.
Da kern lasten nicht linear skallieren und alle derren eigenen Chunk an Spannung brauchen.
1kern 700mV
2 kerne 1400mV
Funktioniert zb nicht als Rechnung
Auch nicht,
1 kern 800mV
2 kerne 900mV
3 kerne 1000mV
Ebenso ein Märchen
So funktionieren CPU designs nicht
Threads stören nicht. Es gibt nur leicht "suboptimal-designte" Programme, welche hier und da etwas Druck brauchen, daten Inteligent zu verteilen.
Im aktuellen Intel Design,
Ist die Backend groß genug um effizient zu arbeiten und diese zu füllen.
Im zukünftigem Design, wird der HT entfernt und neu-designed.
Das hat mir der aktuellen SKU jedoch nichts zu tun.
Alle CPUs funktionieren perfekt, so wie sie aus Intel-HQ kommen.
Die CPU zu kastrieren, nur weil eine Application abenteuerlich resourcen verteilt ~ ist etwas unlogisch und eine umgehung des eigentlichen Problems.
Ebenso eine verschwendung des Designs und einschränkung potentieller Leistung.
Den zwischen Kernen zu springen ist abseits langsamer, auch stromfressend.
Zuletzt bearbeitet:
bedeutet auch das ich nicht alles was vorher stabil lief nicht einfach überschreibe/lösche...
