Do Garbage Collectors necessarily make code slow?

The compiler is getting better. There was a big improvement in Julia 1.5 for structs containing heap allocated objects no longer themselves always being heap allocated (e.g. SubArrays created from views), but things like non-escaping MArrays were non(-heap) allocating for a very long time.
The difficulty is the non-escaping part, which can eventually be made easier with escape analysis…

4 Likes

This should really get upstreamed to Base, not just because it’s a runtime improvement but also because it’s a non-trivial compile time improvement in some cases.

4 Likes

In updating the loop unswitching pass for the new pass manager, LLVM also broke it for some important Julia cases that aren’t tested within LLVM itself.
This is one of the things blocking an LLVM upgrade at the moment.
Test added to catch that in Julia:

Aside from all our efforts on improving SciML runtime and compile times, it was funny that it also came up recently as blocking a major upgrade, thanks to relying on the fickle compiler.

The thing about broadcasting vs loops is that broadcasting is better for generic code, where you may have some sort of GPUArray or a SparseArray, so we really don’t want to discourage using broadcasting.
I wish broadcasts didn’t broadcast. Instead, we have to make the best out of these semantics that we can.

1 Like

I many times wish . defaulted to map and it needed an @broadcast or something to mean broadcast.

4 Likes