Mehrere Threads Anhalten/Weiterführen

[SeppJ]

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:

Wie es wirklich ist: Programm läuft unter Windows 95, macht einfach überhaupt keine Speicherfreigaben, und wird daher 1x die Stunde neu gestartet bevor der Speicher voll läuft

Noch eine Stufe darunter mit DOS wäre vielleicht gar nicht mal so verkehrt, wenn man nun wirklich nichts besseres zur Verfügung hat. Unter dem System haben Programme so viel Kontrolle, das ist fast wie direkt in das Programm als eigenes OS booten. Damit lassen sich Echtzeitanforderungen sicherlich recht gut erfüllen - wenn auch ziemlich fummelig, weil das OS halt generell nicht sonderlich viel kann

Ich wollte zuerst auch Win 3.1 schreiben, wegen kooperativem Multitaskings und weil's quasi DOS mit GUI ist, aber hab mir dann gedacht, dass wäre zu obskur
Außerdem hört man immer wieder echte Horrorgeschichten, wie etwa dass irgendwelche U-Boote mit alten Win 9x Computern laufen. Womöglich wegen genau solcher Anforderungen (Win 9x macht auch so gut wie nix im Hintergrund).

[hustbaer]

Ja, so altes DOS/Windows Zeug ist für soft-realtime oft nicht verkehrt. Am besten auf entsprechend alter Hardware.

Bei moderner Hardware kommen dann so Dinge zu Tragen wie @VLSI_Akiko angesprochen hat. Da werden dann gerne CPU oder Chipset Bugs maskiert indem die "CPU Firmware" das System so konfiguriert dass z.B. ein NMI ausgelöst wird wenn ein bestimmtes Register geschrieben wird, und da drin läuft dann Code der irgendeinen Workaround macht.

Soweit ich weiss sind sogar Sachen wie Rechnungen mit Denormals in modernen CPUs so implementiert dass irgend ein Interrupt ausgelöst wird wo das Ergebnis dann per Software ausgerechnet wird. Daher sollte man Denormals auch immer deaktivieren wenn man sie nicht braucht und die Berechnung zeitkritisch ist. Sonst kann es schnell passieren dass man z.B. tausende Nullen auf einen Akkumulatur draufaddiert der gerade einen Denormal-Wert hat. Und dadurch dann tausende Male den Overhead für die Software-Berechnung bezahlt.

Das kann einem dann auch unter DOS/... unerwartete Verzögerungen spendieren.

[Finnegan]

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Da werden dann gerne CPU oder Chipset Bugs maskiert indem die "CPU Firmware" das System so konfiguriert dass z.B. ein NMI ausgelöst wird wenn ein bestimmtes Register geschrieben wird, und da drin läuft dann Code der irgendeinen Workaround macht.

Ui, danke für die Info. Das war mir noch nicht bekannt. Ich habe bisher immer gedacht, dass bei CPU-Instruktionen auf Registern bestenfalls mehr oder weniger umfangreicher Mikrocode zur Ausführung kommt. Mit Ausnahme natürlich von General Protection Fault und Division durch 0 Handlern und sowas.

[VLSI_Akiko]

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Naja... die Grenzen sind da ein bisschen verschwommen denke ich. Also was ist eine "reine Hardwarelösung" und was nicht?

S390 oder zSeries Hardwarepartitionierung, aber Mainframes sind eine gaaaanz andere Geschichte. Aber grob kann man sagen, dass alles was unveränderlich in der CPU steck, ist Hardware. Dazu unten ein wenig mehr ...

Schon CPUs wie der 6502 haben ein Instruction-ROM über das eine Instruction in mehrere Teile aufgesplittet wird. Ist das noch rein Hardware, weil's ein ROM ist?

Ist Hardware, gibt Leute die Machen decapping von CPU/ROMs, fotografieren die Muster (Transistoren im Silizium) ab und übersetzen die Bitmasken mit einer Bildanalyse zurück in Code bzw Logikgatter. Ist quasi die Oberliga was reverse-engineering angeht. Kann man sich übrigends auch auf Youtube anschauen, bzw ist jedes Jahr beim CCC gefühlt ein Vortrag dabei, wo das gezeigt wird.

Spätere CPUs haben dann Microcode, was im Prinzip auch nix anderes ist bzw. nur eine konsequente fortführung des
selbem Prinzips. Ist das noch rein Hardware? Was wenn man den Microcode updaten kann? Dann ist es kein ROM mehr?

