Unterschied HTT DualCore optimierte Software

[HellHorse]

Hi

So wie ich die heutigen News verstehe, gibt's einer Unterschied zwischen Hyper-Threading und DualCore optimierter Software.
Ich dache bissher immer neuen Thread oder Prozess aufmachen, möglichst keine spinlocks verwenden und und man profitiert sowohl von SMP wie SMT.
Ok irgendwie muss noch für Synchronisation und Kommunikation gesorgt werden, aber das sind "Details".

Könnte mich jemand erhellen?

[StefanV]

Kurzfassung:

Bei SMT optimierter SW muss man aufpassen, daß die Threads sich nicht gegenseitig blockieren und ev. die gleichen Ausführungseinheiten benötigen würden.

Bei Dual Core muss man darauf keine Rücksicht mehr nehmen, man kann einfach was auf 2 'echte' CPUs verteilen

[Haarmann]

HellHorse

Imho wird alles was aus SMT Nutzen zieht auch bei DualCore Nutzen bringen, aber wenn man z.B. versuchte 2 Threads zu kreieren, die identische Aufgaben bewältigen, wird das SMT System wohl einbrechen und das DualCore noch immer profitieren. Wenns allerdings um Speicherleistung geht ists wohl wieder Fisch was Vogel.

[Endorphine]

Software, die ohne Multitaskingeffekte von SMT profitiert und darauf optimiert ist wird auch auf CMPs deutliche Gewinne zeigen imho. Der umgekehrte Fall gilt aber nicht unbedingt: SMP-optimierte Software kann auf SMT-CPUs zu Leistungs-/Durchsatzeinbussen führen.

Da ein CMP üblicherweise die I/O-Schnittstelle teilt muss man bei der Optimierung nun darauf achten, dass nicht beide CPUs zur gleichen Zeit I/O-Bedarf haben (Systemhauptspeicherzugriffe etc.). Ein entscheidender Unterschied im Vergleich zu SMP aus diskreten CPUs. Der Parallelverarbeitung wird dadurch Grenzen gesetzt, bei SMP-Rechnern mit gewöhnlichen diskreten K8 kann dagegen CPU0 auf ihren Speicher zugreifen, CPU1 währenddessen Daten zur Grafikkarte transferieren etc.

Ein CMP verhält sich also teilweise wie eine Master-Slave Multiprozessorarchitektur.

[Benedikt]

Software, die ohne Multitaskingeffekte von SMT profitiert und darauf optimiert ist wird auch auf CMPs deutliche Gewinne zeigen imho. Der umgekehrte Fall gilt aber nicht unbedingt: SMP-optimierte Software kann auf SMT-CPUs zu Leistungs-/Durchsatzeinbussen führen.

Da ein CMP üblicherweise die I/O-Schnittstelle teilt muss man bei der Optimierung nun darauf achten, dass nicht beide CPUs zur gleichen Zeit I/O-Bedarf haben (Systemhauptspeicherzugriffe etc.). Ein entscheidender Unterschied im Vergleich zu SMP aus diskreten CPUs. Der Parallelverarbeitung wird dadurch Grenzen gesetzt, bei SMP-Rechnern mit gewöhnlichen diskreten K8 kann dagegen CPU0 auf ihren Speicher zugreifen, CPU1 währenddessen Daten zur Grafikkarte transferieren etc.

Ein CMP verhält sich also teilweise wie eine Master-Slave Multiprozessorarchitektur.

Das heißt SMT-optimierte Software, wie sie vermehrt in letzter Zeit herausgekommen ist, sollte auch auf SMP/Dual Core gut performen?

MFG,
B. W.

[mrdigital]

Kurz und knapp: ja ;)

[Muh-sagt-die-Kuh]

