1. Foren
  2. Kommentare
  3. Security-Forum
  4. Alle Kommentare zum Artikel
  5. › Linux: Vom einfachen…
  6. T…

Lösung: ...

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


  1. Re: Lösung: ...

    Autor: ultim 21.10.21 - 14:01

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Ich rede nicht von einem Windows oder Linux,
    > > sondern von embedded und real-time Systemen.
    >
    > Ach, und deswegen kann man sowas nicht in C++ programmieren ?
    > Is ja interessant.
    >
    > > Ja das brauchen virtuelle Methoden, und eben deshalb
    > > vermeidet man in einigen Projekten Vererbung zum Beispiel.
    >
    > Das phantasierst Du dir jetzt um kompetent zu wirken zurecht bzw. das gibt
    > es nicht.
    > Ein VMT-Pointer pro Objekt hat noch niemanden gestört.
    >
    > > Verstehe nicht woher das LOL kommt, außer du hast nicht viel
    > > Erfahrung in der Embedded Industry.
    >
    > Ich bin promovierter Informatiker (GH) und weiß wovon ich rede.
    > Du hattest mit Embedded sicher noch nie was am Hut.

    Eingebettete Systeme sind mein tägliches Brot, und habe einiges hinter mir, wie zB. die Portierung von embedded Betriebssystemen auf neue Architekturen, grosse Teile eines ASIL-B AUTOSAR-Kernels (indirekt für mehrere Automarken, weil ja Tier-3 Entwicklung), eine Eye-Tracking Brille, und dutzende Projekte in der Industrieautomation. Aber ich hatte "mit Embedded sicher noch nie was am Hut" LOL. Ich weiss ganz genau wovon ich rede. Ich kann nichts dafür wenn andere diese Erfahrungen nicht haben.



    1 mal bearbeitet, zuletzt am 21.10.21 14:02 durch ultim.

  2. Re: Lösung: ...

    Autor: oleid 21.10.21 - 15:35

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > In C++ kannst du einene shared_ptr<> nehmen und dein Objekt lebt so lange
    > wie nur ein Thread einen shared_ptr<> hält.

    Und was machst du, wenn sich Jemand ne Referenz auf den Inhalt es shared_ptr nimmt?
    Die wird auch ungültig, wenn es Niemanden mehr gibt der ne Kopie des shared_ptr hat.

    Oder auch beliebt: was machst du, wenn über Threadgrenzen hinweg der Inhalt des shared_ptr mutiert wird.

  3. Re: Oh je

    Autor: nohoschi 21.10.21 - 15:45

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Wichtig ist, dass man die Anleitung und Handbücher liest und versteht.
    > > Und dann ordentlich mit bedacht arbeiten. Damit lassen sich Fehler
    > > nicht vermeiden und sie tun mir immer weh, aber sie sind immer die
    > > Gelegenheit zum Lernen.
    >
    > Was für eine idiotische Einstellung. Lieber direkt eine leistungsfähigere
    > Sprache nehmen, dann hat man den ganzen Ärger nicht.

    Mit der Einstellung zum Lernen wird programmiert?

    > > C++ setzt mit RIAA und Smartpointer (Referenzzählung und sichere
    > > Speicherverwaltung) wirklich gute Dinge um - das erlaubt Effizenz
    > > und Sicherheit. Spezielle Sprachfeatures und komplexe Dinge wie
    > > Template-Metaprogrammierung sollte man nicht einsetzen, außer
    > > man will sich etwas beweisen.
    >
    > Mein Gott, mit wem diskutier ich hier ?
    > Was für ein Quatscch. Gerade Templates führen zu einem Bruchteil des Codes
    > und zu Größenordnungen mehr Wartbarkeit.

    Generische Programmierung mit Templates, wunderschön.
    Template-Metaprogrammierung hat eine eigenen Namen. Aus gutem Grund. Damit es nicht verwechselt wird. Hier trotzdem passiert?

  4. Re: Lösung: ...

    Autor: FreiGeistler 21.10.21 - 16:12

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > Besser C++ oder Rust.

    Dann eher Rust oder Go.

  5. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 16:28

    > Eingebettete Systeme sind mein tägliches Brot, und habe einiges hinter
    > mir, wie zB. die Portierung von embedded Betriebssystemen auf neue
    > Architekturen, grosse Teile eines ASIL-B AUTOSAR-Kernels (indirekt für
    > mehrere Automarken, weil ja Tier-3 Entwicklung), eine Eye-Tracking Brille,
    > und dutzende Projekte in der Industrieautomation. Aber ich hatte "mit
    > Embedded sicher noch nie was am Hut" LOL. Ich weiss ganz genau wovon ich
    > rede. Ich kann nichts dafür wenn andere diese Erfahrungen nicht haben.


    Ja, sischaaa ....

  6. Re: Oh je

    Autor: spiegelneuron 21.10.21 - 16:30

    >> Was für eine idiotische Einstellung. Lieber direkt eine
    >> leistungsfähigere Sprache nehmen, dann hat man den
    >> ganzen Ärger nicht.

    > Mit der Einstellung zum Lernen wird programmiert?

    Mit der idiotischen Begründung die Du hier anführst könnte man noch weitergehen und sagen, man sollte alles in Assembler programmieren. Die Sache ist einfach, dass die Fehlerquote, Produktivität und Wartbarkeit in C sehr viel geringer ist als in C++. Da kannste dich auf den Kopf stellen, das kann man nicht umkehren.

    > Generische Programmierung mit Templates, wunderschön.
    > Template-Metaprogrammierung hat eine eigenen Namen.
    > Aus gutem Grund. Damit es nicht verwechselt wird. Hier trotzdem passiert?

    Template-Metaprogrammierung setzt du z.B. automatisch ein wenn Du einem Container einen eigenen allocator gibst, oder einer Hashtable einen eigenen Hasher. Was ist daran falsch ?

  7. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 16:31

    >> Besser C++ oder Rust.

    > Dann eher Rust oder Go.

    Rust ist seitdem die den jemalloc-Allocator rausgenommen haben ein gutes Stück langsamer als C++ und Go ist von der Performance für eine systemnahe Sprache völlig inakzeptabel.

  8. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 16:33

    > Und was machst du, wenn sich Jemand ne Referenz auf den Inhalt es
    > shared_ptr nimmt?

    Das macht man nicht und fertig. Und es ist auch kein Kunststück, diese Regel einzuhalten.

    > Oder auch beliebt: was machst du, wenn über Threadgrenzen hinweg der Inhalt
    > des shared_ptr mutiert wird.

    Das ist nicht möglich weil pro Thread mindestens ein shared_ptr<> exklusiv existiert und der Control-Block nur vom Kon- und Destruieren dieser shared_ptr<> abhängt.

  9. Re: Lösung: ...

    Autor: ultim 21.10.21 - 19:16

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > > Und das ist oft nicht erlaubt siehe vorigen Punkt.
    >
    > Das ist selten nicht erlaubt (s.O.).

    Du glaubst selten, weil du offensichtlich dich nicht mit Embedded auskennst. Das zeigt sich zB auch an deinem nächsten Argument mehrfach:

    > Der Witz an Exceptions ist ja, dass eben bzgl. der Performance nur der
    > Fall, dass eben keine fliegt zählt. Wenn ein Speicher- oder I/O-Kollaps
    > passiert, dann kann der Overhead ja beliebig sein weil man in der Situation
    > keine Ansprüche an die Performance hat. Aber wenn eben keine fliegt, dann
    > ist der Overhead von Exceptions bei table-driven Exceptions so gut wie
    > Null. Mach das mal mit händischen Auswerten von Rückgabe-Codes ...

    1: Einerseits argumentierst du nur über das Performance, und dir fällt überhaupt nicht auf oder ein, dass es andere Kriterien und andere Arten von Overheads auch geben kann, die im Embedded-Bereich ähnlich stark relevant sind, wie zB. Binärgröße. Alleine das zeigt schon, dass du hier noch nicht viel gemacht hast, falls überhaupt.
    2: Aber noch wichtiger, dein Argument über das Nichtvorhandensein vom Performanceoverhead wenn keine Exceptions fliegen ist der größte Tell woran es sich zeigt, dass du dich im Embedded nicht auskennst. Du ignorierst (oder vergisst, oder hast nicht einmal gewusst, kA) nämlich, dass was du hier sagst nur für bestimmte Exception-Handling-Mechanismen gültig ist. Das gilt zB für SEH, SEH hast du aber nur unter Windows, hast also im Bereich Embedded sicher nicht gemeint, oder? Würde auch für DWARF2/3 gelten theoretisch, da ist aber der "Code Bloat" riesengroß weil es partielle Debug-Informationen über das ganze Call-stack benötigt auch im Release-Code damit das Unwinding funktionieren kann. DWARF-EH hat weiterhin auch das (nicht ganz unwesentliche) Problem dass dort keine Exceptions über Fremd- oder C-Code geworfen werden dürfen. Es bleibt dann praktisch noch das SJLJ-Mechanismus, das diese Schwächen nicht hat, bei SJLJ ist aber deine Behauptung von Null-Performance-Overhead komplett falsch.

    Aber schön, behaupte weiterhin dass du als "promovierter Informatiker" weisst wovon du redest. Vielleicht zu viel Theorie, zu wenig Erfahrung? Und das lächerlichste ist, wenn ich auf dein Herumprahlen mit deiner Ausbildung anmerke, dass ich eigentlich selbst in der Industrie seit Jahren professionell tätig bin und kein Skriptkiddie bin, du implizierst ich würde lügen. [headbang] Du solltest vielleicht eine Stufe herabsteigen. Oder zwei.

    Ausserdem bist du schon mehrmals mit dir selbst in diesem Thread in Widerspruch geraten. Einmal schreibst du zB, Rust löst C++ komplett ab, später schreibst du Rust sei ein "gutes Stück langsamer als C++". Da stellt sich die Frage ob du nur ein Troll bist statt ein "promovierter Informatiker". So oder so, ein Experte wahrscheinlich nicht.



    1 mal bearbeitet, zuletzt am 21.10.21 19:18 durch ultim.

  10. Re: Lösung: ...

    Autor: Walter Plinge 21.10.21 - 20:27

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > Es gibt sicher in c++ komplexe Dinge.
    > Aber ein this-Pointer in einem Lambda isses ganz sicher nicht.

    Was nur zeigt, dass Du entweder die Fallen kennst, oder noch nicht in dieselben getappt bist (Stichwort ownership und lifetime von Objekten). Ich sehe allzuoft Code die sorglos (aber fälschlich) davon ausgehen, dass ein Lambda nicht länger leben würde, als das Objekt welches es definiert.

    Oder Objekte die in Container (z.B. Vektoren oder Maps) gepackt werden, während ein Callback-lambda (mit this) außerhalb des Objektes verfügbar ist. Damit fängt man sich Ruck-Zuck dangling pointer auf this im lambda ein.



    1 mal bearbeitet, zuletzt am 21.10.21 20:32 durch Walter Plinge.

  11. Re: Lösung: ...

    Autor: spiegelneuron 21.10.21 - 20:30

    > Du glaubst selten, weil du offensichtlich dich nicht mit Embedded
    > auskennst. Das zeigt sich zB auch an deinem nächsten Argument
    > mehrfach: ..

    Die tangieren Embedded-Themen gar nicht, Du Pfeife.

    > 1: Einerseits argumentierst du nur über das Performance, und dir fällt
    > überhaupt nicht auf oder ein, dass es andere Kriterien und andere Arten
    > von Overheads auch geben kann, die im Embedded-Bereich ähnlich stark
    > relevant sind, wie zB. Binärgröße. Alleine das zeigt schon, dass du hier noch
    > nicht viel gemacht hast, falls überhaupt.

    Das ist der seltene Ausnamefall, dass das so ist.

    > 2: Aber noch wichtiger, dein Argument über das Nichtvorhandensein
    > vom Performanceoverhead wenn keine Exceptions fliegen ist der größte
    > Tell woran es sich zeigt, dass du dich im Embedded nicht auskennst.

    Eine Exception fliegt nur bei Speicher- oder I/O-Kollaps, und dann ist die Performance komplett egal weil dann eine Operation agebrochen werden muss.


    > Du ignorierst (oder vergisst, oder hast nicht einmal gewusst, kA) nämlich,
    > dass was du hier sagst nur für bestimmte Exception-Handling-Mechanismen
    > gültig ist. Das gilt zB für SEH, SEH hast du aber nur unter Windows, hast also
    > im Bereich Embedded sicher nicht gemeint, oder?

    Table-driven Exception-Handling hat nur unter Windows was mit SEH zu tun und ist ansonsten auf so ziemlich allen Plattformen mittlerweile Standard.

    > Würde auch für DWARF2/3 gelten theoretisch, da ist aber der "Code Bloat"
    > riesengroß weil es partielle Debug-Informationen über das ganze Call-stack
    > benötigt auch im Release-Code damit das Unwinding funktionieren kann.

    Und was hat das mit table-driven EH zu tun ? Gar nichts.

    > DWARF-EH hat weiterhin auch das (nicht ganz unwesentliche) Problem
    > dass dort keine Exceptions über Fremd oder C-Code geworfen werden
    > dürfen.

    Das hat nichts mit DWARF zu tun und auch nichts mit table-driven EH im Speziellen. Exceptions können generell nich durch C-Code geworfen werden weil der C-Code halt keine Unwind-Handler hat. Das ist auch kein wirkliches Problem, denn dann fängt man halt alles über der C-Funktion die C++-Code aufruft, macht einen exception_ptr draus, und leitet das an den C++-Code unterhalb der C-Funktion weiter (abgeshen davon, dass sich diese Notwendigkeit nur selten bei C++-Callbacks in aufgerufenen C-Funktionen, also fast nie, ergibt).

    > Es bleibt dann praktisch noch das SJLJ-Mechanismus, das diese Schwächen
    > nicht hat, bei SJLJ ist ber deine Behauptung von Null-Performance-Overhead
    > komplett falsch.

    C++ table-driven EH hat Null Overhead wenn der Compiler es richtig implementiert. Das liegt daran, dass der Unwind-Code der beim Werfen der Exception beschritten wird ein völlig anderer ist als der wenn keine Exception fliegt. Der Nachteil ist, dass der Unwind-Handler beim Werfen einer Exception in der Runtime den Kernel fragen muss zu welchem Executable oder zu welcher Shared Library die Rücksprungadresse einer Funktion die eine Exception wirft gehört um die Unwind-Handler des Executables oder der Shared Libary zu finden, und Kernel-Calls kosten halt.

    > Aber schön, behaupte weiterhin dass du als "promovierter Informatiker"
    > weisst wovon du redest. Vielleicht zu viel Theorie, zu wenig Erfahrung?

    Ich bin halt nicht so gut im Buzzword-Blödsinn reden wie Du.

    > Und das lächerlichste ist, wenn ich auf dein Herumprahlen mit deiner
    > Ausbildung anmerke, dass ich eigentlich selbst in der Industrie seit
    > Jahren professionell tätig bin und kein Skriptkiddie bin, ...

    Wer das Wort Skriptkiddie in den Mund nimmt arbeitet sicher nicht an der Stelle.

    > Ausserdem bist du schon mehrmals mit dir selbst in diesem Thread
    > in Widerspruch geraten. Einmal schreibst du zB, Rust löst C++ komplett
    > ab, später schreibst du Rust sei ein "gutes Stück langsamer als C++".

    Das ist kein Widerspruch, denn dass Rust nun mit dem neuen System-Allocator ein gutes Stück langsamer ist ist meist kein Problem.

  12. Re: Lösung: ...

    Autor: oleid 21.10.21 - 22:37

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > >> Besser C++ oder Rust.
    >
    > > Dann eher Rust oder Go.
    >
    > Rust ist seitdem die den jemalloc-Allocator rausgenommen haben ein gutes
    > Stück langsamer als C++

    Wieso langsamer als c++, wenn der gleiche allocator verwendet wird?

    Zudem: die Aussage ist sehr abhängig von der Plattform und was du tust. Für die Codebasis auf meiner Arbeit ist der allocator der glibc schneller.
    Aber wenn du wirklich jemalloc in Rust brauchst ist es trivial den zu verwenden. Gleiches gilt für andere allocatoren.

  13. Re: Lösung: ...

    Autor: ultim 21.10.21 - 22:40

    Gleich voraus zu deiner Aussage, dass die Binärgrösse meistens von keiner Bedeutung ist, oder dass C-Callbacks nur in den seltensten Fällen OOP-Code wie C++ aufrufen... LOL. Lebst du in einer Höhle? Den ersten Teil könnte ich zumindest auf einigen Plattformen zustimmen, aber... no Komment.

    spiegelneuron schrieb:
    -------------------------------------------------------------------------------

    >
    > > 2: Aber noch wichtiger, dein Argument über das Nichtvorhandensein
    > > vom Performanceoverhead wenn keine Exceptions fliegen ist der größte
    > > Tell woran es sich zeigt, dass du dich im Embedded nicht auskennst.
    >
    > Eine Exception fliegt nur bei Speicher- oder I/O-Kollaps, und dann ist die
    > Performance komplett egal weil dann eine Operation agebrochen werden muss.

    Wos? Ein Exception fliegt weitaus nicht nur bei "Speicher- oder I/O-Kollaps". Ausserdem bei Speicher- oder I/O-Kollaps gibt es sicher keine Exceptions weil diese müssten vom OS geworfen werden und es gibt fast kein OS das sowas wirft. Linux by-the-way auch nicht. Windows wirft schon selbstständig Exceptions (SEH) , ist aber möglicherweise das einzige OS das sowas tut und nicht irgendein Research-Project ist. Fairerweise muss man sagen von den meisten CPUs gibt es auch sog. "Exceptions" die wie du sagst zB bei Speicher-Problemen geworfen werden können, die sind aber etwas völlig anderes als die C++ Exceptions über die wir reden.
    Und bevor du sagst, zwischen der App und dem OS könnte das STL die Exceptions werfen... das tut es aber standardmäßig nicht. IO exceptions im STL müssen explizit von der Applikation enabled werden.

    > Exceptions können generell nich durch C-Code geworfen werden
    > weil der C-Code halt keine Unwind-Handler hat. Das ist auch kein wirkliches
    > Problem, denn dann fängt man halt alles über der C-Funktion die C++-Code
    > aufruft, macht einen exception_ptr draus, und leitet das an den C++-Code
    > unterhalb der C-Funktion weiter (abgeshen davon, dass sich diese
    > Notwendigkeit nur selten bei C++-Callbacks in aufgerufenen C-Funktionen,
    > also fast nie, ergibt).
    >

    Auch falsch. Natürlich können auch C++ Exceptions auch über C-Routinen propagieren! Zumindest wenn die Implementierung stimmt, ein konkretes (und verbreitetes) Beispiel habe ich schon genannt. Automatisches RAII-artiges Cleanup passiert im C-Code natürlich nicht, aber der Aufrufer vom C-code kann das Exception zumindest doch fangen und selbst dann Dinge unternehmen. Das ist nicht bei allen EH-Mechanismen möglich oder gegeben! Und natürlich würde man sowas mit mit dem Weiterleiten von exception_ptrs in C-code wie du schilderst generell nicht machen, weil dazu müsstest du den C-Code unter eigener Kontrolle haben. Wenn das der Fall wäre dann hättest du keinen gemischten Kod!

    > C++ table-driven EH hat Null Overhead wenn der Compiler es richtig
    > implementiert. Das liegt daran, dass der Unwind-Code der beim Werfen der
    > Exception beschritten wird ein völlig anderer ist als der wenn keine
    > Exception fliegt. Der Nachteil ist, dass der Unwind-Handler beim Werfen
    > einer Exception in der Runtime den Kernel fragen muss zu welchem Executable
    > oder zu welcher Shared Library die Rücksprungadresse einer Funktion die
    > eine Exception wirft gehört um die Unwind-Handler des Executables oder der
    > Shared Libary zu finden, und Kernel-Calls kosten halt.

    Du gelingst schon wider in Gegenspruch mit dir selbst. Plötzlich ist es ein Nachteil wenn die Kernel-Calls im Exception-Case etwas kosten, vor kurzem hast du aber erzählt sowas ist völlig wurscht weil das Exception-Pfad für das Performance eh nicht relevant ist.
    Ist dir egal was du sagst solang du irgendwie argumentieren kannst du hättest Recht?

    >
    > > Aber schön, behaupte weiterhin dass du als "promovierter Informatiker"
    > > weisst wovon du redest. Vielleicht zu viel Theorie, zu wenig Erfahrung?
    >
    > Ich bin halt nicht so gut im Buzzword-Blödsinn reden wie Du.

    Wo siehst du Buzzwords eigentlich? Das einzige ist "promoviert", dieses kommt aber von dir. Die Anführungszeichen sind nicht umsonst da: ist ja ein Zitat von dir.

    > > Ausserdem bist du schon mehrmals mit dir selbst in diesem Thread
    > > in Widerspruch geraten. Einmal schreibst du zB, Rust löst C++ komplett
    > > ab, später schreibst du Rust sei ein "gutes Stück langsamer als C++".
    >
    > Das ist kein Widerspruch, denn dass Rust nun mit dem neuen System-Allocator
    > ein gutes Stück langsamer ist ist meist kein Problem.

    Ach ja, sicher, überhaupt kein Widerspruch, weil es keine Applikationen, Informatikfelder, Firmen oder Personen gibt, die sich interessieren würden, wenn ihre Software plötzlich "ein gutes Stück langsamer" läuft. LOL. Wenn du Recht hast und Rust um vieles langsamer ist, dann ist es in vielen Applikationen eben *kein* Ersatz für C++. Siehst du wirklich den Widerspruch nicht? Ich rede natürlich nicht von deinem Wordprozessor.



    1 mal bearbeitet, zuletzt am 21.10.21 22:40 durch ultim.

  14. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 06:47

    > Gleich voraus zu deiner Aussage, dass die Binärgrösse meistens von keiner
    > Bedeutung ist, oder dass C-Callbacks nur in den seltensten Fällen OOP-Code
    > wie C++ aufrufen... LOL. Lebst du in einer Höhle? Den ersten Teil könnte
    > ich zumindest auf einigen Plattformen zustimmen, aber... no Komment.

    Doch, das ist so, C++-Code als Callback einer C-Funktion ist selten.

    > Wos? Ein Exception fliegt weitaus nicht nur bei "Speicher- oder
    > I/O-Kollaps".

    Doch, das ist so.

    > Ausserdem bei Speicher- oder I/O-Kollaps gibt es sicher keine
    > Exceptions weil diese müssten vom OS geworfen werden und
    > es gibt fast kein OS das sowas wirft.

    Mit was für einem Anfänger red ich hier eigentlich ?
    Schon mal was von bad_alloc gehört ? Wird das etwa vom Betriebssystem geworfen ?

    > Fairerweise muss man sagen von den meisten CPUs gibt es auch
    > sog. "Exceptions" die wie du sagst zB bei Speicher-Problemen
    > geworfen werden können, ...

    Das sind Traps und die dienen völlig anderen Zwecken als Exceptions.

    > Und bevor du sagst, zwischen der App und dem OS könnte das STL die
    > Exceptions werfen... das tut es aber standardmäßig nicht. IO exceptions im
    > STL müssen explizit von der Applikation enabled werden.

    Eben, das tut man aber so gut wie immer bzw man schreibt dann einfach:
    is.exceptions( ios_base::badbit | ios_base::failbit )
    Damit erspart man sich viel arbeit, denn das manuelle Auswerten des Fehlerzustandes im Gegensatz dazu kostet viel Aufwand.
    Und nebenbei: auch hier werden keine I/O-Exceptions vom Betriebssystem geworfen.

    > Auch falsch. Natürlich können auch C++ Exceptions auch über C-Routinen
    > propagieren!

    NEIN, das geht bei table-driven EH nicht mehr weil die Rücksprungadressen im C-Code keine Exception-Tabellen haben.
    Beim klassischen Verfahren vor table-driven EH werden die Stackframes der C++-Funktionen durcch eine einfach-verkettete Liste deren Kopf im thread local storage liegt verkettet und der Code der Runtime die beim Werfen der Exception geworfen wird geht diese Kette durch und ruft entsprechend die Unwind-Handler und die Exception-Filter auf. Aber auch wenn das dann mit C-Funktionen zusammen zu funktionieren _scheint_, es funktioniert i.d.R. eben doch nicht weil bei dieser Verkettung dann eben Stackframes von C-Funktionen überpsrungen werden die ggf. Resourcen nach der Rückkehr der aufgerufenen Funktion freigeben wollen und wo das dann nicht passiert und es dementsprechend dann nicht freigegebenen Speicher, nicht geschlossenes I/O o.Ä. gibt.
    MIT, table-driven EH werden keine EH-tabellen von den C-Rucksprung-Adressen erkannt und der Unwind-Handler der Runtime macht dann einfach terminate().

    > Und natürlich würde man sowas mit mit dem Weiterleiten von exception_ptrs
    > in C-code wie du schilderst generell nicht machen, weil dazu müsstest du
    > den C-Code unter eigener Kontrolle haben.

    Sachmal, was für einem N00b diskutier ich hier eigentlich ? Hast Du eigentlich verstanden was ich schrieb ?
    Ich beschrieb die Situation, dass ich eine C-Funktion aufrufe die einen C++-Callback in meinem eigenen Code schrieb der dann eine Exception wirft. Die fange ich dann auf unterster Ebene in meinem Callback-Code, merke mir die exception_ptr und (ggf. in einer thread_local Variable die vom Callback und dem C-aufrufenden C++-Code geteilt wird) und werte den dann nach Rückkehr aus der C-Funktion aus und mache ein rethrow_exception - alles eine recht saubere Sache.

    > Du gelingst schon wider in Gegenspruch mit dir selbst. Plötzlich ist es ein
    > Nachteil wenn die Kernel-Calls im Exception-Case etwas kosten, vor kurzem
    > hast du aber erzählt sowas ist völlig wurscht weil das Exception-Pfad für
    > das Performance eh nicht relevant ist.

    Es ist ja auch so gut wie egal, denn das Timing bei Resourcen-Kollaps interessiert keinen.

    > Ach ja, sicher, überhaupt kein Widerspruch, weil es keine Applikationen,
    > Informatikfelder, Firmen oder Personen gibt, die sich interessieren würden,
    > wenn ihre Software plötzlich "ein gutes Stück langsamer" läuft.

    Für die seltenen Fälle wo das eine Rolle spielt gibt es mimalloc als drop-in-replacement für Rust. Das ist der im Schnitt schnellste Allocator.

  15. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 06:49

    >> Rust ist seitdem die den jemalloc-Allocator rausgenommen haben ein gutes
    >> Stück langsamer als C++

    > Wieso langsamer als c++, wenn der gleiche allocator verwendet wird?

    Ja, sischaaaaa. Es gibt ja bei einer Programmiersprache nuuur den Allocator, der die Performance bestimmt.

    > Zudem: die Aussage ist sehr abhängig von der Plattform und was du tust.
    > Für die Codebasis auf meiner Arbeit ist der allocator der glibc schneller.

    Das ist Quatsch. jemalloc ist nach mimalloc der zweitschnellste Allocator.

  16. Re: Lösung: ...

    Autor: oleid 22.10.21 - 08:43

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------
    > >> Rust ist seitdem die den jemalloc-Allocator rausgenommen haben ein
    > gutes
    > >> Stück langsamer als C++
    >
    > > Wieso langsamer als c++, wenn der gleiche allocator verwendet wird?
    >
    > Ja, sischaaaaa. Es gibt ja bei einer Programmiersprache nuuur den
    > Allocator, der die Performance bestimmt.

    Ne, sicher nicht, aber was hat denn überhaupt der allocator mit der Programmiersprache zu tun? Die Aussage ist eher: wenn der systemallokator langsam zu langsam ist, warum ist er denn schnell genug für c++?

    Und warum nutzt man nicht in c++ ausschließlich jemalloc?
    >
    > > Zudem: die Aussage ist sehr abhängig von der Plattform und was du tust.
    > > Für die Codebasis auf meiner Arbeit ist der allocator der glibc
    > schneller.
    >
    > Das ist Quatsch. jemalloc ist nach mimalloc der zweitschnellste Allocator.

    Ja, in Benchmarks die bei gewissen nutzungspattern relevant sind.
    Junge, warum nimmst du dir eigentlich das Recht raus zu behaupten es wäre Quatsch?

  17. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 08:58

    > Ne, sicher nicht, aber was hat denn überhaupt der allocator mit der
    > Programmiersprache zu tun?

    Die Standardbibliothek inkl. ihrer Container gehört zur Sprache.

    > Die Aussage ist eher: wenn der systemallokator langsam
    > zu langsam ist, warum ist er denn schnell genug für c++?

    Das ist Ansichtssache ob der schnell genug ist. Manche Leute wechseln den gg. TCMalloc, jemalloc oder mimalloc aus.

    > Ja, in Benchmarks die bei gewissen nutzungspattern relevant sind.

    Nein, auch in praktischen Benchmarks. Lies die entsprechenden Papers.

  18. Re: Lösung: ...

    Autor: Superlokkus 22.10.21 - 09:11

    A) Lese ich hier nur viel Spekulation, es gibt doch wundebare konkrete Evidenz ich sag nur "Technical Report on C++ Performance" Date: 2003-08-11
    WG21 N1487=03-0070 . (Link kann ich wegen Anti spam nicht posten)

    B) Mal abgesehen von A), wieso sollten diese anderen Allocatoren schneller als malloc sein? Für die C und C++ Sprache sind das einfach Funktionen die die Implementierung, heißt z.B. gcc/libc/linux bereit stellen müssen. Im einfachsten Fall, wie im Embedded Bereich gibt man einen globalen Pointer zurück den man nur um size postinkrementiert. Diese libc sind damit reine linux oder libc nutzende Plattform-Diskussionen, hat nichts mit den Sprachen wirklich zu tun.

    C++s new ist dann auch nicht mehr als ein malloc plus ggf. ein Konstruktoraufruf. Und beide sind dann ggf nur eine Handvoll Assembly Instructions im Sinne von 1-2 Funktioncalls. Nicht mal ein conditional jump müsste drin sein.

  19. Re: Lösung: ...

    Autor: spiegelneuron 22.10.21 - 09:23

    > B) Mal abgesehen von A), wieso sollten diese anderen Allocatoren schneller
    > als malloc sein? ...

    OMG - ist die Frage dein Ernst ?

    > Für die C und C++ Sprache sind das einfach Funktionen die die
    > Implementierung, heißt z.B. gcc/libc/linux bereit stellen müssen.

    Glibc ist ein mittelmäßiger Allokator, der zwar thread-caching kann, der aber konservativ ist und seine Pools klein hält um Speicher zu sparen. Andere Allokatoren aasen mehr mit dem RAM rum, sind dafür gravierend schneller.

    > Im einfachsten Fall, wie im Embedded Bereich gibt man einen
    > globalen Pointer zurück den man nur um size postinkrementiert.

    Nein, Speicher muss auch wieder freigegeben und die selben Blöcke im Nachhinein wieder verfügbar sein, dass dieser Trivial-Ansatz nicht drin ist Und so fordert es auch die Sprach-Spezifikation von C und c++.

    > Diese libc sind damit reine linux oder libc nutzende Plattform-Diskussionen,
    > hat nichts mit den Sprachen wirklich zu tun.

    Die Sprachspezifikation gibt natürlich nicht die interene Arbeitsweise eines Alloaktors vor, aber bei diesen gibt es erhebliche Performance-Unterschiede, wobei mehr Performance grob immer einen höheren Speicherbedarf bedeutet; wobei es unter den drei schnellsten Allokatoren kaum einen Unterschied im Verbrauch, aber in der Performance gibt.

    > C++s new ist dann auch nicht mehr als ein malloc plus ggf. ein
    > Konstruktoraufruf. Und beide sind dann ggf nur eine Handvoll
    > Assembly Instructions im Sinne von 1-2 Funktioncalls. Nicht mal
    > ein conditional jump müsste drin sein.

    Es ist sinnlos, mit dir darüber zu diskutieren.



    1 mal bearbeitet, zuletzt am 22.10.21 09:31 durch spiegelneuron.

  20. Re: Lösung: ...

    Autor: Superlokkus 22.10.21 - 09:32

    spiegelneuron schrieb:
    --------------------------------------------------------------------------------

    > Nein, Speicher muss auch wieder freigegeben und die selben Blöcke im
    > Nachhinein wieder verfügbar sein, dass dieser Trivial-Ansatz nicht drin ist
    > Und so fordert es auch die Sprach-Spezifikation von C und c++.

    Hast du auch mal Belege für die ganzen wilden Behauptungen?
    Zwar sagt der C Standard "The free function causes the space pointed to by ptr to be deallocated, that is, made available
    for further allocation. " verbietet bei § 7.22.3 aber nirgends die einfache Ich-Geb-nur-raus-bis-zum-ende Speicherverwaltung wie z.B. auch free RTOS es wahlweise anbietet. Und ja freestanding vs hosted sagt dazu auch nix.

  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. IT Inhouse Consultant CRM / Marketing-Systeme (w/m/d)
    dmTECH GmbH, Karlsruhe
  2. Fachprojektleiter (w/m/d) IT & Netzwerktechnik
    SSI SCHÄFER Automation GmbH, Giebelstadt bei Würzburg
  3. SAP WM Junior Berater (m/w/x)
    über duerenhoff GmbH, Albstadt
  4. Software Inbetriebnehmer (m/w/d)
    Dürr Systems AG, Goldkronach

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 40,99€
  2. 35,99€
  3. 34,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de