Mehrere Threads Anhalten/Weiterführen

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.

VLSI_Akiko

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

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.

Also ich dachte da an ein Thread pro Topic, wobei ich da den ersten Post auf den laufenden halte. Alles an einem Stück zu schreiben ist je nach Thema ein bisschen viel, außerdem mache ich ja auch Fehler usw. Aber so etwas wie eine Unterkategorie (in C++) wie "Tutorials & Howtos" wäre ganz nett. Also dann eventuell später um da alles hinzuschieben, gibt bestimmt noch mehr, die was beitragen wollen. (Oder ich bin der einzige Idiot, der seine Freizeit opfert und anderen was beibringen will )

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

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

Hmm, ich möchte eigentlich nicht noch einen weiteren Github Account anlegen. Ich verliere langsame den Überblick über meine Keys. Und ob ich meinen zentralen Github hier verlinke... hmm, weiß nicht.

SeppJ

Github klingt durchaus nach einer guten Idee für so etwas. Sowohl was die Versionsverwaltung, Diskussionsmöglichkeit, als auch die mögliche Reichweite angeht.

"Diskussionsmöglichkeit" als Vorteil von github mag zwar etwas komisch klingen, wo dies hier doch ein Diskussionsforum ist, aber bei solchen Artikeln möchte man ja gerade keine überbordende Off-Topicdiskussion. Da ist es dann ganz gut, wenn man nur gezielte Bugreports hat, die man als Hauptautor moderieren kann.

hustbaer

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

als auch die mögliche Reichweite angeht.

Genau. Wenn man es dann noch auf Englisch macht, dann haben potentiell noch mehr Leute was davon. Und auf die Kandidaten, die meinen Programmieren wäre was für Leute die kein Englisch können, muss (bzw. sollte) man denke ich eh nicht Rücksicht nehmen.

VLSI_Akiko

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

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

als auch die mögliche Reichweite angeht.

Genau. Wenn man es dann noch auf Englisch macht, dann haben potentiell noch mehr Leute was davon. Und auf die Kandidaten, die meinen Programmieren wäre was für Leute die kein Englisch können, muss (bzw. sollte) man denke ich eh nicht Rücksicht nehmen.

Also ich hatte vor Codefragment zu zeigen, dass muss nicht auf Github und hilft dem Forum hier sicher auch etwas. Vollständige Implementierungen packe ich dann natürlich auf Github.

Also das mit dem Englisch ist ein Trugschluss. Lass mich dir ein Beispiel geben.

p(fritz).
p(hans).
p(karl).

l(B1,B2,B3):-p(B1),p(B2),p(B3),B1\=B2,B2\=B3,B1\=B3,
             B2\=hans,B1\=fritz,B2\=fritz.
             
b(anton).
b(bernd).
b(christian).

l(E,F,T,B,M,K):-b(E), b(F), b(T), b(B), b(M), b(K), 
                E\=F, F\=T, E\=T, B\=M, M\=K, B\=K,
                E\=anton, F\=bernd, E\=B, F=M, K\=bernd.

Hrhr, niemand hat Syntax highlighting dafür, außer vielleicht vim. Ist etwa 25 Jahre alter Code. EDIT: Nein, nicht mal vim kennt es.

Helmut.Jakoby

Lieber @hustbaer ,
ich dachte, es gibt ein deutschsprachiges C++ Forum um gerade Menschen, die nicht so sicher in der englischen Sprache sind, in C++ weiter zu helfen.

Bitte überdenke doch noch mal den Satz "Und auf die Kandidaten, die meinen Programmieren wäre was für Leute die kein Englisch können, muss (bzw. sollte) man denke ich eh nicht Rücksicht nehmen.". Der kommt etwas komisch rüber in einem deutschsprachigen Forum. So ein bisschen von oben herab.
Ich unterstelle mal, dass Du auch schlecht englisch sprechende bzw. schreibende Menscher soweit Intelligenz zumutest, ordentlich programmieren zu können.

Ach so mal so nebenbei, ich bin Legastheniker und bestreite mein Leben als Softwareentwickler. Ich kann ohne Rechtschreibprüfung also nicht mal richtig deutsch.

SeppJ

Ich denke, du missverstehst. Das ist kein Urteil über diese Leute, sondern einfach ein Fakt, dass man ohne fließende Englischkenntnisse (aus egal welchem Grund!) niemals über Amateurniveau hinaus kommen wird. Alle erwähnenswerten Experten schreiben nur auf Englisch (und zwar viel zu viel und viel zu zeitkritisch, als dass man alles übersetzen könnte), daher müssen alle ernsthaften Leser auch Englisch sprechen, wodurch es wieder noch mehr Gründe gibt, exklusiv auf Englisch zu publizieren. Und damit ist auch ein Großteil der Diskussionsplattformen zu dem Thema exklusiv auf Englisch, und alle Dokumentation erst Recht.

Für Anfängertutorials mag es Gründe für andere Sprachen geben, aber auch für jeden Anfänger gilt, dass kurz- bis mittelfristig Englisch Pflicht ist, um über das Anfängerniveau zu wachsen. Das wird auch kein einzelner Beitrag hier im Forum ändern.

(Das gilt nicht nur für Programmierung, sondern für so ziemlich jede Wissenschaft. Würde mich nicht überraschen, wenn das sogar für Germanistik gelten sollte)

hustbaer

@Helmut-Jakoby sagte in Mehrere Threads Anhalten/Weiterführen:

Bitte überdenke doch noch mal den Satz "Und auf die Kandidaten, die meinen Programmieren wäre was für Leute die kein Englisch können, muss (bzw. sollte) man denke ich eh nicht Rücksicht nehmen.". Der kommt etwas komisch rüber in einem deutschsprachigen Forum. So ein bisschen von oben herab.

Ich bin Utilitarist. D.h. ich akzeptiere kleine Ungerechtigkeiten zum Wohl der Vielen.

Die meisten die Programmieren sind junge Leute, und die haben üblicherweise Englisch in der Schule. Wenn sie dann mit 12, 13, 14 ankommen und nach deutschen Artikeln/Tutorials z.T. Programmieren fragen, weil sie sich mit Englisch so schwer tun, dann hab ich dafür halt relativ wenig Sympathie. Sie sind jung genug um noch relativ leicht lernen zu können, und wenn sie das irgendwann beruflich machen wollen, dann sollten sie ausreichend gut Englisch können um Fachartikel z.T. Programmieren lesen & verstehen zu können.

Mit denen, die dann zu faul sind ausreichend Englisch zu lernen, hab ich kein Mitleid. Vermutlich fallen da dann ein paar wenige durch den Raster, die irgendeine komische Lernstörung haben die es ihnen extrem schwer macht Englisch zu lernen, aber nicht so schwer macht Programmieren zu lernen. Und das ist ungerecht, aber das nehme ich in kauf. Womit wir wieder beim Utilitarismus wären.

Ich unterstelle mal, dass Du auch schlecht englisch sprechende bzw. schreibende Menscher soweit Intelligenz zumutest, ordentlich programmieren zu können.

Natürlich. Es geht hier ja nicht um Intelligenz. Es geht darum was mehr Sinn macht: Artikel zum Thema Programmieren auf Deutsch oder auf Englisch zu schreiben.

Und meine Meinung dazu ist ziemlich klar.