Da ein CMP üblicherweise die I/O-Schnittstelle teilt muss man bei der Optimierung nun darauf achten, dass nicht beide CPUs zur gleichen Zeit I/O-Bedarf haben (Systemhauptspeicherzugriffe etc.). Ein entscheidender Unterschied im Vergleich zu SMP aus diskreten CPUs. Der Parallelverarbeitung wird dadurch Grenzen gesetzt, bei SMP-Rechnern mit gewöhnlichen diskreten K8 kann dagegen CPU0 auf ihren Speicher zugreifen, CPU1 währenddessen Daten zur Grafikkarte transferieren etc.

Ein CMP verhält sich also teilweise wie eine Master-Slave Multiprozessorarchitektur.In dieser allgemeinen Form ist diese Aussage nicht so ganz richtig ;)

Intel basierte SMP Systeme bestehen aus diskreten CPUs, sie unterliegen aber den selben Einschränkungen wie der CMP Opteron => geteilter FSB.

Dementsprechend sollte das Skalierungsverhalten eines einzelnen DualCore Opterons gegenüber einem einzelnen SingleCore Opteron ähnlich dem eines 2-way Xeon SMP Systems gegenüber einem single Xeon sein.

Btw, ich hab Leo zu den News mal einen Hinweis auf einen Widerspruch in das 3DCenter Forum gesetzt ;)

[Endorphine]

Ich hab eher drauf gewartet, dass die AMD-Fraktion Einspruch erhebt, weil AMD ja lt. eigenen Angaben einen "Crossbar Switch" als I/O-Schnittstelle verwendet, was ja impliziert, dass zumindest Transfers zum/vom integrierten Speichercontroller und über die HT-Links synchron zueinander erfolgen können (zwar nur entweder-oder zu einem Kern, aber zeitgleich, wenn es sich wirklich um einen Switch handelt). ;)

http://www.heise.de/bilder/50540/0/0

[Bokill]

@Endorphine
So manche Beiträge sind so angemüllt mit Unwissen, so dass da deine (verzeihliche) möglicherweise gar beabsichtigte "Fehlleistung" nicht zum sofortigen Wiederspruch anregte. ;)

Auch ein Switsch/Fabric hat eine Grenze ;) ...

Und keiner vermag genau sagen, wie es denn mit 4 Kernen aussehen könnte ... ist das der mögliche Grund für Horus? , der inoffizielle Nachfolger der IO/X-Bar und SRQ? ... Wer kann dies schon genau sagen ...

Hypertransport verursacht bei vielen Kernen ja auch einen gewissen Kommunikations-Overhead und Latenzunterschiede.

Und AMD sagte zum Cohärenten Hypertransport, dass dort das HT-Konsortium keinen Einfluss hat.

Horus hingegen hat HTc integriert, mehrfach! Ohne Zustimmung und Zusammenarbeit mit AMD wäre so etwas nie möglich gewesen.

MFG Bokill

[zeckensack]

Es gibt einige Differenzen, wenn mehrere Threads miteinander kommunizieren müssen.

Ganz grob mal das Modell, an dem ich zufälligerweise gerade arbeite:
*hust*
"Frontend"-Threads schreiben in einen FIFO (gelöst als Ringpuffer).
Ein "Backend"-Thread liest aus diesem FIFO.

Bei einem SMP-System stellt sich nun die Frage: in wessen Cache ist eigentlich der FIFO?

Kohärenzprotokolle wie MO(E)SI verhindern in diesem Szenario zwar, dass dauernd beide Prozessoren ihre Caches ausleeren und synchronisieren müssen -- schlimm wär's nur dann, wenn mehrere Threads gleichzeitig in die gleiche Cache-Line schreiben wollten --, allerdings fällt hier doch nicht unerheblicher "snoop traffic" an. Dabei wird zwar nur festgestellt, dass diese Kollision harmlos ist, trotzdem müssen die Kerne sich hier andauernd koordinieren. Wie schlimm das ist hängt von der Systemarchitektur ab.

Ein "klassisches" SMP-System ala Intel Xeon (ohne HTT) hat hiermit sicher mehr Probleme als ein über Hypertransport verbundenes Mehrfach-Opteron-System. Ich hoffe das leuchtet auch ohne weitere Erläuterungen ein.