Microcode ist ein Lösung, die schon vor langer Zeit eingeführt wurde, um während der Produktion noch schnell Änderungen durchführen zu können. Eines der besten Beispiele für diese Weitsicht ist (ja, okay, ich mag das Teil ) der Motorola 68000 (1979). Das was dir als Microcode Update verkauft wird, updated nicht den Microcode in der CPU, sonst müsstest du ihn nicht in den BIOS integrieren oder wie bei Linux/BSD beim Booten als ucode laden.

Immer noch rein Hardware? Und spätestens wenn man Virtualisierung in irgendeiner Form implementieren möchte, was schon bei einer MMU anfängt, werden die Dinge die zum Abarbeiten von einfachen Instruktionen oder auch nur Speicherzugriffen nötig sind ziemlich komplex.

Ja und nein, eine MMU arbeitet eigentlich transparent zur CPU. Das wird ziemlich offensichtlich, wenn du ein System hast, wo CPU und MMU noch getrennte Bausteine sind. Ist es komplex? Oh ja, liegt aber größtenteils daran, dass es heutzutage so gut wie keine CPU mehr gibt, die kein Pipelining umsetzt.

Da kann es schon Sinn machen das nicht mehr alles über klassischen Microcode zu machen sondern eine Abstraktionsebene darüber anzusetzen - nur halt mit Code der nicht vom OS kommt sondern quasi direkt in die CPU mit eingebaut ist. Bzw. aus dem UEFIA/BIOS kommt (AGESA & Co).

Es gab da ja sehr nett klingende Versuche (die in der Praxis aber schiefgingen). Ein Beispiel hierfür wäre der VLIW Prozessor Transmeta. Was sich in der Richtung letztendlich durchgesetzt hat sind CLPDs und FPGAs.

Und dass die Chip-Hersteller das nicht open-sourcen wollen ist denke ich auch klar, es würde ja viel darüber verraten wie diese Features in ihren CPUs umgesetzt sind.

Wie die Features umgesetzt sind, kannst du in den Patenten nachlesen. Ich kann dir sagen warum da kaum jemand open-sourcen will. Einerseits sind es die Errata. Da sind nämlich ein paar Sachen dabei, die rechtliche Schritte ermöglichen würden. Und andererseits ein sehr beliebter Grund ist Intellectual Property (siehe Nvidia/3Dfx - manchmal ist es besser die "geklaute" Technologie zu kaufen, statt einen riesigen Prozess zu verlieren). Du kannst heute eigentlich keine neuen CPUs mehr designen ohne die Patente anderer zu verletzen. Ist genau wie bei der Entwicklung von Videocodecs, da wird alles mit Patenten "unterbunden/kontrolliert".

Genau das ist der Punk, man kann es nicht 100% abdrehen. Ohne das funktionieren heutige (x86) CPUs einfach nicht mehr.

Bist du sicher was den 2. Punkt angeht? Ich hätte angenommen dass moderne x86 CPUs problemlos ohne dieses Management-OS im PCH/Chipset/... auskommen.

Ja, bin ich, was x86 angeht. Der Platform Supportcode ist mehr als nur das Management-OS. Im Fall der Radeon Grafikkarten und deren ATOM BIOS ist es der darin verbaute ARM Prozessor. Hier liefert ein Teil des ATOM Bios die Trusted Firmware für den Trustzone Teil, ohne den die GPU nicht initialisiert. So ziemlich die gleichen ARM Cores stecken im PSP (Platform Support Processor) der Ryzen CPU's. Der ARM Core da drin ist für eine Authentifizierung zuständig. Der Ryzen tut nämlich bevor er mit dem Laden des BIOS/UEFI beginnt erstmal sicherstellen ob er selber legal ist und das Ganze darf. Alles Mechanismen um zu verhindern, dass da jemand etwas nachbaut oder einfach kopiert.

Achtung Geschichtsstunde: Deswegen konnten ja damals SIS/AMD/Cyrix/Rise die ganzen CPUs ja nachbauen und das stellenweise besser. Und Intel konnte nichts machen, weil man Nummern nicht markenrechtlich schützen kann. Deswegen der Name Pentium stat 80586. Und siehe da, die nächste 586 basierte CPU von AMD (k5) hatte Anfang echt Probleme mit dem Pentium mitzuhalten, weil sie nicht mehr ohne Konsequenten kopieren konnten. Die haben dann einfach das EV6 Protokoll von DEC (Alpha) lizensiert und damit die Athlons aufgebaut. Als sie dann noch etwa die Hälfte der Alpha Ingenieure übernommen hatten, hatten die plötzlichen einen Athlon, der ganz schön abging. Geschichtsstunde Ende. (Frag lieber nicht, mein ganzes Leben besteht nur aus Computerkram.)

