1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Sicherheit: Microsoft…

GAC zur kompilierzeit

Am 17. Juli erscheint Ghost of Tsushima; Assassin's Creed Valhalla und Watch Dogs Legions konnten wir auch gerade länger anspielen - Anlass genug, um über Actionspiele, neue Games und die Next-Gen-Konsolen zu sprechen! Unser Chef-Abenteurer Peter Steinlechner stellt sich einer neuen Challenge: euren Fragen.
Er wird sie am 16. Juli von 14 Uhr bis 16 Uhr beantworten.
  1. Thema
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6

Neues Thema Ansicht wechseln


  1. GAC zur kompilierzeit

    Autor: dangi12012 22.07.19 - 14:43

    Das ist natürlich ein sehr guter ansatz. Nachdem garbage collection zur laufzeit immer overhead hat und das konzept: "Pointer ownership" auch im bezug auf threadsicherheit einiges schöner löst als mutex etc.

    Außerdem weiß der compiler in rust statisch, dass arrays sich nicht überlappen und somit kann bei schleifen immer avx2 code verwendet werden.

  2. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 15:11

    dangi12012 schrieb:
    --------------------------------------------------------------------------------
    > Das ist natürlich ein sehr guter ansatz. Nachdem garbage collection zur
    > laufzeit immer overhead hat und das konzept: "Pointer ownership" auch
    > im bezug auf threadsicherheit einiges schöner löst als mutex etc.

    Wie soll das funktionieren bzw. wozu soll das nützlich sein? Die Notwendigkeit einer GC, also drohender Speichermangel, kann ja nur zur Laufzeit festgestellt werden. Und explizite GC aufrufe sind kontraproduktiv weil die a) ggf. eine GC machen wenn das nicht nötig ist und b) nicht ggf. in Idle-Phasen laufen und somit CPU-Zeit verbraten die anderweitig genutzt werden könnte.

  3. Re: GAC zur kompilierzeit

    Autor: dangi12012 22.07.19 - 15:24

    > Wie soll das funktionieren bzw. wozu soll das nützlich sein? Die
    > Notwendigkeit einer GC, also drohender Speichermangel, kann ja nur zur
    > Laufzeit festgestellt werden.

    Bitte grundlagen von RUST lernen. Da gibt es keine nullPointer und jeder Pointer gehört EINER instanz. Es gibt in RUST keine GC und keine (nativen) Speicherlecks.
    Theoretisch schneller als C++ und so sicher wie C#. Eben weil garantiert werden kann ob AVX überlappend ist oder nicht.

  4. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 15:45

    > Bitte grundlagen von RUST lernen. Da gibt es keine nullPointer und jeder
    > Pointer gehört EINER instanz. Es gibt in RUST keine GC und keine (nativen)
    > Speicherlecks.

    Wann der Scope einer Referenz oder eines Pointer endet ist für die Aussage, dass die Notwendigkeit eines GC nur asynchron und ganz sicher nicht zur Compile-Zeit festgestellt werden kann nicht von Belang.

    > Theoretisch schneller als C++ und so sicher wie C#.

    Rust ist mit durchgehend safe Code sicher nicht so schnell wie C++.

    > Eben weil garantiert werden kann ob AVX überlappend ist oder nicht.

    Was AVX hiermit jetzt zu tun haben soll verstehst auch nur Du.

  5. Re: GAC zur kompilierzeit

    Autor: schap23 22.07.19 - 16:14

    Sicheres C++ ist sicher nicht so schnell wie Rust, da wesentlich mehr Checks eingebaut werden müssen, um die Sicherheit zu garantieren.

    In einigen wenigen Fällen kann man mit Techniken, die der Compiler nicht auf Sicherheit überprüfen kann, Performance herausholen. Das ist aber extrem selten und dafür erlaubt Rust ja auch etwas als "unsafe" zu markieren. Den Code sollte man dann aber von mehreren Leuten, die genau wissen, was sie tun, überprüfen lassen.

    Mit dieser Markierung weiß man wenigstens, wo man nachher die Bugs suchen muß, die zu den Sicherheitslücken führen, die neuerdings die Firmen gewaltige Geldbußen kosten.

  6. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 16:16

    > Sicheres C++ ist sicher nicht so schnell wie Rust, da wesentlich mehr
    > Checks eingebaut werden müssen, um die Sicherheit zu garantieren.

    Quelle?

  7. Re: GAC zur kompilierzeit

    Autor: dangi12012 22.07.19 - 17:07

    Wenn pointer null -> exception.
    Das gibt es in rust nicht. Hier garantiert die sprache selbst dass es keinen invaliden pointer gibt.
    zusätzlich 0 runtime cost GC.

    Theoretisch schneller als c++. Praktisch ist gcc natürlich ausgereifter.

  8. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 17:09

    > Wenn pointer null -> exception.
    > Das gibt es in rust nicht. Hier garantiert die sprache selbst dass es
    > keinen invaliden pointer gibt.
    > zusätzlich 0 runtime cost GC.
    > Theoretisch schneller als c++. Praktisch ist gcc natürlich ausgereifter.

    Und was hat das damit zu tun, dass die Notwendigkeit eines GC nicht zur Compile-Zeit festgestellt werden kann, sondern nur völlig asynchron zur Laufzeit?

  9. Re: GAC zur kompilierzeit

    Autor: Cubimon 22.07.19 - 17:15

    dangi12012 schrieb:
    --------------------------------------------------------------------------------

    > Theoretisch schneller als c++. Praktisch ist gcc natürlich ausgereifter.

    Erfordert nicht rust ein c++ compiler wie gcc? Das macht es naturlich nicht genauso schnell wie c++/c.

  10. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 17:17

    >> Theoretisch schneller als c++. Praktisch ist gcc natürlich ausgereifter.

    > Erfordert nicht rust ein c++ compiler wie gcc? Das macht es naturlich nicht
    > genauso schnell wie c++/c.

    Na das ist ja Kokolores; man könnte auch einen C-Compiler in Java schreiben (bzw. es gibt sogar einenen, siehe Compilerbau-Drachenbuch) der schnelleren Code generiert als Java.

  11. Re: GAC zur kompilierzeit

    Autor: Anonymer Nutzer 22.07.19 - 17:28

    Go hat einen Müllsammler, Rust setzt auf Referenzcounter.

  12. Re: GAC zur kompilierzeit

    Autor: pythoneer 22.07.19 - 18:33

    Märchenfee schrieb:
    --------------------------------------------------------------------------------
    > Go hat einen Müllsammler, Rust setzt auf Referenzcounter.

    Das ist so nicht richtig. Man kann in Rust Referenzzähler verwenden, muss aber nicht. Ich meinem Code tauchen so gut wie nie Referenzzähler auf, die sind zum großen Teil auch nicht notwendig. Das kommt aber natürlich auch immer auf den Anwendungsfall und die gewählte Architektur an. Aber grundsätzlich wird das nicht benötigt.

  13. Re: GAC zur kompilierzeit

    Autor: pythoneer 22.07.19 - 18:42

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > Rust ist mit durchgehend safe Code sicher nicht so schnell wie C++.

    Quelle?
    Grundsätzlich befinden sich Rust und C/C++ im selben Bereich was die Geschwindigkeit angeht. Für Ausbrecher nach oben oder unten sind meist Implementierungsdetails verantwortlich die, wenn es sich um grobe Schnitzer handelt, auch vom Rust Compiler in einer der nächsten Versionen behoben wird/werden kann. Und ich spreche hier natürlich von Safe Rust.

    Gerade was die "Wirklichkeit" der Implementierung angeht erlebe ich oft, dass Rust Code schneller ist als ein in C/C++ geschriebenes Programm. Das liegt aber meist nicht daran, dass man das in C/C++ nicht grundsätzlich auch könnte, sondern weil eine Probleme mit Rust schlicht einfacher gelöst werden können. Wo ich mich bei manch paralleler Programmierung in C/C++ scheue das umzusetzen und dann doch auf linearen, konservativen Code setzte habe ich bei Rust absolut keine Bedenken, weil ich genau weiß, ich kann es nicht falsch machen. Falsch machen heißt mein Programm kompiliert nicht. Wenn es kompiliert habe ich zumindest keine Data Races im Code. Was auch der Grund ist warum in Rust häufiger parallele Programmierung anzufinden ist.

    Und was das Benchmarkgame anbelangt – ich gebe zu nicht so wirklich repräsentativ – da hat Rust C++ schon überholt.

  14. Re: GAC zur kompilierzeit

    Autor: dangi12012 22.07.19 - 18:45

    > Go hat einen Müllsammler, Rust setzt auf Referenzcounter.
    Was für ein unwissen hier verbreitet wird.

    Rust hat das konzept von Ownership und das garantiert dass der compiler zur compilierzeit die lifetime eines jeden objekts kennt. Rust braucht keine GC und hat optional eine reference counting GC.
    Nebenbei sind race conditions ausgeschlossen.

    C++ -> Cleanup by programmer (fehleranfällig)
    C#/Java/swift -> Cleanup during Runtime (langsam)
    Rust -> Cleanup by compiler (man kann pointer nicht einfach kopieren)

    https://stackoverflow.com/questions/32677420/what-does-rust-have-instead-of-a-garbage-collector
    https://www.codevamping.com/2018/12/rust-move-copy/



    1 mal bearbeitet, zuletzt am 22.07.19 18:46 durch dangi12012.

  15. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 18:46

    > Und was das Benchmarkgame anbelangt – ich gebe zu nicht so wirklich
    > repräsentativ – da hat Rust C++ schon überholt.

    Nö, in den meisten Benchmarks nicht:
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust.html
    Und Du kannst davon ausgehen, dass die sich alle Mühe geben, den Code maximal zu optimieren so lange der paradigmatisch bleibt (so sind die Regeln).

  16. Re: GAC zur kompilierzeit

    Autor: pythoneer 22.07.19 - 18:54

    dangi12012 schrieb:
    --------------------------------------------------------------------------------
    > Nebenbei sind race conditions ausgeschlossen.

    Das stimmt so nicht. Es sind data races ausgeschlossen, race conditions kann man nicht ausschließen.

  17. Re: GAC zur kompilierzeit

    Autor: pythoneer 22.07.19 - 19:14

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > > Und was das Benchmarkgame anbelangt – ich gebe zu nicht so
    > wirklich
    > > repräsentativ – da hat Rust C++ schon überholt.
    >
    > Nö, in den meisten Benchmarks nicht:
    > benchmarksgame-team.pages.debian.net
    > Und Du kannst davon ausgehen, dass die sich alle Mühe geben, den Code
    > maximal zu optimieren so lange der paradigmatisch bleibt (so sind die
    > Regeln).

    Ok in den aktuellen Werten hat C++ wieder aufgeholt. Vor ca. 5 Monaten lag Rust noch um 3% vorne, das ändert sich aber alle paar Wochen wieder, wenn neue Compiler-Versionen erscheinen. Das änder aber alles an der grundsätzlichen Aussage nichts, dass beide Sprachen gleich schnell sind. Mit den aktuellen Zahlen liegt C++ um 0,7% Prozent vorne.

    https://repl.it/repls/RegularImaginativeManagement (hier mal die aktuellen Zahlen verwendet)

    Und vor allem ändert es nichts an der Tatsache, dass es mir Rust schlicht einfacher ist parallelen Code zu schreiben und das passiert auch so in der Praxis. Ich habe jedenfalls keine Lust mich mit Data Races in C++ die Nächte um die Ohren zu schlagen. Mozilla hat zwei mal versucht ihre CSS Layoutengine zu parallelisieren in C++. Beide Versuche sind aufgrund von zu vielen Problemen gescheitert. Mit Rust haben sie es hin bekommen.



    1 mal bearbeitet, zuletzt am 22.07.19 19:15 durch pythoneer.

  18. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 19:15

    > Und vor allem ändert es nichts an der Tatsache, dass es mir Rust schlicht
    > einfacher ist parallelen Code zu schreiben und das passiert auch so in der
    > Praxis. Ich habe jedenfalls keine Lust mich mit Data Races in C++ die
    > Nächte um die Ohren zu schlagen. ...

    Data Races in C++ sind kein real nennenswert häufiges Problem.

  19. Re: GAC zur kompilierzeit

    Autor: pythoneer 22.07.19 - 19:19

    Bonita.M schrieb:
    --------------------------------------------------------------------------------
    > Data Races in C++ sind kein real nennenswert häufiges Problem.

    Richtig. Weil gar nicht erst paralleler Code geschrieben wird.

  20. Re: GAC zur kompilierzeit

    Autor: Bonita.M 22.07.19 - 19:28

    >> Data Races in C++ sind kein real nennenswert häufiges Problem.

    > Richtig. Weil gar nicht erst paralleler Code geschrieben wird.

    So ein Quatsch. Das ist in C++ i.d.R. nicht schwierig.

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

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. Fraunhofer-Institut für Software- und Systemtechnik ISST, Dortmund
  2. AKDB Anstalt für kommunale Datenverarbeitung in Bayern, München
  3. operational services GmbH & Co. KG, verschiedene Standorte
  4. St. Augustinus Gruppe, Neuss

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 56,53€ (Release: 17. Juli)
  2. (u. a. Deals des Tages: HP 24oh, 24 Zoll LED Full-HD für 95,84€, Acer P6200 Beamer DLP XGA für...
  3. 699€
  4. (u. a. Samsung TU7079 55 Zoll (Modelljahr 2020) für 459€, Samsung LS03R The Frame QLED 49 Zoll...


Haben wir etwas übersehen?

E-Mail an news@golem.de