Tatsache ist aber, dass auf einem reinen SMT-System (dh nur ein "physikalischer" Prozessor) kein snoop traffic auftritt. Es gibt nur den einen Cache, und dessen Inhalt gehört unzweifelhaft dem Prozessor als ganzen. Es ist kein Abgleich nötig.

[Benedikt]

Es gibt einige Differenzen, wenn mehrere Threads miteinander kommunizieren müssen.

Ganz grob mal das Modell, an dem ich zufälligerweise gerade arbeite:
*hust*
"Frontend"-Threads schreiben in einen FIFO (gelöst als Ringpuffer).
Ein "Backend"-Thread liest aus diesem FIFO.

Bei einem SMP-System stellt sich nun die Frage: in wessen Cache ist eigentlich der FIFO?

Kohärenzprotokolle wie MO(E)SI verhindern in diesem Szenario zwar, dass dauernd beide Prozessoren ihre Caches ausleeren und synchronisieren müssen -- schlimm wär's nur dann, wenn mehrere Threads gleichzeitig in die gleiche Cache-Line schreiben wollten --, allerdings fällt hier doch nicht unerheblicher "snoop traffic" an. Dabei wird zwar nur festgestellt, dass diese Kollision harmlos ist, trotzdem müssen die Kerne sich hier andauernd koordinieren. Wie schlimm das ist hängt von der Systemarchitektur ab.

Ein "klassisches" SMP-System ala Intel Xeon (ohne HTT) hat hiermit sicher mehr Probleme als ein über Hypertransport verbundenes Mehrfach-Opteron-System. Ich hoffe das leuchtet auch ohne weitere Erläuterungen ein.

Tatsache ist aber, dass auf einem reinen SMT-System (dh nur ein "physikalischer" Prozessor) kein snoop traffic auftritt. Es gibt nur den einen Cache, und dessen Inhalt gehört unzweifelhaft dem Prozessor als ganzen. Es ist kein Abgleich nötig. Sicher, bei einem konventionellen SMP-System... Aber gerade ein DualCore-Prozessor sollte ja auch snoop traffic relativ schnell abarbeiten können, oder? :)

MFG;
B. W.

P.S./OT: was sind das eigentlich für Sachen, die du da machst - privat oder "geschäftlich"? :)

[Muh-sagt-die-Kuh]

Sicher, bei einem konventionellen SMP-System... Aber gerade ein DualCore-Prozessor sollte ja auch snoop traffic relativ schnell abarbeiten können, oder? :)Das kommt auf den Aufbau der Cache-Hierarchie an.

Bei einem gesharten, inklusiven L2 Cache muss man nur diesen Cache snoopen, bei geteiltem L2 Cache logischerweise jeden der beiden Caches.

[micki]

HellHorse

Imho wird alles was aus SMT Nutzen zieht auch bei DualCore Nutzen bringen, aber wenn man z.B. versuchte 2 Threads zu kreieren, die identische Aufgaben bewältigen, wird das SMT System wohl einbrechen
eigentlich können zwei threads die selben aufgaben beweltigen, selbst dann hat man oft noch performancegewinne laut intel.


worauf man bei HT aufpassen muss, ist dass man durch zwei threads nicht den einen cache zerschiesst, laut intel ist das das größte problem das auftretten kann... und was die beim prescott optimiert hatten.


ich frage mich aber gerade deshalb ob HT optimierte programme nicht entgegen der cache-strategie von dualcore optimiert wurden.

MfG
micki

[Demirug]

eigentlich können zwei threads die selben aufgaben beweltigen, selbst dann hat man oft noch performancegewinne laut intel.


worauf man bei HT aufpassen muss, ist dass man durch zwei threads nicht den einen cache zerschiesst, laut intel ist das das größte problem das auftretten kann... und was die beim prescott optimiert hatten.


ich frage mich aber gerade deshalb ob HT optimierte programme nicht entgegen der cache-strategie von dualcore optimiert wurden.