Jendenfalls diese binären Blobs, die da in den kleinen SRAM vom ARM Core geladen werden (oder schlimmer, in die ROMS gebrannt sind*), sind das Problem. Die müssen da sein, oder die CPU beendet ihre Initialisierungphase nicht. Es gibt nur wenige CPUs, die so ein Blödsinn (es wird einem gerne als Secureboot und Co. verkauft) nicht machen, da wäre die chinesische MIPS CPU Loongson/Godson oder amüsanterweise auch die fetten POWER9 Prozessoren von IBM. (Deswegen gibt es die POWER9 Talos Workstation von Raptor Computing komplett ohne binäre Blobs.)

• Es gibt einige Smartphones und Nintendo Geräte wo dieser ROM im ARM Bugs enthält, aufgrund dessen der Herstellen Securitylöcher nicht schließen kann und sich die "Raubkopierer" um diese Geäte auf Ebay kloppen.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Lustig, das ist exakt eines der Spiele, wo mir der GC ebenfalls negativ aufgfallen ist. Es kommt nicht immer vor, aber bei manchen fortgeschrittenen Spielständen kommt es manchmal zu diesen regelmässigen Sekunden-Aussetzern alle paar Sekunden. Das ist extrem nervig. Das Ruckeln an sich ist nicht ganz so wild, sondern vor allem dass es oft dazu führt, dass man letztendlich wegen dem Aussetzer bei einer komplexen Maschine an eine falsche Stelle klickt und sich dabei schonmal gehörig was kaputt macht, wenn nach dem Fehlklick giftiges heißes Gas oder flüssige Lava in die Basis strömen

Ja genau, nicht wahr? Das ist so nervtötend. Und wenn du dann noch jemand bist, der gerne diese Glühwürmchenrektoren baut, wo du zum Schluss 60+ Glühwürmchen in je einem Feld hast (und davon locker 10), da merkste dann so richtig warum man Spiele nicht in C# schreibt. Da kannst du 10 GHz haben und deine Framerate geht trotzdem unter 20 fps. Schau dir mal im Vergleich dazu Dwarf Fortress an. Das simuliert locker 100 mal mehr Aspekte in einer viel größeren Welt und läuft trotzdem deutlich besser.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Stelle mir gerade eine Steuersoftware für einen Chirurgieroboter vor, bei der man sich regelmässig wegen dem GC "verklickt"

Ich kenne es genau umgekehrt. In der Atomindustrie wurden die analog aufgebauten Schaltkreise im Containment vor ca 30+ Jahren durch Computer ersetzt. Vor 10 Jahren waren das noch PIC-MG Industriekarten, auf denen K6-3 verbaut waren (die haben die geringste Latenzabweichung bei Abarbeitung der immer selben Algorithmen - ein Problem von Caches und Superskalarität und out-of-order execution) auf denen nur Baremetal Programme liefen, die selten größer als 50 KB waren. Da wo es drauf ankommt, ist man sich der Probleme bewusst. Will damit sagen, ich denke nicht, dass so ein Chirogencomputer auch nur eine Etappe bei der Zulassung/Zertifizierung überleben würde. Naja, wie ich schon in einem meiner ersten Posts angedeutet habe, ich kann da stundenlang zu erzählen. Ich habe einfach überall da gearbeitet, wo es mal so richtig ans Eingemachte ging. Hint: Aktuell arbeite ich an Geräten, wo FPGAs als Coprozessoren verwendet werden um Timestamping und Timing in Nanosekundenbereich akurat und nachvollziehbar zu realisieren. Wir bauen auch unsere eigenen Bios, der komplett verriegelt wird und sich selbst prüft.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Was mir an DOS immer gut gefallen hat ist, dass man damit Dinge stricken kann, die sonst nur gehen, wenn man ein eigenes OS baut - ohne den Aufwand tatsächlich ein eigenes OS programmieren zu müssen.

Oh, da dürfte dir eventell Pure64 und BaremetalOS von ReturnInfinity eine Menge Spaß machen.

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Soweit ich weiss sind sogar Sachen wie Rechnungen mit Denormals in modernen CPUs so implementiert dass irgend ein Interrupt ausgelöst wird wo das Ergebnis dann per Software ausgerechnet wird. Daher sollte man Denormals auch immer deaktivieren wenn man sie nicht braucht und die Berechnung zeitkritisch ist.

Geht noch viel lustiger. Man nutzt einfach Traps/Interrupts um gewisse Aspekte in Software umzusetzen, statt in Hardware. Suche einfach mal nach 32 Bit ARM und 64Bit Divisionen, ich garantiere dir einen WTF?!?-Moment.

[hustbaer]

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Da werden dann gerne CPU oder Chipset Bugs maskiert indem die "CPU Firmware" das System so konfiguriert dass z.B. ein NMI ausgelöst wird wenn ein bestimmtes Register geschrieben wird, und da drin läuft dann Code der irgendeinen Workaround macht.

