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

[Anonymer Nutzer]

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.

[EQuatschBob]

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.

[Klau3]

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

[pythoneer]

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.

[pythoneer]

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.

[stiGGG]

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?

[crypt0]

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)

[pythoneer]

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.

[pythoneer]

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.

[crypt0]

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

[pythoneer]

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.

[apriori]

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