4 ms·

> We have multiple open-source pauseless miracles GCs right there in front of us Can you share some links/references?

by iyn 3mo ago

quotemstr 3mo ago
ZGC is extremely good work. https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main > ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB. Go's GC is also very good: https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc. V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.) I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.
- platinumrad 3mo ago
  If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.
  - phplovesong 3mo ago
    You just described http://www.lisette.run http://www.lisette.run
  - mappu 3mo ago
    Cgo is cheap these days, don't worry about it. It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
    - throwaway17_17 3mo ago
      Do you know of any articles, tests, or implementation breakdowns that show this. I don’t have the personal experience to agree, but if that’s the case Inwould really like to know how the improvements were achieved.
      - mappu 3mo ago
        It was somewhat slow about a decade ago - you can see - (2015, Go 1.5) Calls cost about 170ns https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o... - (2017, Go 1.8) Cgo speedup by 50% https://go.dev/doc/go1.8#cgoperf https://go.dev/doc/go1.8#cgoperf - (2023, Go 1.21) Calls cost about 40ns https://shane.ai/posts/cgo-performance-in-go1.21/ https://shane.ai/posts/cgo-performance-in-go1.21/ - (2026, Go 1.26) Cgo speedup by another 30% https://go.dev/doc/go1.26#faster-cgo-calls https://go.dev/doc/go1.26#faster-cgo-calls A current benchmark shows a Cgo function call as costing about 25 ns. https://gist.github.com/DeedleFake/2f50b02c0708484c66d18253302c4fd6 https://gist.github.com/DeedleFake/2f50b02c0708484c66d182533...
- adastra22 3mo ago
  A millisecond is an eternity. It is 1/3 of the entire time allocated to a frame update in a modern game.
  - quotemstr 3mo ago
    Various GCs can go faster now too. JEP 376 talks about hundreds-of-microsecond work done in pause now that GC no longer has to scan the whole stack. That said: 1ms? 1ms is getting into the sorts of latency the OS and hardware impose on your program no matter what it does. For example, on x86, a SMI can take 300us, or 1000us if you're unlucky. I've seen softirqs for shitty wifi chips take a hundred milliseconds! And God help you if you take a hard page fault: You're worried about 1ms latencies, right? So you're mlock()ing all memory? Running RT threads pinned to cores? Carefully using PI and static priorities to avoid inversions? Avoiding blocking IO everywhere, not even for graphics page-flipping? Managing thermal headroom to avoid involuntary clock collapses? And it should go without saying, but I have to ask: you're running a PREEMPT_RT kernel, right? No? You're not doing any of these things? Then why are you worried about 1ms in GC?
    - adastra22 3mo ago
      Yes, I am. That’s why I develop on a systems programming language, and why systems programming and GC are not compatible.
      - throwaway17_17 3mo ago
        I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses: - infrastructure development like Docker and Kubernetes - general utilities programming like grep, terminal emulators, compilers, etc - performance sensitive artifacts like OS kernels, video/audio codecs, hardware interaction layers and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology. I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.
- RedComet 3mo ago
  Are any of those actually pauseless like he asked for?
- yunuskusak 3mo ago
  [flagged]
elitepleb 3mo ago
https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/libpas/fugc.c#L41 https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...

> We have multiple open-source pauseless miracles GCs right there in front of us Can you share some links/references?

by iyn 3mo ago

> We have multiple open-source pauseless miracles GCs right there in front of us Can you share some links/references?

ZGC is extremely good work. https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main > ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB. Go's GC is also very good: https://go.dev/blog/greenteagc https://go.dev/blog/greenteagc. V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.) I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.

platinumrad 3mo ago
If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.
- phplovesong 3mo ago
  You just described http://www.lisette.run http://www.lisette.run
- mappu 3mo ago
  Cgo is cheap these days, don't worry about it. It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
  - throwaway17_17 3mo ago
    Do you know of any articles, tests, or implementation breakdowns that show this. I don’t have the personal experience to agree, but if that’s the case Inwould really like to know how the improvements were achieved.
    - mappu 3mo ago
      It was somewhat slow about a decade ago - you can see - (2015, Go 1.5) Calls cost about 170ns https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o... - (2017, Go 1.8) Cgo speedup by 50% https://go.dev/doc/go1.8#cgoperf https://go.dev/doc/go1.8#cgoperf - (2023, Go 1.21) Calls cost about 40ns https://shane.ai/posts/cgo-performance-in-go1.21/ https://shane.ai/posts/cgo-performance-in-go1.21/ - (2026, Go 1.26) Cgo speedup by another 30% https://go.dev/doc/go1.26#faster-cgo-calls https://go.dev/doc/go1.26#faster-cgo-calls A current benchmark shows a Cgo function call as costing about 25 ns. https://gist.github.com/DeedleFake/2f50b02c0708484c66d18253302c4fd6 https://gist.github.com/DeedleFake/2f50b02c0708484c66d182533...
adastra22 3mo ago
A millisecond is an eternity. It is 1/3 of the entire time allocated to a frame update in a modern game.
- quotemstr 3mo ago
  Various GCs can go faster now too. JEP 376 talks about hundreds-of-microsecond work done in pause now that GC no longer has to scan the whole stack. That said: 1ms? 1ms is getting into the sorts of latency the OS and hardware impose on your program no matter what it does. For example, on x86, a SMI can take 300us, or 1000us if you're unlucky. I've seen softirqs for shitty wifi chips take a hundred milliseconds! And God help you if you take a hard page fault: You're worried about 1ms latencies, right? So you're mlock()ing all memory? Running RT threads pinned to cores? Carefully using PI and static priorities to avoid inversions? Avoiding blocking IO everywhere, not even for graphics page-flipping? Managing thermal headroom to avoid involuntary clock collapses? And it should go without saying, but I have to ask: you're running a PREEMPT_RT kernel, right? No? You're not doing any of these things? Then why are you worried about 1ms in GC?
  - adastra22 3mo ago
    Yes, I am. That’s why I develop on a systems programming language, and why systems programming and GC are not compatible.
    - throwaway17_17 3mo ago
      I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses: - infrastructure development like Docker and Kubernetes - general utilities programming like grep, terminal emulators, compilers, etc - performance sensitive artifacts like OS kernels, video/audio codecs, hardware interaction layers and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology. I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.
RedComet 3mo ago
Are any of those actually pauseless like he asked for?
yunuskusak 3mo ago
[flagged]

elitepleb 3mo ago

https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/libpas/fugc.c#L41 https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...