expertenaustausch > comp.lang.* > comp.lang.iso-c++

Thomas Koenig (19.10.2019, 19:13)
Wenn man sich den Talk unter mal
anschaut, gehalten vom "Chair of Language Evolution" von C++,
findet man so ab 1:37 ein paar interessante Ideen, u.a.

- Bytes have eight bits
- Endian: little
- sizeof (void *) == 8
- is_iec559 == true // IEEE 754

Der Mensch arbeitet bei Apple, und das passt ja auch ganz gut auf
die Apple-Hardware - wenn 32-bit-Programme in IOS und MacOS nicht
mehr laufen dürfen, dann braucht C++ das ja auch nicht mehr.

Immerhin hat er schon Zweierkomplement für ints durchgedrückt...
Florian Weimer (19.10.2019, 21:24)
* Thomas Koenig:

> Wenn man sich den Talk unter mal
> anschaut, gehalten vom "Chair of Language Evolution" von C++,
> findet man so ab 1:37 ein paar interessante Ideen, u.a.
> - Bytes have eight bits
> - Endian: little
> - sizeof (void *) == 8
> - is_iec559 == true // IEEE 754


Das ist wohl als Provokation gedacht. Big Endian und 32-bit werden so
schnell nicht verschwinden, es gibt immer noch entsprechende neue
Architekturen. POWER hat auf GNU/Linux auch kein IEEE-long double.

> Immerhin hat er schon Zweierkomplement für ints durchgedrückt...


Nicht in dem Sinne, wie es die meisten erwarten. Der Überlauf ist
immer noch undefiniert.
Stefan Reuther (20.10.2019, 10:19)
Am 19.10.2019 um 19:13 schrieb Thomas Koenig:
> Wenn man sich den Talk unter mal
> anschaut, gehalten vom "Chair of Language Evolution" von C++,
> findet man so ab 1:37 ein paar interessante Ideen, u.a.
> - Bytes have eight bits
> - Endian: little
> - sizeof (void *) == 8
> - is_iec559 == true // IEEE 754


Die Audio-Qualität ist irgendwie unterirdisch, aber ich höre da: "These
are kind of jokes, not really but kind of". Also sooo ernst ist das wohl
nicht.

Dass volatile irgendwie nicht zu gebrauchen ist, da gibt's aber auch
ausreichend Tiraden von Linus Torvalds darüber. Insofern kann man da
schon mal über Verbesserungen sprechen. Bei den anderen eher nicht so.

Andererseits gibt es ja schon Programmiersprachen, die 8-bit-Bytes und
IEEE-Float fordern: Java.

Stefan
Bonita Montero (20.10.2019, 15:26)
> Dass volatile irgendwie nicht zu gebrauchen ist, da gibt's aber auch
> ausreichend Tiraden von Linus Torvalds darüber. Insofern kann man da
> schon mal über Verbesserungen sprechen. Bei den anderen eher nicht so.


volatile ist sehr wohl zu gebrauchen. Z.B. gibt es Heap-Allokatoren
wie jemalloc, TCMalloc oder mimalloc, die einen Pointer auf einen
Stack haben auf den andere Threads Speicher den diese freigeben per
locked compare & exchange draufpacken und die Threads denen der
Thread-lokale Heap gehört lesen diesen Wert ohne spezielle Art des
Zugiffs asynchron
Bonita Montero (20.10.2019, 15:31)
> Dass volatile irgendwie nicht zu gebrauchen ist, da gibt's aber auch
> ausreichend Tiraden von Linus Torvalds darüber. Insofern kann man da
> schon mal über Verbesserungen sprechen. Bei den anderen eher nicht so.


volatile ist sehr wohl zu gebrauchen. Z.B. gibt es Heap-Allokatoren
wie jemalloc, TCMalloc oder mimalloc, die einen Pointer auf einen
Stack haben auf den andere Threads Speicher den diese freigeben per
locked compare & exchange draufpacken und die Threads denen der
Thread-lokale Heap gehört lesen diesen Wert ohne spezielle Art des
Zugiffs asynchron, rein darauf verlassend, dass volatile eben nur
bedeutet, dass volatile nicht mehr bedeutet als dass der Speicher-
zugriff nicht in einem Register gecacht werden darf. Ist der nicht
Null, so werden diese Stack-Elemente analog atomar gepoppt und in
den Heap wieder eingereiht. Das verhindert, dass es für den Thread
-lokalen Heap ein gemeinsames Lock geben muss, das Allokationen und
Deallkationen blockiert, was die ganze Sache natülrich verlangsamt.
Einfach nur asynchron den volatile Pointer auf das oberste Stack
-Element auf Null zu überprüfen ist natürlich superschnell.
Stefan Reuther (21.10.2019, 18:09)
Am 20.10.2019 um 15:31 schrieb Bonita Montero:
> volatile ist sehr wohl zu gebrauchen. Z.B. gibt es Heap-Allokatoren
> wie jemalloc, TCMalloc oder mimalloc, die einen Pointer auf einen
> Stack haben auf den andere Threads Speicher den diese freigeben per
> locked compare & exchange draufpacken und die Threads denen der
> Thread-lokale Heap gehört lesen diesen Wert ohne spezielle Art des
> Zugiffs asynchron, rein darauf verlassend, dass volatile eben nur
> bedeutet, dass volatile nicht mehr bedeutet als dass der Speicher-
> zugriff nicht in einem Register gecacht werden darf.


Dafür ist volatile weder hinreichend noch notwendig.

