Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.iso-c++ > #2119 > unrolled thread

"Interessante" Richtungen für C++

Back to article view | Back to de.comp.lang.iso-c++

Contents

  "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2019-10-19 17:13 +0000
    Re: "Interessante" Richtungen für C++ Florian Weimer <fw@deneb.enyo.de> - 2019-10-19 21:24 +0200
      Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-06 16:39 +0200
        Re: "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2020-08-07 11:22 +0000
          Re: "Interessante" Richtungen für C++ Florian Weimer <fw@deneb.enyo.de> - 2020-08-07 21:25 +0200
            Re: "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2020-08-15 08:34 +0000
    Re: "Interessante" Richtungen für C++ Stefan Reuther <stefan.news@arcor.de> - 2019-10-20 10:19 +0200
      Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-20 15:26 +0200
      Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-20 15:31 +0200
        Re: "Interessante" Richtungen für C++ Stefan Reuther <stefan.news@arcor.de> - 2019-10-21 18:09 +0200
          Re: "Interessante" Richtungen für C++ Markus Schaaf <mschaaf@elaboris.de> - 2019-10-22 08:01 +0200
            Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-08 10:41 +0200
          Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-22 05:43 +0200
      Re: "Interessante" Richtungen für C++ Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-10-21 20:36 +0200
        Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-22 10:43 +0200
          Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-22 12:55 +0200
      Re: "Interessante" Richtungen für C++ Thomas Koenig <tkoenig@netcologne.de> - 2019-10-23 18:19 +0000
        Re: "Interessante" Richtungen für C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-08 14:47 +0200

#2119 — "Interessante" Richtungen für C++

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...

[toc] | [next] | [standalone]

#2120

* 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.

[toc] | [prev] | [next] | [standalone]

#2138

> 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 !

[toc] | [prev] | [next] | [standalone]

#2139

Bonita Montero <Bonita.Montero@gmail.com> schrieb:
>> 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 !

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

[toc] | [prev] | [next] | [standalone]

#2140

* Thomas Koenig:

> Bonita Montero <Bonita.Montero@gmail.com> schrieb:
>>> 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 !
>
> 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:

* 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.

[toc] | [prev] | [next] | [standalone]

#2143

Florian Weimer <fw@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.

[toc] | [prev] | [next] | [standalone]

#2121

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.

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

[toc] | [prev] | [next] | [standalone]

#2122

> 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




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

[toc] | [prev] | [next] | [standalone]

#2123

> 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.

[toc] | [prev] | [next] | [standalone]

#2124

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.

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

[toc] | [prev] | [next] | [standalone]

#2126

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

[toc] | [prev] | [next] | [standalone]

#2141

> 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
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.

[toc] | [prev] | [next] | [standalone]

#2127

> 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.

[toc] | [prev] | [next] | [standalone]

#2125

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...

[toc] | [prev] | [next] | [standalone]

#2128

> 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.

[toc] | [prev] | [next] | [standalone]

#2129

> 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.

[toc] | [prev] | [next] | [standalone]

#2133

Stefan Reuther <stefan.news@arcor.de> schrieb:
> 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,
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.

[toc] | [prev] | [next] | [standalone]

#2142

>> 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
sich als native Datentypen irgendwann in C++ wiederfinden werden. Das
gibt wenn überhaupt eigene Klassen.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.iso-c++

csiph-web