Ui, danke für die Info. Das war mir noch nicht bekannt. Ich habe bisher immer gedacht, dass bei CPU-Instruktionen auf Registern bestenfalls mehr oder weniger umfangreicher Mikrocode zur Ausführung kommt. Mit Ausnahme natürlich von General Protection Fault und Division durch 0 Handlern und sowas.

Upps, sorry, das war misverständlich. Ich meinte mit Register kein CPU Register sondern ein Register irgend eines Hardwarebausteins, z.b. im Chipset. Wie genau das Maskieren von CPU Bugs geht weiss ich nicht. Vermutlich gehört da zumindest ein Microcode-Update dazu.

[hustbaer]

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Microcode ist ein Lösung, die schon vor langer Zeit eingeführt wurde, um während der Produktion noch schnell Änderungen durchführen zu können. Eines der besten Beispiele für diese Weitsicht ist (ja, okay, ich mag das Teil ) der Motorola 68000 (1979). Das was dir als Microcode Update verkauft wird, updated nicht den Microcode in der CPU, sonst müsstest du ihn nicht in den BIOS integrieren oder wie bei Linux/BSD beim Booten als ucode laden.

Ich dachte das liegt daran, dass die CPU einfach keinen nicht-flüchtigen Speicher dafür hat. Das liest man so auch öfter im Netz. Würde mich auf jeden Fall wundern wenn die mit Microcode Updates nicht auch wirklich am Microcode der CPU rumdoktorn. Wäre ja doch ziemlich hilfreich wenn das ginge. Und es würde mich wundern wenn es nicht gehen sollte.

Ja, bin ich, was x86 angeht. Der Platform Supportcode ist mehr als nur das Management-OS.

OK. Aber zumindest das Management-OS sollte man abdrehen können ohne dass die CPU Probleme bekommt.

Geht noch viel lustiger. Man nutzt einfach Traps/Interrupts um gewisse Aspekte in Software umzusetzen, statt in Hardware.

Rechnen mit Denormals ist doch genau sowas. Das betrifft ja ganz normale Maschinensprachbefehle, das ganze x87 Zeugs halt. x87 interessiert heute kaum mehr jemanden der wirklich Performance braucht, und daher gibt es auch keinen guten Grund für etwas wie Denormals viele Transistoren zu verbraten. Daher löst man es lieber so dass man der CPU "in Hardware" nur beibringt "Hilfe!" zu schreien, und irgend ein Trap/Interrupt Handler macht das dann "in Software".

Aber egal. Ist immer interessant weitere Beispiele zu hören/lesen.

[Finnegan]

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Microcode ist ein Lösung, die schon vor langer Zeit eingeführt wurde, um während der Produktion noch schnell Änderungen durchführen zu können. Eines der besten Beispiele für diese Weitsicht ist (ja, okay, ich mag das Teil ) der Motorola 68000 (1979). Das was dir als Microcode Update verkauft wird, updated nicht den Microcode in der CPU, sonst müsstest du ihn nicht in den BIOS integrieren oder wie bei Linux/BSD beim Booten als ucode laden.

Echt? Ich hätte jetzt gedacht, dass Mikrocode in der CPU in einem flüchtigen Speicher liegt, in den bei der CPU-Initialisierung geaden wird. Dass dieser Code Teil des BIOS-ROMs ist oder sogar vom OS geladen wird hat mich daher bisher nicht verwundert. oder hab ich das was missverstanden?

Du kannst heute eigentlich keine neuen CPUs mehr designen ohne die Patente anderer zu verletzen. Ist genau wie bei der Entwicklung von Videocodecs, da wird alles mit Patenten "unterbunden/kontrolliert".

Ziemliche Innovationsbremse IMHO. Vor allem wenn man als kleiner Entwickler mit frischen Verbesserungsideen neu in so einen Markt einsteigen will. Es gibt sicherlich einige Erfindungen, bei denen es so hohe Entwicklungskosten gab, dass sich der Schutz rechtfertigen lässt. Leider gibt es aber auch viel zu viele "Patente" auf die man intuitiv und unabhängig selbst kam, nachem man eine halbe Stude über ein Problem nachgedacht hat. Nur um dann festzustellen, dass es schon jemand patentiert hat

Der Ryzen tut nämlich bevor er mit dem Laden des BIOS/UEFI beginnt erstmal sicherstellen ob er selber legal ist und das Ganze darf. Alles Mechanismen um zu verhindern, dass da jemand etwas nachbaut oder einfach kopiert.

