@Gelöschter Nutzer schrieb: netzwerkkarten kann man simulieren, cpus nicht?! Hmmmmm. Da kriege ich wieder Ärger, wenn ich das beantworte. Also bitte, TRIGGERWARNUNG: Grob vereinfachter technischer Zusammenhang. Die Idee mit dem Mikrorozessor kann man sich ja so vorstellen wie so eine automatische Orgel: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwiRxoG1nKn1AhUUSPEDHVzvCXAQwqsBegQIBhAB&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DZBP1anbfmeQ&usg=AOvVaw1SYVWmgoZjZO21V-dUvUAJ Genau dieses fahrbare Ding, "De Korsikaan", habe ich einmal in Neuwied gesehen, die Musik war fast so kläglich wie Igor Lewits Versuch über die Waldsteinsonate, aber das Innenleben sah interessant aus: Es gab dort einen "Lochkartenleser", für jede der Orgelpfeifen gab es eine Spalte und die überdimensionalen "Lochkarten" waren zieharmonikaartig zusammengefaltet und mit Scharnieren verbunden. Setzte man das ganze in Betrieb, mit einem konstanten Vorschub, dann spielte die Orgel ein durchaus kompliziertes Stück. DAS war die Grundidee eines Mikroprozessors: Lese einen Befehl aus dem Speicher aus, bringe ihn zur Ausführung und lese dann den nächsten Befehl. So funktionierte schon der Intel 8008. Habe ich noch dran gearbeitet, KIENZLE 1100, unter anderem ein Erfassungsprogramm für den DATEV-Wettbewerber ZBL, "Zentralbüro für Lochkartenverarbeitung". Das erwähne ich, um darzustellen, daß diese Prozessoren schon absolut praxistauglich waren. Es war aber schon so, daß die Damen in der Pilotkanzlei bemängelten, daß sie schneller seien als der "Buchungsapparat". Allerdings kannten jene die "DATEV Komforterfassung" noch nicht, die um den Faktor 10 langsamer ist. Gut, INTEL muß die Beschwerden der Damen aus Menden mitbekommen haben und brachte neue Prozessoren mit zwei genialen Änderungen: - Der Hauptspeicher, seinerzeit typischerweise Magnetkernspeicher, war schweinelahm und begrenzte natürlich die Geschwindigkeit der CPU. Ohne Kommandos keine Aktion. Also baute INTEL eine 'prefetch queue' ein, die Befehle "auf Vorrat" abholte. So konnte nachgeladen werden, während eine zeitaufwendige Operation durchgeführt wurde. Das war der erste Schritt in die "Virtualisierung", der so seine Tücken hatte: Wenn nämlich die CPU an die Speicherstellen schrieb, die sie vorher in der Warteschlange hatte, dann waren diese Operationen faktisch unwirksam und es gab, abhängig vom Sonnenstand und der Bestückung des Computers, fiese und heimtückische Fehler. - Man erfand den 'CISC' - Befehlssatz, es gab also "Metainstruktionen", die gleich ein ganzes Programm ausführten, zum Beispiel "CMPSB": Da wurden zwei Zeichenketten miteinander verglichen, und wenn noch das REP-Präfix gesetzt war, dann so lange, bis die Zeichenketten differierten. Anstatt also den Vergleich mit einer Schleife selbst zu programmieren, delegierte man an dem Mikroprozessor. 'CISC' wurde in den 90ern von "proaktiven" modernen "IT-Pros" fürchterlich verschriien, aber diese Species erkennt eine geniale Lösung nicht einmal, wenn sie ihr auf den Fuß fällt. Zusammenfassung: Schon ein "Intel 8086" war sehr komplex und bestand nicht nur aus Hardware, sondern aus Software. Die war allerdings noch "fest verdrahtet". Richtig verstehen konnte einen solchen Prozessor nur, wer mit ihm auf Augenhöhe kommunizieren konnte, sprich: IN ASSEMBLER. Und wer das Reich des Computers nicht betritt als Assemblerprogrammierer, der wird niemals hineinkommen. In den Worten des Herrn "Sully" Sulenberger, der gegen jede "Automatik" einen havarierten Jet im Hudson notlandete und allen Passagieren das Leben rettete, obwohl das wegen der unterhalb der Tragflächen angeordneten Triebwerke theoretisch völlig unmöglich war: "The more sophisticated a modern aircraft is, the more essential are basic flying skills". Nun wurde der Hauptspeicher rasend schnell, aber die Recheneinheit blieb langsam. Und da kam die nächste geniale Idee, die "Pipeline": Ein Befehl wurde in mehreren Stufen bearbeitet, buchstäblich wie am Fließband. Dadurch wurde die Bearbeitung EINES Befehls langsamer, aber während der Bearbeitung rückten die Folgebefehle quasi auf. Statt also 5 bis 40 Taktzyklen pro Befehl brauchten professionelle CPUs (also jetzt nicht die von Intel) typischerweise nur noch einen einzigen. Das haute 'rein. Bloß: Im Unterschied zur oben angesprochenen Drehorgel müssen innerhalb des "Musikstückes" abhängige Sprünge innerhalb desselben durchgeführt werden. Wenn jetzt die ganze "Pipeline" gut gefüllt ist, dann heißt es bei einem Sprung: "Alles verwerfen und zurück auf Start". Folge: Ein sattes "Loch" von 40 und mehr Taktzyklen. Man konnte mit "geschickter" Programmierung die Performance eines "486er" regelrecht hinrichten. Es reichte allerdings auch die Installation der DATEV-Suite. So wurde dann die "Nebenläufigkeit" erfunden, sprich, es gab 'mal mindestens zwei Pipelines, die spekulativ, vor einer "Weggabelung", beide Wege ausführten. Ein Wahnsinns-Klapperatismus. BIS HEUTE ist es nicht möglich, beispielsweise für vier Aufzüge eine gemeinsame Steuerung zu schreiben, die die Transportzeiten für die Fahrgäste optimiert. Wer einmal in einem Krankenhaus war, der weiß, was ich meine. WIE KOMPLEX ist dann ein System, welches simultan mit zwei Instruktionsströmen jongliert? Man redet von einem "Superskalar- / Superpipelining - System". Dann kamen ganz schlaue Leute auf die Idee, noch mehr Pipelines einzubauen und den Prozessor quasi "in der Hardware" zu wirrtualisieren, sodaß er gleich zwei (bei IBM mittlerweile 😎 unabhängige Programme gleichzeitig ausführen konnte. Das konnte nicht gutgehen: "Spectre resp. Meltdown" nutzen die Technik der Nebenläufigkeit aus, um Schadcode auszuführen. Die Lösung der "Communtiy": Weitgehendes Abschalten der elaborierten Funktionen. Etwa 40% Performance kostet der "Sicherheitspatch" bei Intel und die CPUs überhitzten. Wenn Sie also einen schnellen Intel-Prozessor haben wollen, dann deaktivieren Sie auf jeden Fall die entsprechenden Patches. Damit man überhaupt eine solche Wahnsinnsmaschine (die heute aus mehr als 2 BILLIONEN = 2.000.000.000.000 Transistoren besteht) warten konnte, baute man die Funktionen der Rechnerkerne zurück und lagerte den komplexen Klapperatismus als sogenannten "Microcode" in Software aus. Typischerweise bekommt ein Intel-Prozessor vom "BIOS" oder vom "EFI" gegebenenfalls einen Update. Der Prozessor stellt sich also bereits einer "VMWare" als Gruppe von Prozessoren dar, und abgesehen davon tut er das noch "verkleidet" als "amd64". Tja, und auf einem Sockel befinden sich heute ACHT Prozessoren. Und meistens gibt es noch zwei oder vier Sockel pro Rechner. Dagegen sind unsere vier Katzen richtig pflegeleicht, nicht einmal der berühmte "Sack Flöhe" kommt auch nur in die Nähe dieser Komplexitätshölle. In Beantwortung Ihrer Frage: Bereits die "Hardware" virtualisiert Prozessoren, und wenn Sie nur einen Prozessor erkennen können, dann sollten Sie beim Anbieter rückfragen. Insbesondere ist es wünschenswert, daß Sie zwei Prozessoren unterschiedlicher NUMA-Knoten zugewiesen bekommen, weil bei der Intel-Architektur die Speicherbausteine fest den Sockeln zugeordnet sind. Persönlich empfinde ich Ekel und Abscheu vor dem INTEL - Monopolzeugs, aber ich weiß, daß man bei professionellen Plattformen enorme Prformancegewinne erzielen kann, wenn man Gast-VMs ganz gezielt CPUs und Ressourcen zuweist. Da brauchen Sie aber einen Top-Partner. Der Metallposaunist, dem ich es zutraue, hat im Moment "Sendepause" angekündigt. So, in eigener Sache: Als ich mit dem Schreiben begann, habe ich nicht einmal geahnt, wie umfassend eine erklärende Antwort sein könnte. Beim Schreiben ist meine ganze berufliche Laufbahn an mir vorbeigezogen, Eigentlich müßte ich das alles löschen und neuschreiben, aber lassen Sie mir die Sentimentalität: Schon bei meinem ersten Auftrag, den ich 1976 als 16jähriger Junge bekam, habe ich darunter gelitten, nicht die Performance abliefern zu können, die der Kunde sich vorgestellt hatte. Und immer wieder mußte ich feststellen: "Die Software wird schneller langsam als die Hardware schneller wird" (N. Wirth). Oder: https://kalliope.org/da/text/goethe2000010804
... Mehr anzeigen