MfG
micki

Eigentlich nicht. Den das Anpassen von HTT auf den Cache bedeutet nichts anderes als auf einen kleineren Cache anzupassen. Bei einem Dualcore mit getrenten Caches würde das als im schlimmsten Fall dazu führen das der Cache nicht komplett ausgenutzt wird. Aber bei den vielen Chips mit unterschiedlichen Cachegrössen findet man da sowieso keine perfekte Lösung.

[micki]

Eigentlich nicht. Den das Anpassen von HTT auf den Cache bedeutet nichts anderes als auf einen kleineren Cache anzupassen.
Nein, es bedeutet dass man ein anderes allignment für daten macht und darauf achten muss, dafür wird eventuell sogar speicher doppelt gehalten.

MfG
micki

[Demirug]

Nein, es bedeutet dass man ein anderes allignment für daten macht und darauf achten muss, dafür wird eventuell sogar speicher doppelt gehalten.

MfG
micki

Das Allignment wird durch die grösse der Cachelines bestimmt und die ändert sich durch HTT nicht.

[micki]

Das Allignment wird durch die grösse der Cachelines bestimmt und die ändert sich durch HTT nicht.
wenn die virtuellen addressen von zwei speicherbereichen modulo64kb zueinander sind (64k allignmentprobleme gibt es nur <prescott, ab prescott sind es wohl 512k soweit ich mich erinnere), dann wird es einen cacheconflict geben und die speicherbereiche konkurieren dann um den cache.
natürlich ist dann nur ein bereich in der cacheline und bei abwechseldem zugriff werden beide bereiche abwechseln in der cacheline gespeichert. das passiert bei multithreading öfters und deswegen muss man dabei aufpassen (indem man z.b. ein 32kb allignment für die allokation vom speicher einbaut, je nachdem welcher thread allokiert oder natürlich indem man die daten gleich günstig liegend hat).

das was am schlimmsten peformance zieht, wäre wenn man 2 threads aufmacht und sie laufen ließe, sie würden die selbe virtuelle addresse für ihren stack haben und ständig collisions hervorrufen. wenn man sich also nicht damit auskennt, wird man gleich merken dass HT viel langsammer ist als ein einzelner prozess.

bei dualcore würde es hingegen vielleicht performance einbussen bringen wenn man die daten (oder den stack) umarrangiert anstatt sie so zu nutzen wie sie darliegen.

MfG
micki

[Muh-sagt-die-Kuh]

wenn die virtuellen addressen von zwei speicherbereichen modulo64kb zueinander sind (64k allignmentprobleme gibt es nur <prescott, ab prescott sind es wohl 512k soweit ich mich erinnere), dann wird es einen cacheconflict geben und die speicherbereiche konkurieren dann um den cache.Northwood Stepping <= B0: 64K L1 Aliasing Problem (niedrigste 16 bit der virtuellen Adresse)
Northwood Stepping > B0: 1M L1 Aliasing Problem (niedrigste 20 bit der virtuellen Adresse)
Prescott: 4M Aliasing "Problem"

So schreibt es zumindest die c´t

Ich habe damit allerdings ein leichtes Problem, vielleicht kann jemand mir das erklären:

Der L1 D-Cache des P4 virtually indexed, physically tagged. Die niedrigsten 12 bit sind kein Problem, da bei virtueller und physischer Adresse identisch (4K Pages = 2^12 bit zur Adressierung innerhalb einer Page). Der Cache hat nun 64 byte pro line, eine Größe von 8 KiB (Northwood) bzw 16 KiB (Prescott) und ist 4-way (Northwood) bzw 8-way (Prescott) set-associative. Um diesen Cache zu Adressieren benötigt man, wenn ich nicht völlig falsch liege, nur die niedrigsten 11 bits der Adresse: 6 bit um alle 64 byte in einer Line anzusprechen sowie 5 bit um alle 32 Sets im Cache anzusprechen.

