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

GAC zur kompilierzeit

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

Stellenmarkt
  1. Deutsches Krebsforschungszentrum (DKFZ), Heidelberg
  2. ARI Fleet Germany GmbH, Eschborn, Stuttgart
  3. Universität der Bundeswehr München, Neubiberg
  4. Hong Kong Economic and Trade Office, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 29,99€
  2. 3,99€
  3. 54,49€
  4. 149,99€ (Release noch nicht bekannt)


Haben wir etwas übersehen?

E-Mail an news@golem.de


IT-Arbeit: Was fürs Auge
IT-Arbeit
Was fürs Auge

Notebook, Display und Smartphone sind für alle, die in der IT arbeiten, wichtige Werkzeuge. Damit man etwas mit ihnen anfangen kann, ist ein anderes Werkzeug mindestens genauso wichtig: die Augen. Wir geben Tipps, wie man auch als Freiberufler augenschonend arbeiten kann.
Von Björn König

  1. Sysadmin "Man kommt erst ins Spiel, wenn es brennt"
  2. Verdeckte Leiharbeit Wenn die Firma IT-Spezialisten als Fremdpersonal einsetzt
  3. IT-Standorte Wie kann Leipzig Hypezig bleiben?

Mobile Payment: Mit QR-Code-Kooperation zum europäischen Standard
Mobile Payment
Mit QR-Code-Kooperation zum europäischen Standard

Die Mobile Wallet Collaboration will ein einheitliches QR-Format als technische Grundlage für ein vereinfachtes Handling etablieren. Die Allianz aus sechs europäischen Bezahldiensten und Alipay aus China ist eine ernstzunehmende Konkurrenz für Google, Apple, Facebook, Amazon.
Von Sabine T. Ruh


    Hyundai Kona Elektro: Der Ausdauerläufer
    Hyundai Kona Elektro
    Der Ausdauerläufer

    Der Hyundai Kona Elektro begeistert mit Energieeffizienz, Genauigkeit bei der Reichweitenberechnung und umfangreicher technischer Ausstattung. Nur in Sachen Emotionalität und Temperament könnte er etwas nachlegen.
    Ein Praxistest von Dirk Kunde

    1. Elektroauto Neuer Chevrolet Bolt fährt 34 km weiter
    2. Elektroauto Porsches Elektroauto Taycan im 24-Stunden-Dauertest
    3. Be emobil Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt

    1. UMTS: 3G-Abschaltung kein Thema für die Bundesregierung
      UMTS
      3G-Abschaltung kein Thema für die Bundesregierung

      Nutzer, die kein LTE in ihren Verträgen festgeschrieben haben, sollten wechseln, da 3G zunehmend abgeschaltet werde. Das erklärte das Bundesverkehrsministerium und sieht keinen Grund zum Eingreifen.

    2. P3 Group: Wo die Mobilfunkqualität in Deutschland am niedrigsten ist
      P3 Group
      Wo die Mobilfunkqualität in Deutschland am niedrigsten ist

      Die Qualität des Mobilfunks in Deutschland ist in den einzelnen Bundesländern sehr unterschiedlich. Dort, wo Funklöcher gerade ein wichtiges Thema sind, ist die Versorgung gar nicht so schlecht.

    3. Mecklenburg-Vorpommern: Funkmastenprogramm verzögert sich
      Mecklenburg-Vorpommern
      Funkmastenprogramm verzögert sich

      Wegen fehlender Zustimmung der EU ist das Geld für ein Mobilfunkprogramm in Mecklenburg-Vorpommern noch nicht verfügbar. Dabei hat das Bundesland laut einer P3-Messung große Probleme.


    1. 18:00

    2. 18:00

    3. 17:41

    4. 16:34

    5. 15:44

    6. 14:42

    7. 14:10

    8. 12:59