Doofe Frage: Werden Chips tatsächlich kopiert wie das ein desinteressierter Informatik-Erstemester tun würde? Copy+Paste ohne zu verstehen, was da passiert? Wäre es nicht ein leichtes, den Verifikationsmechanismus entweder wegzulassen oder so zu modifizieren, dass er auch meine Kopie akzeptiert?

...

Achtung Geschichtsstunde: Deswegen konnten ja damals SIS/AMD/Cyrix/Rise die ganzen CPUs ja nachbauen und das stellenweise besser.

... die Antwort ist vermutlich "Nein"

Schau dir mal im Vergleich dazu Dwarf Fortress an. Das simuliert locker 100 mal mehr Aspekte in einer viel größeren Welt und läuft trotzdem deutlich besser.

Factorio ist auch ein Beispiel, das bezüglich exzellenter Performance bei riesigen Welten mit komplexen Maschinen besonders hervorsticht. Interessant ist bei Factorio auch der Netzwerkcode - das Spiel verursacht im Multiplayer nur minimalsten Traffic. Da fährt jeder Client seine eigene, reproduzierbare Simulation und lediglich die User-Eingaben werden übers Netzwerk synchronisiert. Wenn zwei Computer das gleiche berechnen, sollten sie schliesslich auch zum gleichen Ergebnis kommen*, da muss man nicht jeden Zwischenschritt übers Netzwerk übertragen.

(* Bei Fliesskommaoperationen kann das allerdings schonmal etwas haarig werden. Besonders wenn die Clients auch noch unterschiedliche CPU-Architekturen fahren)

Hint: Aktuell arbeite ich an Geräten, wo FPGAs als Coprozessoren verwendet werden um Timestamping und Timing in Nanosekundenbereich akurat und nachvollziehbar zu realisieren.

Das klingt schon recht anspruchsvoll. Mir würden ja schon zuverlässige 16ms reichen, damit bei 60fps der nächste Frame rechtzeitig fertig wird

Oh, da dürfte dir eventell Pure64 und BaremetalOS von ReturnInfinity eine Menge Spaß machen.

Ich hatte schon den Verdacht, dass es da sowas geben muss. Nicht immer braucht oder will man den Overhead, den ein ausgewachsenes OS mitbringt. Von BaremetalOS habe ich auf jeden Fall schonmal gehört. Schau ich mir vielleicht mal an für ein paar Hobby-Spielereien

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Upps, sorry, das war misverständlich. Ich meinte mit Register kein CPU Register sondern ein Register irgend eines Hardwarebausteins, z.b. im Chipset. Wie genau das Maskieren von CPU Bugs geht weiss ich nicht. Vermutlich gehört da zumindest ein Microcode-Update dazu.

Ah verstehe. Mache nicht viel mit Hardware, aber diese "Register" sind mir schon ein Begriff.

[VLSI_Akiko]

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Ich dachte das liegt daran, dass die CPU einfach keinen nicht-flüchtigen Speicher dafür hat. Das liest man so auch öfter im Netz. Würde mich auf jeden Fall wundern wenn die mit Microcode Updates nicht auch wirklich am Microcode der CPU rumdoktorn. Wäre ja doch ziemlich hilfreich wenn das ginge. Und es würde mich wundern wenn es nicht gehen sollte.

Da ist mir nichts bekannt, dass es da eine Art Flash oder so für x86 CPU's gibt. Wäre ja auch fatal, wenn man sowas direkt in die CPU "brennen" könnte, denk da nur mal Malware, uiuiui... Es gibt allerdings ein paar ARMs die sowas haben.

OK. Aber zumindest das Management-OS sollte man abdrehen können ohne dass die CPU Probleme bekommt.

Ja, da gibt es dank dieser reverse-engineering Geschichten mitlerweile Tools, die diese Sachen aus BIOS Update Images und wohl auch aus dem BIOS-Flash direkt "rauschneiden" können. Oder du nutzt Coreboot/Libreboot. Ich habe Libreboot auf einem ASUS KGPE-16D (dual Sockel G34 - Opterons) laufen, musste dafür meine eigenen SPI Flash zurechtfriemeln. Alles andere als spaßig und was noch viel schlimmer ist. Es ist alles autoconfig, es gibt kein Bios-Menu, nichts was du einstellen kannst. Und die Stabilität ist, naja, bescheiden, von 128GB DDR3 reg ECC werden zum Beispiel nur 64 erkannt und so weiter.

Rechnen mit Denormals ist doch genau sowas. Das betrifft ja ganz normale Maschinensprachbefehle, das ganze x87 Zeugs halt. x87 interessiert heute kaum mehr jemanden der wirklich Performance braucht, und daher gibt es auch keinen guten Grund für etwas wie Denormals viele Transistoren zu verbraten. Daher löst man es lieber so dass man der CPU "in Hardware" nur beibringt "Hilfe!" zu schreien, und irgend ein Trap/Interrupt Handler macht das dann "in Software".

