One of the performance pitfalls in Julia is allocations, especially in loops. For instance, with lots of arrays being created inside a long loop. This can be handled by creating “workspaces” and then filling/overwriting the arrays inside the loop. Unfortunately, however, that often leads to code th…

I wouldn’t really recommend it to beginners, but my package GitHub - MasonProtter/Bumper.jl: Bring Your Own Stack is specifically designed for speeding up this pattern of allocating intermediate arrays, using them, then deallocating them soon afterwards.

There is a set of optimizations a sufficiently smarter optimizer can do. We are sometimes to hoist and allocation outside of a loop / or sink it outside that loop. This currently only happens for Julia objects and not arrays and it happens fairly late in the pipeline (LLVM passes). I do believe th…

[image] Paul_Soderlind: For instance, by letting local X inside a loop mean that that X is created in the first iteration and subsequently any X = will lead to mutating the existing X? This particular proposal would break backwards compatibility, which is a no-go: [image] P…

[image] Paul_Soderlind: Therefore, my question: could “compiler” development possibly help the users with this? This seems like one possible feature that could help, in addition to the already existing features like the allocation profilers.

It’s not a proposal (as I am not qualified to make one). Rather, just an attempt to explain a general idea/question. (Of course we cannot change local, so let’s call it local2.)

[image] Paul_Soderlind: Therefore, my question: could “compiler” development possibly help the users with this? For instance, by letting local X inside a loop mean that that X is created in the first iteration and subsequently any X = will lead to mutating the existing X? Problem is this isn…

[image] Benny: Allocating X before the loop and writing mutation code in the loop is clearer and less effort Not always; especially when you have to calculate types for a container. I am sympathetic to @Paul_Soderlind ’s problem, as I often encounter it when solving economic models. Specifica…

[image] Tamas_Papp: Not always; especially when you have to calculate types for a container. I think I’m misunderstanding this, because if the array in every iteration doesn’t have the same element type, then it would be impossible to refactor to reuse of 1 array across iterations. Doesn’t so…

I’m confused because your phrasing sounds like you are disagreeing with Tamas, but then you seem to just be restating his point: just preallocating an array and re-using it can be really awkward if you want to use it to store different types in different places.

[image] Benny: if the array in every iteration doesn’t have the same element type In practice it is restricted to a few types (eg Float64, and the corresponding ForwardDiff.Dual{nightmare}), or maybe BigFloat when I am doing numerical debugging. Within the same evaluation, it is the same type…

Loops, allocations and helping the coder

Internals & Design

nsajko October 8, 2023, 7:22pm 4

This particular proposal would break backwards compatibility, which is a no-go:

Topic		Replies	Views
Why is Julia's performance more sensitive to memory allocations than Numpy's? Performance	19	1333	September 5, 2024
Non-escaping array buffer re-use and the sufficiently smart compiler Internals & Design	11	1017	February 21, 2021
Common allocation mistakes Performance memory-allocation	47	7750	August 21, 2023
Reducing allocations to optimize (to match Java speed) Performance	22	1478	December 10, 2018
Increase in allocations with Julia v1.11-beta Internals & Design performance , arrays	46	3428	May 8, 2024

Loops, allocations and helping the coder

Related topics