Wer kann mir erklären, wieso es nun zu Aliasing kommen kann, wenn ich die fraglichen Bits zur Adressierung überhaupt nicht brauche?

[Muh-sagt-die-Kuh]

*push*

[GloomY]

Northwood Stepping <= B0: 64K L1 Aliasing Problem (niedrigste 16 bit der virtuellen Adresse)
Northwood Stepping > B0: 1M L1 Aliasing Problem (niedrigste 20 bit der virtuellen Adresse)
Prescott: 4M Aliasing "Problem"

So schreibt es zumindest die c´t

Ich habe damit allerdings ein leichtes Problem, vielleicht kann jemand mir das erklären:

Der L1 D-Cache des P4 virtually indexed, physically tagged. Die niedrigsten 12 bit sind kein Problem, da bei virtueller und physischer Adresse identisch (4K Pages = 2^12 bit zur Adressierung innerhalb einer Page). Der Cache hat nun 64 byte pro line, eine Größe von 8 KiB (Northwood) bzw 16 KiB (Prescott) und ist 4-way (Northwood) bzw 8-way (Prescott) set-associative. Um diesen Cache zu Adressieren benötigt man, wenn ich nicht völlig falsch liege, nur die niedrigsten 11 bits der Adresse: 6 bit um alle 64 byte in einer Line anzusprechen sowie 5 bit um alle 32 Sets im Cache anzusprechen.

Wer kann mir erklären, wieso es nun zu Aliasing kommen kann, wenn ich die fraglichen Bits zur Adressierung überhaupt nicht brauche?
Ich :D

Das hier angesprochene Aliasing ist ein anderes Aliasing als das was man normalerweise mit "Aliasing" bei Caches bezeichnet. Daher auch die Verwirrung deinerseits. Es ist richtig, dass es für zwei unterschiedliche virtuelle Adressen eines virtuellen Adressraums im L1 Cache des P4s keine Aliases gibt, also keine unterschiedlichen Cachelines, die auf die gleiche physikalische Adresse abgebildet werden.
Jetzt kann es aber sein, dass der Prozessor bei SMT zwei Threads von zwei unterschiedlichen Prozessen, also auch von zwei unterschiedlichen virtuellen Adressräumen bearbeitet (jeder Prozess hat seinen eigenen virtuellen Adressraum). Für je beide Threads gibt es eine Funktion, die virtuelle Adressen in physikalische abbilden (u.a. auch zwei TLBs). Diese Funktionen bilden AFAIK auf disjunkte physikalische Adressen ab, der Schnitt der beiden Bildmengen ist also leer. Die physikalischen Adressen sind also immer verschieden, aber nicht umbedingt die virtuellen. Und genau das ist hier mit "Aliasing" gemeint.

Hier geht es um gleiche virtuelle Adressen aus unterschiedlichen virtuellen Adressräumen, die zwar auf unterschiedliche physikalische Adressen abgebildet werden, bei einem virtuell indexierten Cache aber in das gleiche Set fallen und damit natürlich die Konfliktwahrscheinlichkeit erhöhen.


In wie weit man da die Aliases mit einem neuen Stepping "auseinander"-bewegen kann, ist mir momentan auch nicht klar. Ich hab' aber leider keine Zeit sondern muss weiterlernen. Vielleicht Ende nächster Woche mehr... ;)

[Muh-sagt-die-Kuh]

Ich :D

Hier geht es um gleiche virtuelle Adressen aus unterschiedlichen virtuellen Adressräumen, die zwar auf unterschiedliche physikalische Adressen abgebildet werden, bei einem virtuell indexierten Cache aber in das gleiche Set fallen und damit natürlich die Konfliktwahrscheinlichkeit erhöhen.