Ich glaube hier gibts ein kleines Missverständnis. Ich meine die div und udiv Opcode, also Integer Divisionen. 64 Bit Integerdivisionen gehen auf nahezu jeder 32 Bit CPU in Hardware, außer eben vielen 32 Bit ARMS ... und ja, das gilt auch für die Cortex-A Reihe. Das Ganze sieht dann so aus, wenn es mal wieder jemand in seinem Treibern vermasselt hat, und ich darfs fixen:

| ERROR: modpost: "__aeabi_ldivmod" [drivers/spi/spi-cadence-quadspi.ko] undefined!
| ERROR: modpost: "__aeabi_uldivmod" [drivers/spi/spi-cadence-quadspi.ko] undefined!

Weil es ein Linkproblem ist, bekommste nicht mal die Information wo es passiert. Nun darf ich jede Division in dem Treiber checken und dann durch die Kernelimplementierung ersetzen.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Echt? Ich hätte jetzt gedacht, dass Mikrocode in der CPU in einem flüchtigen Speicher liegt, in den bei der CPU-Initialisierung geaden wird. Dass dieser Code Teil des BIOS-ROMs ist oder sogar vom OS geladen wird hat mich daher bisher nicht verwundert. oder hab ich das was missverstanden?

Nein, es gibt einen "festeingebrannten" Microcode der hoffentlich bugfrei ist und während der Laufzeit geupdated werden kann, indem einfach "Pointer" auf den neuen Code umgelenkt werden. Es kann gut sein, dass die CPU einen kleinen versteckten SRAM Bereich hat (oder eben einer der Caches), wo der Microcode reingeladen wird. Sowas über den normalen RAM zu machen ist ein bisschen bescheuert, weils einfach zu langsam wäre. Kannst es dir ein wenig wie BIOS shadowing vorstellen, nur dass nicht in den RAM sondern in so einen kleines SRAM/Cache geshadowed wird. Sind die Bugs im Microcode zu krass, gibts ein neues Stepping der CPU. Oft werden auf diese Weise auch Sachen verborgen, die noch in der CPU sind. Kannst du dich noch an 3DNOW/3DNOW! aus den K6 CPUs und frühen Athlons erinnern, oder an das FMA4 aus den Bulldozer/Piledriver/Excavator CPUs? Alle Ryzen CPUs können das ohne Probleme, da ist es nur per Microcode aus der CPU-Flags Liste rausgenommen worden.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Ziemliche Innovationsbremse IMHO. Vor allem wenn man als kleiner Entwickler mit frischen Verbesserungsideen neu in so einen Markt einsteigen will. Es gibt sicherlich einige Erfindungen, bei denen es so hohe Entwicklungskosten gab, dass sich der Schutz rechtfertigen lässt. Leider gibt es aber auch viel zu viele "Patente" auf die man intuitiv und unabhängig selbst kam, nachem man eine halbe Stude über ein Problem nachgedacht hat. Nur um dann festzustellen, dass es schon jemand patentiert hat

Ursprünglich war das Patentsystem dafür gedacht, dass du zumindest deine Entwicklungskosten wieder reinholen kannst. Es war zeitlich stark begrenzt (5-10 Jahre? keine Ahnung). Aber irgendwann wurde das komplett pervertiert und es gibt da einige Player, die da stark dazu beitragen (* hust * Nvidia, Oracle).

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

(* Bei Fliesskommaoperationen kann das allerdings schonmal etwas haarig werden. Besonders wenn die Clients auch noch unterschiedliche CPU-Architekturen fahren)

Das sollte eigentlich nicht vorkommen, dafür gibt es ja eben die IEEE754 Spec an die sich alle aktuellen CPU's halten. Ich kann mir vorstellen, dass sowas nur passiert wenn du auf der einen Architektur alles/einiges in floats machst und auf anderen in doubles.

@Finnegan sagte in Mehrere Threads Anhalten/Weiterführen:

Das klingt schon recht anspruchsvoll. Mir würden ja schon zuverlässige 16ms reichen, damit bei 60fps der nächste Frame rechtzeitig fertig wird

Naja, hier gehts halt darum ob du nen Knöllchen für 15 km/h oder 200 km/h zu schnell bekommst. * duck * Es geht im Prinzip um Existenzen (Führerscheinverlust) und da werden keine halbe Sachen gemacht. Ein anderes Szenario ist das Erkennen von 500 Nummernschildern pro Minute aus 50 Megapixel Bildern mit einer Erfolgsrate von 95%+ auf 3-4 Spuren mit bis zu 8 Kameras. Gibts da irgendwo auch nur 50 Mikrosekunden Verzögerung, sind die ganzen Messvorgänge für die Katz. (Ist auch ohne DSPs oder FPGAs nicht mehr machbar.)

