4 ms·
Julia has a big culture and a lot of interfaces built around writing non-allocating code. We sometimes even overemphasize eliminating GC allocations from stuff.
by eigenspace 8mo ago
Julia has a big culture and a lot of interfaces built around writing non-allocating code. We sometimes even overemphasize eliminating GC allocations from stuff.
Generally, the code ends up looking rather similar to non-GC languages. You create some buffers outside of your performance-sensitive parts, and then thread them through your code so they can be accessed and re-used in the hot loop or whatever.
It could be better, e.g. C++ and Rust both have some nice utilities for this stuff that are a bit hard to replicate in Julia, but it's not auch a huge difference, and there's also a lot of advantages on the julia side.
E.g. it's really nice to have the GC available for the non-performance critical parts of your code.
- VorpalWay 8mo agoSince I don't know Julia, let me ask: how easy is it to add a use of the GC by mistake in a critical part of the code (maybe a junior dev does it)? Are there any tools to lint against that (some sort of function attribute to deny uses of GC in the function perhaps)? If it happens, how hard is it find the culript lines of code? Because from what I have seen in other GC languages, the answers to any of those questions haven't been great.
- SatvikBeri 8mo agoYou can use AllocCheck.jl to guarantee your code doesn't allocate. It's conservative, so it'll sometimes throw false positives, but shouldn't throw false negatives. You apply the checks to function definitions. You can profile memory usage line by line in detail pretty easily with tools like @timeit or @btime In practice I've found it pretty easy to get inner loops down to few or 0 allocations when needed for parallelization
- dandanua 8mo agoIt's easy to add, yes. However, the basic @time macro outputs the info about allocations by default. So it is also easy to see if there is a problem.
- eigenspace 8mo agoTooling for this in julia is evolving, but currently works fairly well. It could be better, but could be a lot worse. There's static analysis tools that might be over-eager finding allocations, and there's also runtime measurement tools which should go into your test suite if it's of vital importance to monitor.
- pjmlp 8mo agoAdditionally, the HPC folks are looking into Chapel, which also has a mixed mode approach to memory management, similar to Swift with memory ownership, than either C++ as it has always been, or looking into Rust. Turns out a little bit of ergonomics actually matter.