Es sagt eben de facto nur, dass der Wert nicht in einem Register
gecached werden darf. Es trifft aber keine Aussage darüber, wie der Wert
zwischen den Caches eines Mehr-Kern-Rechners synchronisiert wird. Nicht
alle Architekturen machen das implizit und transparent (MESI-Protokoll
usw.).

Was man eigentlich braucht ist std::atomic mit magischen Assembler-
Instruktionen. Soweit mir bekannt werden diese eben für volatile nicht
generiert. Und wenn man std::atomic mit load, store, exchange,
compare_exchange_X hat, braucht man volatile nicht mehr.

Stefan
Hergen Lehmann (21.10.2019, 20:36)
Am 20.10.19 um 10:19 schrieb Stefan Reuther:

> Dass volatile irgendwie nicht zu gebrauchen ist, da gibt's aber auch
> ausreichend Tiraden von Linus Torvalds darüber.


volatile ist unverzichtbar für Embedded- und Treiber-Programmierung
(Zugriff auf Hardware-Register).

Das es bei reinen Anwendungsprogrammierern zahlreiche Missverständnisse
über den Sinn und die Funktionsweise von volatile gibt, steht auf einem
anderen Blatt. Das ausgerechnet Linus da irregeleitet sein soll,
verwundert mich aber doch etwas. Urban legend?

> Andererseits gibt es ja schon Programmiersprachen, die 8-bit-Bytes und
> IEEE-Float fordern: Java.


C ist halt sehr viel älter und stammt aus Zeiten, als die 8 Bit noch
nicht in Stein gemeißelt waren.
Und ob heute wirklich alle Maschinen IEEE als Hardware-Fließkommaformat
verwenden? Ich könnte mir vorstellen, das es im embedded-Sektor,
speziell bei DSPs, da immer noch Sonderlocken gibt...
Bonita Montero (22.10.2019, 05:43)
> Dafür ist volatile weder hinreichend noch notwendig.

Doch, dafür ist volatile notwendig. Sonst hätte der Compiler die
Gelegenheit, den Stack-Pointer zu cachen und dem Allocator würde
entgehen, dass mittlerweile dort ein neues Element liegt.

> Es sagt eben de facto nur, dass der Wert nicht in einem Register
> gecached werden darf. Es trifft aber keine Aussage darüber, wie
> der Wert zwischen den Caches eines Mehr-Kern-Rechners synchronisiert
> wird.


Das genaue Timing der Synchronisation ist in dem Fall auch völlig
egal.

> Nicht alle Architekturen machen das implizit und transparent (MESI-Protokoll usw.).


Doch. Was anderes gibt es heute nicht.

> Was man eigentlich braucht ist std::atomic mit magischen Assembler-
> Instruktionen. ...


Völlig überflüssiger Käse, volatile macht in diesem Fall das gleiche.
Markus Schaaf (22.10.2019, 08:01)
Am 21.10.19 um 18:09 schrieb Stefan Reuther:

> Es sagt eben de facto nur, dass der Wert nicht in einem Register
> gecached werden darf. Es trifft aber keine Aussage darüber, wie der Wert
> zwischen den Caches eines Mehr-Kern-Rechners synchronisiert wird. Nicht
> alle Architekturen machen das implizit und transparent (MESI-Protokoll
> usw.).


Dafür war es auch nie da. Das glaubten einige Leute nur. Volatile dient
zum markieren von Variablen, die zur Kommunikation zwischen
Signal-Handlern und Hauptprogramm gedacht sind.

MfG
Bonita Montero (22.10.2019, 10:43)
> volatile ist unverzichtbar für Embedded- und Treiber-Programmierung
> (Zugriff auf Hardware-Register).


Und bei nativen Datentypen die nicht zusammengesetzterweise durch den
Compiler emuliert werden müssen, also wie ein std::uint64_t auf IA-32,
da verhält sich ein volatile-Wert im Speicher de-facto genauso wie ein
std::atomic entsprechenden Typs beim Laden und beim Zuweisen. Da kann
der C++-standard noch so viel davon schreiben, dass volatile implemen-
tation-defined ist.
Bonita Montero (22.10.2019, 12:55)
> Und bei nativen Datentypen die nicht zusammengesetzterweise durch den
> Compiler emuliert werden müssen, also wie ein std::uint64_t auf IA-32,
> da verhält sich ein volatile-Wert im Speicher de-facto genauso wie ein
> std::atomic entsprechenden Typs beim Laden und beim Zuweisen. Da kann
> der C++-standard noch so viel davon schreiben, dass volatile implemen-
> tation-defined ist.


Noch eine Ergänzung: es ist nicht garantiert welches Memory-Ordering
ein volatile ggü. anderen Threads hat; bzgl. des Beispiels was ich
genannt habe ist das aber egal.
Thomas Koenig (23.10.2019, 20:19)
Stefan Reuther <stefan.news> schrieb:
> Am 19.10.2019 um 19:13 schrieb Thomas Koenig:
> Die Audio-Qualität ist irgendwie unterirdisch, aber ich höre da: "These
> are kind of jokes, not really but kind of". Also sooo ernst ist das wohl
> nicht.


Ein klassischer Versuchsballon. Mal steigen lassen und schauen,
wie viel Widerspruch es gibt. Wenn zu viel kommt, kann man ja
immer noch behaupten, es sei eigentlich ein Witz gewesen.

> Andererseits gibt es ja schon Programmiersprachen, die 8-bit-Bytes und
> IEEE-Float fordern: Java.


Und es gibt, durch IEEE 754-2009 normiert, neue, nicht binäre
Floating-Point-Formate. Ob der Kollege das nicht weiß, ob er
die Typen in C++ nicht sehen möchte oder ob er das einfach
ignoriert hat, ist mir allerdings nicht klar.
Ähnliche Themen