4 ms·
I think when comparing numbers like that you might need throughput figures as well. Supposedly there is a tradeoff between GC pauselessness and throughput.
by nulltype 10y ago
I think when comparing numbers like that you might need throughput figures as well. Supposedly there is a tradeoff between GC pauselessness and throughput.
- emmelaich 10y ago"Supposedly?" I would have thought inevitably.
- nulltype 10y agoWell I've never implemented a GC or built a processor specifically for implementing GC on.
- snaky 10y agoYes, it's being discussed recently https://news.ycombinator.com/item?id=12044044 https://news.ycombinator.com/item?id=12044044
- cliffc 10y agoAzul's GC required a read-barrier (some instructions to be executed on every pointer read) - which cost something like 5% performance on an X86. In exchange max GC pause time is something in the low microsecond range (I helped implement the Azul JVM and portions of the GC relating to starting and stopping threads)
- Gibbon1 10y agoA friend of mine that worked for Azul said that older 0x86 processors didn't support the instructions that they needed. Which is why originally they built their own hardware. I'm uncertain what those are, but my impression is you can't do what they needed with a single atomic word access.
- sievebrain 10y agoThere's a talk somewhere (by Cliff again) on how the Azul chips differed from x86. Intel seems really slow to add features useful for high level GCd languages but apparently nowadays x86 has caught up which is why they don't bother making their own chips anymore.
- cliffc 10y agoNo change to the X86, instead user-mode TLB handler from RedHat allows ptr-swizzeling, that plus some careful planning and the read barrier fell to 2 X86 ops - with acceptable runtime costs. Cliff