[hustbaer]

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Da ist mir nichts bekannt, dass es da eine Art Flash oder so für x86 CPU's gibt. Wäre ja auch fatal, wenn man sowas direkt in die CPU "brennen" könnte, denk da nur mal Malware, uiuiui... Es gibt allerdings ein paar ARMs die sowas haben.

Ja, eben. Und genau weil x86 CPUs kein solches Flash haben, muss man die Microcode Updates bei jedem Boot neu über's BIOS/UEFI einspielen. Dass es im BIOS/UEFI steht ist also kein Argument dafür dass die Microcode Updates "nicht wirklich Microcode in der CPU updaten".

Ich glaube hier gibts ein kleines Missverständnis. Ich meine die div und udiv Opcode, also Integer Divisionen. 64 Bit Integerdivisionen gehen auf nahezu jeder 32 Bit CPU in Hardware, außer eben vielen 32 Bit ARMS ... und ja, das gilt auch für die Cortex-A Reihe. Das Ganze sieht dann so aus, wenn es mal wieder jemand in seinem Treibern vermasselt hat, und ich darfs fixen:

Ich hatte schon verstanden dass du Integerdivisionen meinst. Ich meine nur: ob jetzt wie bei ARM die Integerdivisionen fehlt, oder wie bei x86 nur die Fähigkeit mit Denormals zu rechnen - beides sind für mich Beispiele von fehlenden Features.

Ursprünglich war das Patentsystem dafür gedacht, dass du zumindest deine Entwicklungskosten wieder reinholen kannst. Es war zeitlich stark begrenzt (5-10 Jahre? keine Ahnung)

Patente in D und AT sind aktuell für max. 20 Jahre gültig. Lange, aber immer noch sehr vernünftig verglichen mit z.B. dem amerikanischen Copyright, welches aktuell für 70 Jahre nach dem Tod des Verfassers gilt.

Das sollte eigentlich nicht vorkommen, dafür gibt es ja eben die IEEE754 Spec an die sich alle aktuellen CPU's halten.

Soweit ich weiss sind die ganzen SIMD Geschichten in aktuellen CPUs nicht IEEE-konform. Eben weil bei Sachen wie Denormals die Kosten/Nutzen Rechnung nicht passt. Bei x86 gibt's immer noch die ganzen x87 Instruktionen wenn man IEEE braucht. Bei anderen Architekturen: keine Ahnung.

[VLSI_Akiko]

@hustbaer sagte in Mehrere Threads Anhalten/Weiterführen:

Soweit ich weiss sind die ganzen SIMD Geschichten in aktuellen CPUs nicht IEEE-konform. Eben weil bei Sachen wie Denormals die Kosten/Nutzen Rechnung nicht passt. Bei x86 gibt's immer noch die ganzen x87 Instruktionen wenn man IEEE braucht. Bei anderen Architekturen: keine Ahnung.

Ahh, wie reden von SIMD Units und nicht von den FPUs. Ja, dass ist eine andere Geschichte aber auch die lassen sich konfigurieren. Da gibt es richtig Opcodes für um die richtig einzustellen. Wobei, ARMs NEON ist 100% ieee754 konform und das gilt wohl auch für SSE/AVX. Oh schau an, Agner Fog hat dazu auch was zu sagen. Das Problem ist wohl die OoO execution innerhalb der SIMD Units. Man lernt eben nie aus.

[Enumerator]

So, jetzt aber genug der Anekdoten. Zurück zum Thema :). Tatsächlich geht es um einen GC in C++ und ich will die Stop-The-World Pausen reduzieren. Da wurden ja zuletzt mit Java beachtliche Verbesserugnen des GC erreicht . Siehe z. B. ZGC. Und da Java meines Wissens nach in C++ programmiert ist muss das ja irgendwie erreicht werden können? Meine alternative Idee um die Threads möglichst schnell zu stoppen wäre in z.B. Operatoren oder Funktionen die möglichst häufig verwendet werden eine Write-Barrier zu implementieren, die die Threads stoppt. Aber leider gibt es ja keine z. B. globalen operator* oder operator& die sich angeboten hätten. Und alle paar Zeilen im Code eine "GCStopThread();" Funktion oder so ähnlich aufzurufen ist auch nicht praktikabel.

[SeppJ]