In wie weit man da die Aliases mit einem neuen Stepping "auseinander"-bewegen kann, ist mir momentan auch nicht klar. Ich hab' aber leider keine Zeit sondern muss weiterlernen. Vielleicht Ende nächster Woche mehr... ;)Bei einer Pagesize von 4K und einem Cache mit den oben genannten Parametern macht es keinen Unterschied, ob der Cache virtuell oder physisch indexiert wird: die niederwertigsten 12 bits von virtueller und physischer Adresse sind identisch und mehr als diese 12 bits braucht man zum Indexieren nicht. Virtuelle Indexierung hat hier nur den Vorteil, dass man indexieren kann während der TLB noch die physikalische Adresse zusammenbastelt.

So wie ich die Dokumente lese kann sich beim B-Step Northwood aber im gesamten L1 Cache nur eine einzige Line befinden, deren virtuelle Adresse ein spezifisches Muster in den Bits 15-6 hat.....die beiden virtuellen Adressen

...10 1010 | 0101 0100 0111

und

...11 1010 | 0101 0100 0111

konkurrieren also um einen Cacheline (dass sie um ein Set konkurrieren wäre normal). Wieso zur Hölle ist das bei dem mengenassoziativen L1 Cache des P4 so.....der muss da etwas ganz, ganz komisches intern machen....und mich interessiert was ;)

Hier noch der Text zu dem Thema aus dem "IA-32 Intel® Architecture Optimization Reference Manual":

Data conflict – can only have one instance of the data in the
first-level cache at a time. If a reference (load or store) occurs with
its linear address matching a data conflict condition with another
reference (load or store) which is under way, then the second
reference cannot begin until the first one is kicked out of the cache.
On Pentium 4 and Intel Xeon processors with CPUID signature of
family encoding 15, model encoding of 0, 1 or 2, the data conflict
condition applies to addresses having identical value in bits 15:6
(also referred to as 64K aliasing conflict). If you avoid this kind of
aliasing, you can speedup programs by a factor of three if they load
frequently from preceding stores with aliased addresses and there is
little other instruction-level parallelism available. The gain is
smaller when loads alias with other loads, which cause thrashing in
the first-level cache. On Pentium 4 and Intel Xeon processors with
CPUID signature of family encoding 15, model encoding 3, the
data conflict condition applies to addresses having identical value in
bits 21:6.

P.S.: Viel Erfolg beim Lernen!

[Gast]

Bei einer Pagesize von 4K und einem Cache mit den oben genannten Parametern macht es keinen Unterschied, ob der Cache virtuell oder physisch indexiert wird: die niederwertigsten 12 bits von virtueller und physischer Adresse sind identisch und mehr als diese 12 bits braucht man zum Indexieren nicht. Virtuelle Indexierung hat hier nur den Vorteil, dass man indexieren kann während der TLB noch die physikalische Adresse zusammenbastelt.Hmm, tolles Eigentor von mir :| Du hast natürlich vollkommen Recht.

Solange die Way-Größe unter der Page-Größe bleibt, reicht es virtuell zu indizieren, weil die dafür nötigen Bits die gleichen wie bei der physikalischen Adressierung sind.
So wie ich die Dokumente lese kann sich beim B-Step Northwood aber im gesamten L1 Cache nur eine einzige Line befinden, deren virtuelle Adresse ein spezifisches Muster in den Bits 15-6 hat.....die beiden virtuellen Adressen

...10 1010 | 0101 0100 0111

und

...11 1010 | 0101 0100 0111

konkurrieren also um einen Cacheline (dass sie um ein Set konkurrieren wäre normal). Wieso zur Hölle ist das bei dem mengenassoziativen L1 Cache des P4 so.....der muss da etwas ganz, ganz komisches intern machen....und mich interessiert was ;)

Hier noch der Text zu dem Thema aus dem "IA-32 Intel® Architecture Optimization Reference Manual": [...]Ich schätze, dass es sich um virtual Hints handelt. Diese stellen einen nicht vollständigen virtuellen Tag dar, der die Way-Auswahl schon im Vorfeld tätigt, bevor die TLB den physikalischen Tag liefern kann. Es ist eine spekulative Variante, die wahrscheinlich auch mit die niedrige Zugriffszeit des L1-D des P4s ermöglicht.

