[00:16] Xandros: was der hagen sagt stimmt - hat aber keine konsequenzen wenn man unter nem
os programmiert
[00:16] Xandros: also klar zerlegt die cpu den opcode in microcode
[00:16] -=Assarbad=-: das wollte ich ausdrücken mit dem unterschied zwischen Opcode und Microcode
[00:16] -=Assarbad=-: aber das ist irrelevant
[00:16] Xandros: und wenn man mehrere cpus hat - machen die das natürlich parallel für jeden ihrer eigenen opcodes
[00:17] -=Assarbad=-: was er meint, ist aber das es bei mehreren CPUs konflikte geben kann. IMO aber nicht bei SMP (hieß das nicht Synced MP???)
[00:18] Xandros: wenn nun zufällig eine cpu das datum im speicher ändert - was aber eine andere CPU gerade bearbeitet, kommt es zur kollision und der algo der dann anspringt ist von dem hersteller der cpu abhängig - weil der speicher muss mit dem cache der cpus wieder kohärent gehalten werden - das protokoll heißt MESI was da hauptsächlich genutzt wird
[00:19] Xandros: SMP = Shared multi prozessing
mehrere cpus auf einem speicher, aber mit eigenem cache und MESI als protokoll um den speicher und die caches aller CPUs in Sync zu halten
[00:19] -=Assarbad=-: ups sorry ;)
[00:19] -=Assarbad=-: also ist es doch gesynced?
[00:20] Xandros: und ich glaub er meint die konflikte, die durch MESI halt gelöst werden müssen
[00:20] Xandros: diese konflikte sind ja der grund, weshalb mein system nicht 4 mal schneller wird, wenn ich 4 cpus reinpacke
[00:20] -=Assarbad=-: dann wäre es also weiterhin atomar, selbst bei SMP, oder?
[00:21] -=Assarbad=-: du meinst also wir reden auf verschiedenen ebenen, hagen und ich???
[00:22] -=Assarbad=-: Das wollte ich aber durch folgenden Satz ausschließen: "Wie komplex der darunterliegende Microcode ist, ist komplett irrelevant (, denn in der CPU wird jeder Opcode quasi wie eine Funktion behandelt ... bevor diese nicht zurückkehrt, gehts auch nicht weiter (1))!"
[00:22] Xandros: es muss immer konsistent gehalten werden - folgendes szenario:
cpu1 holt adresse für datum zum schreiben asu speicher in den cache
cpu2 holt sich dasselbe datum ...
problem, cpu2 muss nun erfahren, wenn cpu1 das datum updatet
.. aber das machen die cpus alle selbst - deswegen sind die teile auch so teuer
[00:22] Xandros: ja - genau, verschiedene ebenen - das was hagen sagt hat null relevanz für programmierer
[00:23] -=Assarbad=-: kann ich den Chat zitieren?
[00:24] -=Assarbad=-: darf ich?
[00:24] Xandros: naja, wenn du meinst das ich euch beide richtig verstanden hab und nun nicht auch völlig vorbeidiskutiert habe - klar
[00:25] -=Assarbad=-: jut ich probiers mal ;)
[00:25] Xandros: ich hab nur den eindruck das die ganze diskussion nicht besonders sinnvoll ist, wenn ich ehrlich bin
[00:26] Xandros: weil I/O opereationen über ein medium sich nun mal nicht besonders guten threaden lassen - weil das medium gibts halt nur einmal genauso, wie threads in smp systemen außer einem kleineren overhead im vergleich zu ganzen prozessen auch keinen speedup bringen
[00:27] Xandros: ähh ich meine single cpu systemen
[00:27] Xandros: nicht SMP
[00:27] Xandros: im letzten satz
[00:30] Xandros: an der stelle:
"Bei solchen Konstellationen wird durch das LOCK Prefix alle parallelen CPU's angewiesen zu schlafen, damit eben der EINE OpCode der intern aus vielen sequentiellen OpCodes im MicroCode ausgeführt wird nicht dazu fürht das sich z.b. Überschneidungen auf den Adressleitungen zum Speicher auftreten."
[00:31] -=Assarbad=-: ???
[00:31] Xandros: bin ich mir nicht sicher - es gibt diese locking tatsächlich, aber nicht aus dem grund den er hier nennt - wie gesagt, darum kümmern sich die cpus selber