Wir stellen also fest, deine eigentliche Frage war "Habt ihr Ideen, wie man einen GC schreiben kann, der fühlbare Ausführungsstops vermeidet?". Und weder ist überhaupt gesagt, wieso dein Ansatz aus dem ersten Beitrag überhaupt eine Lösung sein sollte, noch woher du die strikten Anforderungen aus dem ersten Beitrag zauberst. Man hätte sich die ganze Exkursion über die Echtzeitfähigkeit von Computern also sparen können, wenn du nur endlich lernen würdest, nach deinen eigentlichen Problemen zu fragen.

[VLSI_Akiko]

Hmm, das ist in der Tat eine ganz andere Frage. Manager für Smartpointer schreiben. Wrapper um Smartpointer schreiben, sodass jeder Smartpointer, der angelegt wird, als Owner auch den Manager bekommt. Manager schaut periodisch nach den Refcounts im Smartpointer, ist er 1, Smartpointer aus des Managers Liste schmeißen. Manager sollte selbst eine Heuristik bekommen, anhand er "beurteilen" kann, ob gerade ein guter Zeitpunkt ist, wie zum Beispiel spezieller Zustand des Programms, wo bekannt ist, dass gerade nicht viel passiert, oder vor Freigabeaktionen CPU-Last oder I/O Last checken. Das "Pausieren" (yields) der Threads an Conditionvariablen hängen, bzw ab C++20 atomic_flags verwenden (sind signifikant performanter). Eventuell könnte man auch die C++20 std::stop_token um Pausieren erweitern, ist allerdings etwas komplizierter. Hmm, bin schon fast versucht selbst was zu Basteln.

[zeropage]

@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:

Man hätte sich die ganze Exkursion über die Echtzeitfähigkeit von Computern also sparen können,

Das war aber schon interessant

[SeppJ]

@zeropage sagte in Mehrere Threads Anhalten/Weiterführen:

@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:

Man hätte sich die ganze Exkursion über die Echtzeitfähigkeit von Computern also sparen können,

Das war aber schon interessant

Für uns ja, fand ich auch

Aber Enumerator hat's überhauypt nichts für sein Problem gebracht. Nun, wo die eigentliche Frage endlich raus ist, haben viele den Thread sicherlich schon als durchdiskutiert abgehakt. Und wer neu ist oder trotzdem noch mitliest, muss in all der Nebensdiskussion den einen Beitrag mit der eigentlichen Frage herauspicken.

[VLSI_Akiko]

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Hmm, bin schon fast versucht selbst was zu Basteln.

Jupp, die Versuchung war zu groß, hab angefangen. Wenn Interesse besteht könnte ich ja mal eine Tutorialreihe lostreten, wie man verschiedene Patterns/Designs in modernem C++ aufzieht. (Ich bin jemand der grundsätzlich C++20/C++23 macht.)

@zeropage sagte in Mehrere Threads Anhalten/Weiterführen:

Das war aber schon interessant
@SeppJ sagte in Mehrere Threads Anhalten/Weiterführen:
Für uns ja, fand ich auch

Oh Gott, bringt mich bloß nicht in Versuchung ...

[daMicha]

@VLSI_Akiko
Ich würde Dir gern ein Leckerli geben und Dich hinter den Ohren kraulen, aber irgendwie kann mir mein Hund seine Welt nicht so gut erklären wie Du die Deine. Ich hab jedenfalls ne Menge gelernt und würde das gern auch weiter tun.

[VLSI_Akiko]

Okay, dann versuche ich mal was auf die Beine zu stellen. Haben die Mods irgendwie Idee/Hinweise, wie ich das am besten in Forumform quetsche? Ich dachte ich mache mal ein paar Tutorials/Howtos, welchen modernen Features man kennen sollte und wie man sie am besten benutzt.

[SeppJ]

@VLSI_Akiko sagte in Mehrere Threads Anhalten/Weiterführen:

Okay, dann versuche ich mal was auf die Beine zu stellen. Haben die Mods irgendwie Idee/Hinweise, wie ich das am besten in Forumform quetsche? Ich dachte ich mache mal ein paar Tutorials/Howtos, welchen modernen Features man kennen sollte und wie man sie am besten benutzt.

Uff, gute Frage. Es gab mal das Magazin dafür, aber das machen wir nicht mehr so. Derzeit haben wir kein extra Unterforum für Qualitätsartikel. Wir haben nur die Standardmittel eines jeden Forums um Qualitätsbeiträge hervorzuheben. Also gepinnte Threads (wenn du alles in einen Thread packst) oder Links von einem zentralen, gepinnten Thread auf mehrere normale Unterthreads.

[hustbaer]

Wenn ich heutzutage sowas schreiben würde, würde ich vielleicht sowas wie ein GitHub Repo mit Markdown files machen.