Are you sure that allocation is a problem? Nursery allocation is extremely fast: it's just one overflow check and a pointer bump. Usually it's around 3-6 instructions.
Allocation in modern generational GCs is in a completely different performance category than C-style malloc is.
That said, I don't actually know allocation is the problem; it's a suspect, but unlike a native script I can't just run `perf` to get performance counters and assembly listings. All I really know is that the non-allocating order is a lot faster.
[1]: If you can read assembly, this one's hilarious: https://godbolt.org/g/81qWoq
I only barely read assembly, so I was just trying to figure this one out.
So, the compiler has figured out that it just needs to test v against 0 (since the array is immutable), but it does this 2 times, and with a couple of apparently redundant 'je' instructions. Is that what's weird about the output?
In case it changed, this is the output I saw:
example::exists_in_table:
push rbp
mov rbp, rsp
mov al, 1
test edi, edi
je .LBB0_5
je .LBB0_5
test edi, edi
je .LBB0_5
je .LBB0_5
xor eax, eax
.LBB0_5:
pop rbp
retIf I write it as some C
bool should_jump = edi == 0;
if (should_jump) goto LBB0_5;
if (should_jump) goto LBB0_5;
bool should_jump = edi == 0;
if (should_jump) goto LBB0_5;
if (should_jump) goto LBB0_5;
br i1 false, label %bb9, label %bb6
I've opened a (a bit vague for now) issue so at least I don't forget about it: https://github.com/rust-lang/rust/issues/44041
As for phase ordering - someone did show me recently VSDG, which claims to solve at least part of the problem (specifically, https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-705.pdf and http://sro.sussex.ac.uk/7576/1/Stanier%2C_James.pdf).
Thanks for the heads up.
Yes and no. If enough allocation happens that a GC pass occurs while you're still running your JS hot loop you're pretty much screwed and all your performance vanishes. If you want to see this in the extreme go open an Android systrace or Chrome chrome://tracing trace result and do a JS profile while you do so. The single largest consumer of JS CPU time is the GC at nearly 13%.
The problem with modern generation GC langauges is they tend to be designed assuming that allocation is always cheap/free and it just isn't. That's a fairytale. It's just not true.
Also just because it only takes 6-13ns for an allocation to be given to you doesn't mean anything when the first access of that allocation is a cache line miss compared to if you did the same thing in C and it was on the stack, which is likely sitting in hot L1 primed and ready to go. Reusing the same memory address range is critical to getting maximum performance, and modern generational GCs are miserably bad at that.
GCs are expensive relative to not doing anything, but minor GCs are very fast.
> The problem with modern generation GC langauges is they tend to be designed assuming that allocation is always cheap/free and it just isn't. That's a fairytale. It's just not true.
I'm not making an argument about language design here. Obviously value types are a good thing.
> Reusing the same memory address range is critical to getting maximum performance, and modern generational GCs are miserably bad at that.
Not at all. The nursery is usually in cache, just as the stack is. Nurseries are usually implemented as two space copying collectors with small spaces, which are excellent for cache locality (arguably even better than stacks, because stacks can grow deep).
I think you're still working under the assumption that the GC is keeping up with the allocation rate, which if you have a small allocation in a hot loop will largely not be true. Typically GC'd languages rely on escape analysis to handle this and not the generational GC at all, but if that fails then you're SOL because the generational GC is unable to keep up and unable to keep things in the fast path.
No, they don't. Most GC'd languages rely on generational GC, because escape analysis on its own doesn't directly provide a lot of performance benefits once you have a generational GC.
> if that fails then you're SOL because the generational GC is unable to keep up and unable to keep things in the fast path.
No, you aren't. Cleaning up dead objects (for example, temporaries created in a hot loop) in a nursery is extremely fast. The entire nursery semispace is typically in L1.
The entire nursery semispace is typically in L1.
If you read a bunch of data before making an object, I could see you easily evicting your nursery from L1 into L2, but then you only have about 4x as much space.