Thread replies: 9
Thread images: 1
Thread images: 1
File: go-tool-trace-gc-pause-1024x330.png (61KB, 1024x330px) Image search:
[Google]
61KB, 1024x330px
Not all garbage collectors are created equal:
https://gitlab.com/gasche/gc-latency-experiment
> Without further ado, here are the benchmark results on my system: (Longest pause in ms)
> OCaml 4.03.0 (map based) (manual timing) 2.21
> Haskell/GHC 8.0.1 (map based) (rts timing) 67.00
> Haskell/GHC 8.0.1 (array based) (rts timing) [1] 58.60
> Racket 6.6 experimental incremental GC (map based) (tuned) (rts timing) 144.21
> Racket 6.6 experimental incremental GC (map based) (untuned) (rts timing) 124.14
> Racket 6.6 (map based) (tuned) (rts timing) [2] 113.52
> Racket 6.6 (map based) (untuned) (rts timing) 136.76
> Go 1.7.3 (array based) (manual timing) 7.01
> Go 1.7.3 (map based) (manual timing) 37.67
> Go HEAD (map based) (manual timing) 7.81
> Java 1.8.0_102 (map based) (rts timing) 161.55
> Java 1.8.0_102 G1 GC (map based) (rts timing) 153.89
So where does your favorite language's garbage collector rank?
>>
no .net, just shit tier GCs...
>>
>>57926064
>garbage collector
How about you learn to manage your own memory, and learn a real language. Quit being a lazy faggot, anon.
>>
>>57926213
There are two big memory management lies when it comes to programming languages.
The first is that garbage-collection means you don't have to worry about allocating and freeing memory.
The second is that manual memory management means you don't have to worry about speed and efficiency.
Now, it is true that manual memory management can always be optimized to be faster and use less memory than garbage collection. But that takes time and effort, and there are very few instances where that level of optimization is necessary or even desirable.
There is no such thing as a free lunch.
>>
>>57926409
>The first is that garbage-collection means you don't have to worry about allocating and freeing memory.
Huh? How is that wrong?
>>
>>57926513
Not him, but in Java, the GC doesn't delete objects if they are assigned to references. You have to free up the objects after their use is over to ensure that they can be deleted by the GC.
I assume other languages' GCs have similar mechanisms
>>
>>57926409
Another thing that most people get wrong about garbage collection:
GC time is not related to the amount of garbage you have, it's related to the amount of non-garbage you have.
Basically, if your GC takes too long then you shouldn't try and reduce the amount of garbage that needs collecting, you should try and reduce the amount of memory your program uses.
>>
>>57926064
>The workflow (allocating N 1Kio strings with only W kept in memory at any time, and the oldest string deallocated) comes from James Fischer's blog post Low latency, large working set, and GHC’s garbage collector: pick two of three, May 2016, who identified it as a situation in which the GHC garbage collector (Haskell) exhibits unpleasant latencies.
Yes, let's use a benchmark that is known to trigger worst case behavior in GHC. That sure sounds like a fair and valid comparison
>>
>>57926064
That “manual timing” technique seems complete bogus
I noticed all of the “manual timing” languages are the ones that seem to have exceptionally low scores. The author should compare the validity of the manual timing approach by seeing if the “manual timing” numbers match the rts numbers for the languages that report the latter.
Thread posts: 9
Thread images: 1
Thread images: 1