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

Für den Client vielleicht machbar, für NTP-Server sicher nicht.

  1. Thema

Neues Thema Ansicht wechseln


  1. Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: DebianFan 04.01.17 - 14:51

    Die Server müssen Millionen von Anfragen beantworten, wenn das halbwegs effizient ablaufen soll, führt an C/C++ kein Weg vorbei.

    Für einen Client, der alle paar Stunden mal nach der Zeit fragt, ist das egal. Da kann man fast jede Programmiersprache nehmen.

  2. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: EQuatschBob 04.01.17 - 15:05

    DebianFan schrieb:
    --------------------------------------------------------------------------------
    > Die Server müssen Millionen von Anfragen beantworten, wenn das halbwegs
    > effizient ablaufen soll, führt an C/C++ kein Weg vorbei.

    Go hat da natürlich den Nachteil des GC, aber was spricht gegen Rust?
    Warum sollte Rust weniger effizient sein als C?
    Im Gegensatz zu Go soll es ja auch für systemnahe und zeitkritische Anwendungen taugen.

  3. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: Klau3 04.01.17 - 15:42

    EQuatschBob schrieb:
    --------------------------------------------------------------------------------
    > Go hat da natürlich den Nachteil des GC...
    Der Go garbage-collector wir mit der nächsten Version ein stop-the-world Pause von Durchschnittlich 10 μs, im Extremfall von 100 μs haben. - ja, Mikrosekunden.

    Ich verstehe nicht wie man da noch drauf herumreiten kann :|

  4. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: pythoneer 04.01.17 - 15:44

    Die momentan schnellste (mini) HTTP-Server Implementierung ist in Rust genauso wie die schnellste Implementierung für Font-Rendering. Rust "sollte" so schnell sein wie C (zero overhead) alles andere kann als "Bug" angesehen werden. Jedoch ist die Rust Implementierung nicht frei von solchen Bugs ;) Für die Zukunft kann Rust auch schneller als C werden beim beibehalten der Garantien. Aber das spielt sich dann alles im magischen Land der Compileroptimierungen ab und so nen Hokus Pokus kann ein C Compiler meist auch (theoretisch) besonders weil ein C Compiler auf undefined behavior für die Optimierung setzen kann. Rust wird mit MIR(https://blog.rust-lang.org/2016/04/19/MIR.html) aber bald auch dafür was in der Hand haben. Das ist aber alles gar nicht so wichtig, wichtig ist, dass Rust in der selben Liga wie C spielt was die Geschwindigkeit angeht aber zusätzlich halt die Sicherheit mit bringt.

  5. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: pythoneer 04.01.17 - 15:49

    Klau3 schrieb:
    --------------------------------------------------------------------------------
    > Der Go garbage-collector wir mit der nächsten Version ein stop-the-world
    > Pause von Durchschnittlich 10 μs, im Extremfall von 100 μs haben.
    > - ja, Mikrosekunden.
    >
    > Ich verstehe nicht wie man da noch drauf herumreiten kann :|

    Ganz einfach, weil das eben nicht das Hauptkriterium für einen GC ist. Das "Problem" mit dem Go GC ist, dass er – scheinbar aus PR Gründen – auf genau eben jenes Kriterium so viel Wert setzt, dass andere Bereiche völlig vernachlässigt werden. Diese Strategie scheint auch gut zu funktioniere, weil es sehr wenig Kritik diesbezüglich gibt wie Einseitig sich der Go GC hier platziert. Für mich sieht das so aus, als hätten die Go Entwickler eben erkannt, kann die meiste Diskussion über einen GC – wenn auch falsch – über jenes Kriterium ist. Und aus PR Gründen wird dieser nun – koste es was es wolle – klein gehalten. Scheinbar funktioniert diese Strategie ausgezeichnet.

  6. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: stiGGG 04.01.17 - 15:55

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Die momentan schnellste (mini) HTTP-Server Implementierung ist in Rust
    > genauso wie die schnellste Implementierung für Font-Rendering. Rust
    > "sollte" so schnell sein wie C (zero overhead) alles andere kann als "Bug"
    > angesehen werden. Jedoch ist die Rust Implementierung nicht frei von
    > solchen Bugs ;) Für die Zukunft kann Rust auch schneller als C werden beim
    > beibehalten der Garantien.

    Ist es bei den LLVM basierenden Sprachen nicht so, dass die wirklichen Optimierungen im Backend stattfinden und wenn die Frontends wie clang, rust oder swift den gleichen Bitcode generieren hier kein Unterschied mehr bestehen dürfte?

  7. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: crypt0 04.01.17 - 16:01

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Ganz einfach, weil das eben nicht das Hauptkriterium für einen GC ist. Das
    > "Problem" mit dem Go GC ist, dass er – scheinbar aus PR Gründen
    > – auf genau eben jenes Kriterium so viel Wert setzt, dass andere
    > Bereiche völlig vernachlässigt werden.

    Was wären das denn für Aufgabenbereiche? Ein GC soll den "Müll einsammeln" und das mit so wenig overhead wie möglich (Time,Memory,Latency)

  8. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: pythoneer 04.01.17 - 16:07

    stiGGG schrieb:
    --------------------------------------------------------------------------------
    > Ist es bei den LLVM basierenden Sprachen nicht so, dass die wirklichen
    > Optimierungen im Backend stattfinden und wenn die Frontends wie clang, rust
    > oder swift den gleichen Bitcode generieren hier kein Unterschied mehr
    > bestehen dürfte?

    Du hast hier im Grunde recht. Also eigentlich hast du absolut recht was bei Rust aber halt gerade passiert ist MIR womit Optimierungen möglich werden die vorher in HIR oder dem üblichen "selbst geschriebenen" Teil des Rustcompilers nicht möglich waren. Nachdem Rust also nach LLVM IR überführt und an LLVM übergeben wurde weiß LLVM natürlich nichts mehr über die Garantien die Rust bietet und kann diese nicht nutzen um zu optimieren. Mit dem "alten" HIR in Rust sind aber noch keine wirklichen Optimierungen möglich gewesen, da das an dem Punkt noch zu "Roh" war. Mit MIR will man das schon selber im "selbst geschriebenen" des Compilers machen wo die Garantien noch "sichtbar sind" und diese nutzen um Optimierungen machen zu können die der LLVM gar nicht mehr machen kann, weil die Garantien nicht mehr in der Zwischensprache die zum LLVM Backend geschickt werden zu erkennen sind.

  9. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: pythoneer 04.01.17 - 16:22

    crypt0 schrieb:
    --------------------------------------------------------------------------------
    > Was wären das denn für Aufgabenbereiche? Ein GC soll den "Müll einsammeln"
    > und das mit so wenig overhead wie möglich (Time,Memory,Latency)

    Da gebe ich dir recht. Nur misst man "overhead" nicht in der Einheit "stop-the-world Pause" – dem einzigen Kriterium dem scheinbar Beachtung geschenkt wird. Weitere wichtige – und bei weitem nicht die einzigen – Kriterien sind:

    Program throughput – wie sehr verlangsamt der GC algo das eigentliche Programm

    GC throughput – wie viel kann der GC bereinigen bei fixer CPU zeit

    Heap overhead – wie viel zusätzlicher Speicher für den GC wird benötigt

    Pause times – das schon angesprochene stop the world

    Pause frequency – wie oft trift das ein

    Pause distribution – wie ist das verteilt

    Allocation performance – wie schnell kann neuer Speicher angelegt werden

    Compaction – kann der GC OOM verstehen und wie läuft die Defragmentierung

    Concurrency – wie gut kann er mit Multi-Cores umgehen

    Scaling – wie gut funktionier der GC wenn der Heap größer wird

    Tuning – gibt es Stellschrauben

    Warmup time – kann sich der GC auf bestimmte Szenarien einstellen und wie lange braucht er dafür

    Page release – gibt der GC jemals Speicher ans System zurück, wenn ja wie

    Portability – läuft der auch auf nicht x86 Speichermodellen

    Compatibility – kann man den GC mit Sprachen verwenden die kein GC können C++

    und da gibt es sicherlich noch viele weitere die ich hier gerade einfach mal vergessen habe. GC ist eine verdammt komplizierte Wissenschaft und ist nicht mit
    mach die stop the word Time einfach klein ab gefrühstückt.



    1 mal bearbeitet, zuletzt am 04.01.17 16:23 durch pythoneer.

  10. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: crypt0 04.01.17 - 16:42

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > Nur misst man "overhead" nicht in der Einheit
    > "stop-the-world Pause" – dem einzigen Kriterium dem scheinbar
    > Beachtung geschenkt wird. Weitere wichtige – und bei weitem nicht die
    > einzigen –

    Das ist mir schon klar, aber Go ist eine Sprache, die aktuell vorallem Serveranwendungen fucusiert - da ist eine hohe Latenz (lange stop-the-world phasen) ziemlich ärgerlich -> deshalb auch das Ziel: 10 < pause < 100
    Das GCs ein extrem schwieriges Feld sind, dürfte keiner bestreiten.
    Soweit mir aber bekannt ist der Go-GC einer der "besten" seiner Klasse (concurrent mark and sweep/compact) - Was die aktuell Verbesserungen/Ziele des GCs sind, müsste ich jett im GC-dev branch nachschauen...

  11. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: pythoneer 04.01.17 - 16:56

    crypt0 schrieb:
    --------------------------------------------------------------------------------
    > Das ist mir schon klar, aber Go ist eine Sprache, die aktuell vorallem
    > Serveranwendungen fucusiert - da ist eine hohe Latenz (lange stop-the-world
    > phasen) ziemlich ärgerlich -> deshalb auch das Ziel: 10 < pause < 100
    > Das GCs ein extrem schwieriges Feld sind, dürfte keiner bestreiten.


    Mein Post bezog sich grundlegend auf die Aussage von Klau3, warum man sich noch über GC aufregt oder ihn als Nachteil betrachten kann, wo doch "alle" Probleme scheinbar gelöst sind.

    > Soweit mir aber bekannt ist der Go-GC einer der "besten" seiner Klasse

    Ja das stimmt, die Klasse hat aber auch nicht sonderlich viele Schüler ;) Und ich behaupte auch nicht, dass der Go GC Schrott ist. Ich sage nur "aber der Go GC hat ganz kleine stop the world Zeiten" ist kein Argument für "Es gibt keine Probleme oder Nachteile beim Go GC".

    > (concurrent mark and sweep/compact) - Was die aktuell Verbesserungen/Ziele
    > des GCs sind, müsste ich jett im GC-dev branch nachschauen...

    Und das ist doch schon mal ein Problem mehr – HotSpot JVM hat mehrere Algorithmen zum auswählen, je nachdem welche Tradeoffs gerade zu meinem Problem passen. Das kann ich beim Go GC nicht und damit ist es eine "Insellösung" für eine bestimmte Problemklasse und noch mehr für eine Problemklasse wo nur stop the world zählt und alles andere was ich aufgezählt habe vernachlässigt werden kann (Speicherverbrauch, ausbremsen des Hauptprogramms, langsame Speicherallozierung etc. )



    1 mal bearbeitet, zuletzt am 04.01.17 16:57 durch pythoneer.

  12. Re: Für den Client vielleicht machbar, für NTP-Server sicher nicht.

    Autor: apriori 11.04.19 - 22:19

    Eigentlich kann man das ganze einfacher Ausdrücken. Da auf dem Weg zu LLVM IR nur noch kleinschrittige Operationen übrig bleiben, geht absolut jede Sicht für die "übergeordnete Problemstellung" verloren und muss aufwendig und insbesondere invers bestimmt werden. Hier kommen Optimierer gerne mal an Grenzen (ist auch irgendwo klar, da diese Richtung viel schwerer ist).

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Service-Reisen Heyne GmbH & Co. KG, Gießen
  2. Berliner Stadtreinigungsbetriebe (BSR), Berlin
  3. SYNGENIO AG, Hamburg, Bonn, Frankfurt am Main, Stuttgart, München
  4. Hays AG, Ruhrgebiet

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 2,99€
  2. 48,49€
  3. 32,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ricoh GR III im Test: Kompaktkamera mit Riesensensor, aber ohne Zoom
