Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"Interessante" Richtungen für C++
23 views
Skip to first unread message
Thomas Koenig
Oct 19, 2019, 3:00:09 PM10/19/19
to
Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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...
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
Oct 19, 2019, 9:00:04 PM10/19/19
to
* Thomas Koenig:
> Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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.
> Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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
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...
immer noch undefiniert.
Stefan Reuther
Oct 20, 2019, 8:40:04 AM10/20/19
to
Am 19.10.2019 um 19:13 schrieb Thomas Koenig:
> Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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
> Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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
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
Oct 20, 2019, 11:40:09 AM10/20/19
to
> 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
> ausreichend Tiraden von Linus Torvalds darüber. Insofern kann man da
> schon mal über Verbesserungen sprechen. Bei den anderen eher nicht so.
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
Oct 20, 2019, 11:40:09 AM10/20/19
to
> 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.
> 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
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
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
Oct 21, 2019, 2:10:05 PM10/21/19
to
Am 20.10.2019 um 15:31 schrieb Bonita Montero:
>> 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.
Dafür ist volatile weder hinreichend noch notwendig.
>> 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.
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
Oct 22, 2019, 3:10:09 AM10/22/19
to
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...
> Dass volatile irgendwie nicht zu gebrauchen ist, da gibt's aber auch
> ausreichend Tiraden von Linus Torvalds darüber.
(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.
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...
Markus Schaaf
Oct 22, 2019, 6:20:06 AM10/22/19
to
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
> 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.).
zum markieren von Variablen, die zur Kommunikation zwischen
Signal-Handlern und Hauptprogramm gedacht sind.
MfG
Bonita Montero
Oct 22, 2019, 6:20:07 AM10/22/19
to
> 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.
egal.
> Nicht alle Architekturen machen das implizit und transparent (MESI-Protokoll usw.).
> Was man eigentlich braucht ist std::atomic mit magischen Assembler-
Völlig überflüssiger Käse, volatile macht in diesem Fall das gleiche.
Bonita Montero
Oct 22, 2019, 6:30:05 AM10/22/19
to
> volatile ist unverzichtbar für Embedded- und Treiber-Programmierung
> (Zugriff auf Hardware-Register).
Und bei nativen Datentypen die nicht zusammengesetzterweise durch den
> (Zugriff auf Hardware-Register).
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
Oct 22, 2019, 7:20:05 AM10/22/19
to
> 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
> 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.
ein volatile ggü. anderen Threads hat; bzgl. des Beispiels was ich
genannt habe ist das aber egal.
Thomas Koenig
Oct 23, 2019, 2:40:05 PM10/23/19
to
Stefan Reuther <stefa...@arcor.de> schrieb:
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.
> Am 19.10.2019 um 19:13 schrieb Thomas Koenig:
>> Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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.
Ein klassischer Versuchsballon. Mal steigen lassen und schauen,
>> Wenn man sich den Talk unter https://youtu.be/KJW_DLaVXIY 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.
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.
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.
Bonita Montero
Aug 6, 2020, 7:50:11 PM8/6/20
to
> 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.
POWER9 hat long double mit 128 bits - in Hardware !
> schnell nicht verschwinden, es gibt immer noch entsprechende neue
> Architekturen. POWER hat auf GNU/Linux auch kein IEEE-long double.
Thomas Koenig
Aug 7, 2020, 9:40:04 AM8/7/20
to
Bonita Montero <Bonita....@gmail.com> schrieb:
Ja, und die Umstellung vom IBM extended double ist... ein
interessantes Projekt. War mal für gcc 9 vorgsehehen, in gcc 10
ist es immer noch nicht drin...
Der letzte Stand, den ich dazu haben, ist
https://gcc.gnu.org/pipermail/fortran/2018-October/051147.html
interessantes Projekt. War mal für gcc 9 vorgsehehen, in gcc 10
ist es immer noch nicht drin...
Der letzte Stand, den ich dazu haben, ist
https://gcc.gnu.org/pipermail/fortran/2018-October/051147.html
Florian Weimer
Aug 7, 2020, 6:10:05 PM8/7/20
to
* Thomas Koenig:
In glibc 2.32 sollten alle C-Schnittstellen enthalten sein:
* powerpc64le supports IEEE128 long double libm/libc redirects when
using the -mabi=ieeelongdouble to compile C code on supported GCC
toolchains. It is recommended to use GCC 8 or newer when testing
this option.
Es reicht auf jeden Fall aus, um die libstdc++-Implementierung zu
validieren. Wenn alles paßt, kommt der Wechsel mit GCC 11.
* powerpc64le supports IEEE128 long double libm/libc redirects when
using the -mabi=ieeelongdouble to compile C code on supported GCC
toolchains. It is recommended to use GCC 8 or newer when testing
this option.
Es reicht auf jeden Fall aus, um die libstdc++-Implementierung zu
validieren. Wenn alles paßt, kommt der Wechsel mit GCC 11.
Bonita Montero
Aug 8, 2020, 7:10:04 AM8/8/20
to
> 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.
Wenn ein Datentyp von der Plattform nativ atomar gehandhabt
> zum markieren von Variablen, die zur Kommunikation zwischen
> Signal-Handlern und Hauptprogramm gedacht sind.
wird entspricht ein volatile-Zugriff einem Zugriff mit maximal
std::memory_order-relaxed. D.h. da sind Überschneidungen und
man kann de-facto atomic teilweise mit volatile-Variablen
ersetzen.
Bonita Montero
Aug 9, 2020, 2:40:05 AM8/9/20
to
>> 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.
Ist aber auch ziemlich unwahrscheinlich, dass die nicht binären Floats
>> 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.
sich als native Datentypen irgendwann in C++ wiederfinden werden. Das
gibt wenn überhaupt eigene Klassen.
Thomas Koenig
Aug 16, 2020, 6:20:05 PM8/16/20
to
Florian Weimer <f...@deneb.enyo.de> schrieb:
> * Thomas Koenig:
>> Ja, und die Umstellung vom IBM extended double ist... ein
>> interessantes Projekt. War mal für gcc 9 vorgsehehen, in gcc 10
>> ist es immer noch nicht drin...
>>
>> Der letzte Stand, den ich dazu haben, ist
>> https://gcc.gnu.org/pipermail/fortran/2018-October/051147.html
>
> In glibc 2.32 sollten alle C-Schnittstellen enthalten sein:
[...]
> Es reicht auf jeden Fall aus, um die libstdc++-Implementierung zu
> validieren. Wenn alles paßt, kommt der Wechsel mit GCC 11.
Und das wird für die Benutzer ein "flag day" - Code, der vorher
mit "long double" geschrieben wurde, wird dann binär inkompatibel.
Nur wer die unportablen Typen __float128 oder __ibm128 verwendet
hat, ist auf der sicheren Seite :-(
Nur wenige Leute werden long double verwenden, aber die, die es tun,
werden von der Hardware-Untterstüzung des neuen Formats natürlich
stark profitieren.
> * Thomas Koenig:
>> Ja, und die Umstellung vom IBM extended double ist... ein
>> interessantes Projekt. War mal für gcc 9 vorgsehehen, in gcc 10
>> ist es immer noch nicht drin...
>>
>> Der letzte Stand, den ich dazu haben, ist
>> https://gcc.gnu.org/pipermail/fortran/2018-October/051147.html
>
> In glibc 2.32 sollten alle C-Schnittstellen enthalten sein:
> Es reicht auf jeden Fall aus, um die libstdc++-Implementierung zu
> validieren. Wenn alles paßt, kommt der Wechsel mit GCC 11.
mit "long double" geschrieben wurde, wird dann binär inkompatibel.
Nur wer die unportablen Typen __float128 oder __ibm128 verwendet
hat, ist auf der sicheren Seite :-(
Nur wenige Leute werden long double verwenden, aber die, die es tun,
werden von der Hardware-Untterstüzung des neuen Formats natürlich
stark profitieren.
0 new messages