http://en.wikipedia.org/wiki/CPU_cache
It can be useful to distinguish the two functions of tags in an associative cache: they are used to determine which way of the entry set to select, and they are used to determine if the cache hit or missed. The second function must always be correct, but it is permissible for the first function to guess, and get the wrong answer occasionally. [...]

The extra area (and some latency) can be mitigated by keeping virtual hints with each cache entry instead of virtual tags. These hints are a subset or hash of the virtual tag, and are used for selecting the way of the cache from which to get data and a physical tag. Like a virtually tagged cache, there may be a virtual hint match but physical tag mismatch, in which case the cache entry with the matching hint must be evicted so that cache accesses after the cache fill at this address will have just one hint match. Since virtual hints have fewer bits than virtual tags distinguishing them from one another, a virtually hinted cache suffers more conflict misses than a virtually tagged cache.Die virtual Hints sind beim Prescott und Northwood mit Stepping >= B0 wohl einfach größer als bei den früheren Northwoods. :)
P.S.: Viel Erfolg beim Lernen!Danke :)
Ich lasse mich aber leider zu oft ablenken (wie u.a. auch hier) :|

[GloomY]

Das dort oben war ich (wo sind meine Küchlein? ;( )

[Muh-sagt-die-Kuh]

Ich schätze, dass es sich um virtual Hints handelt. Diese stellen einen nicht vollständigen virtuellen Tag dar, der die Way-Auswahl schon im Vorfeld tätigt, bevor die TLB den physikalischen Tag liefern kann. Es ist eine spekulative Variante, die wahrscheinlich auch mit die niedrige Zugriffszeit des L1-D des P4s ermöglicht.

http://en.wikipedia.org/wiki/CPU_cache
Die virtual Hints sind beim Prescott und Northwood mit Stepping >= B0 wohl einfach größer als bei den früheren Northwoods. :)Das wird es wohl sein :)

Wikipedia mausert sich echt zu einem hervorragenden Lexikon, hätte nicht gedacht, dass ich da eine solch umfassende Erklärung zu Caches finden würde, die selbst auf solche Details eingeht. Respekt!

[GloomY]

Das wird es wohl sein :)

Wikipedia mausert sich echt zu einem hervorragenden Lexikon, hätte nicht gedacht, dass ich da eine solch umfassende Erklärung zu Caches finden würde, die selbst auf solche Details eingeht. Respekt!Hihi, weisst du von wem das stammt? Der Name (Iain McClatchie) sagt dir wahrscheinlich nichts, aber vielleicht hilft es, wenn ich dazusage, dass dieser recht häufig auf comp.arch postet... ;)

Ich denke, dass Wikipedia wohl einzelne sehr gute Sachen hat, aber nach denen muss man wirklich suchen...

[Benedikt]

Hihi, weisst du von wem das stammt? Der Name (Iain McClatchie) sagt dir wahrscheinlich nichts, aber vielleicht hilft es, wenn ich dazusage, dass dieser recht häufig auf comp.arch postet... ;)

Ich denke, dass Wikipedia wohl einzelne sehr gute Sachen hat, aber nach denen muss man wirklich suchen...
Wer ist denn der besagte Herr? Hat der nicht irgendwas mit der Entwicklung der CPU oder so zu tun (in den Anfängen)?

MFG,
B. W.

[GloomY]

Wer ist denn der besagte Herr? Hat der nicht irgendwas mit der Entwicklung der CPU oder so zu tun (in den Anfängen)?

MFG,
B. W.Nein, das nicht. Wie bereits erwähnt postet er regelmäßig auf comp.arch und wer da häufig postet, der hat definitiv Ahnung. Es finden sich auch noch andere Beiträge von ihm im Linux Kernel Archive und in anderen Newsgroups. Einfach mal googlen wenn's dich interessiert :)


Iain McClatchie arbeitet imho bei einer Firma im Silicon Valley, die PLLs herstellt. (truecircuits.com)

Jetzt aber genug OT...