Ricoh GR III im Test
Kompaktkamera mit Riesensensor, aber ohne Zoom

Kann das gutgehen? Ricoh hat mit der GR III eine Kompaktkamera im Sortiment, die mit einem APS-C-Sensor ausgerüstet ist, rund 900 Euro kostet und keinen Zoom bietet. Wir haben die Kamera ausprobiert.
Ein Test von Andreas Donath

  1. Theta Z1 Ricoh stellt 360-Grad-Panoramakamera mit Profifunktionen vor
  2. Ricoh GR III Eine halbe Sekunde Belichtungszeit ohne Stativ

In eigener Sache: Neue Workshops zu agilem Arbeiten und Selbstmanagement
In eigener Sache
Neue Workshops zu agilem Arbeiten und Selbstmanagement

Wir haben in unserer Leserumfrage nach Wünschen für Weiterbildungsangebote gefragt. Hier ist das Ergebnis: Zwei neue Workshops widmen sich der Selbstorganisation und gängigen Fehlern beim agilen Arbeiten - natürlich extra für IT-Profis.

  1. Golem Akademie Golem.de startet Angebote zur beruflichen Weiterbildung
  2. In eigener Sache Zweiter Termin für Kubernetes-Seminar
  3. Leserumfrage Wie können wir dich unterstützen?

Razer Blade 15 Advanced im Test: Treffen der Generationen
Razer Blade 15 Advanced im Test
Treffen der Generationen

Auf den ersten Blick ähneln sich das neue und das ein Jahr alte Razer Blade 15: Beide setzen auf ein identisches erstklassiges Chassis. Der größte Vorteil des neuen Modells sind aber nicht offensichtliche Argumente - sondern das, was drinnen steckt.
Ein Test von Oliver Nickel

  1. Blade 15 Advanced Razer packt RTX 2080 und OLED-Panel in 15-Zöller
  2. Blade Stealth (2019) Razer packt Geforce MX150 in 13-Zoll-Ultrabook

  1. Digitale Souveränität: Bundesregierung treibt den Aufbau einer Europa-Cloud voran
    Digitale Souveränität
    Bundesregierung treibt den Aufbau einer Europa-Cloud voran

    Aus Angst vor Industriespionage will die Bundesregierung eine Europa-Cloud - in Abgrenzung zu Anbietern wie Amazon, Microsoft und Google, die nach dem CLOUD-Act, den US-Behörden weitreichende Zugriffe auf die Daten geben müssen, auch wenn sie nicht in den USA gespeichert sind.

  2. 3G: Huawei soll Mobilfunknetz in Nordkorea ausgerüstet haben
    3G
    Huawei soll Mobilfunknetz in Nordkorea ausgerüstet haben

    Die Washington Post will Dokumente erhalten haben, die belegen sollen, dass Huawei ein Mobilfunknetz in Nordkorea ausgerüstet habe. Huawei hat dies dementiert.

  3. 5G-Media Initiative: Fernsehen über 5G geht nicht einfach über das Mobilfunknetz
    5G-Media Initiative
    Fernsehen über 5G geht nicht einfach über das Mobilfunknetz

    In einem Streit unter den Öffentlich-Rechtlichen wird dem Intendanten des Deutschlandradios erklärt, dass Rundfunk über 5G nicht einfach über die Netze der kommerziellen Betreiber ginge. Der Intendant hatte die Technik nicht ganz verstanden.


  1. 21:15

  2. 20:44

  3. 18:30

  4. 18:00

  5. 16:19

  6. 15:42

  7. 15:31

  8. 15:22