# What's Julia's memory model like; e.g. regarding aliasing?

**URL:** <https://discourse.julialang.org/t/whats-julias-memory-model-like-e-g-regarding-aliasing/12565>\
**Category:** General Usage\
**Tags:** aliasing\
**Created:** [July 21, 2018, 4:56pm UTC](https://discourse.julialang.org/t/whats-julias-memory-model-like-e-g-regarding-aliasing/12565 "2018-07-21T16:56:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [July 21, 2018, 4:56pm UTC](https://discourse.julialang.org/t/whats-julias-memory-model-like-e-g-regarding-aliasing/12565/1 "2018-07-21T16:56:28Z")

</div>

For the longest time, C++ didn’t have a memory model (now it does, and e.g. CPUs x86 and ARM implement it).

I know also that Java has a memory model, but never heard of other languages having defined.

Can you assume Julia’s is same as C++'s?

Or with the possible change of having Fortran’s aliasing rules (not sure if that’s part of what you would include in a “memory model”, as opposed to a “programmer model”?).

Looking up “aliasing” in the manual I get 103 “matches”, but it’s e.g. not in one (none?) of them:

[https://docs.julialang.org/en/stable/manual/noteworthy-differences/#Noteworthy-differences-from-C/C-1](https://docs.julialang.org/en/stable/manual/noteworthy-differences/#Noteworthy-differences-from-C/C-1)

[https://docs.julialang.org/en/stable/manual/noteworthy-differences/](https://docs.julialang.org/en/stable/manual/noteworthy-differences/)

In C/C++ “no aliasing” can’t be assumed, why C (not C++ portably) has restrict keyword. In Fortran, no aliasing is assumed (i.e. as you would use restrict always, is my understanding).

This make Fortran faster by default, generated code of, as the compiler has to do less work. An opposing view is that it means the programmer has to do more work, make sure there actually is no aliasing (overlapping memory regions). It’s not clear to me that it’s hard there or in Julia (or MATLAB).

Can I assume Julia is more, or exactly, like Fortran as in other respects (e.g. row vs. column major).

I see this long/old thread with (starting with):

> <https://github.com/JuliaLang/julia/issues/8087>
>
> This is a long-term issue that has arisen out of my recent discussion with James…on Nash on the julia users group: I would like to suggest that the core Julia developers come up with a strategy or roadmap for dealing with aliasing.
> 
> In more detail, consider a code for matrix multiplication C=A\*B with the calling format matmul(A,B,C) that is implemented in the old-fashioned form of three nested loops. It is well known by now that performance boosts of huge factors-- 10 or more -- are possible by reordering the loops, blocking them, etc. Indeed, this was the whole impetus behind the LAPACK project of the 1990s. Furthermore, many papers in the compiler community explain how a compiler can automatically transform three nested loops into high-performance code.
> 
> However, if the compiler does not know that the user will never invoke the routine as matmul(A,B,A), then it cannot carry out most of these transformations because most of them would change the answer in the (unexpected) case that C and A are identical.
> 
> Currently, the Julia manual says nothing at all about aliasing among function arguments.
> 
> For this and probably other examples, it could be useful for the compiler to know that the arguments to a function will not be aliased. What is Julia's strategy in this regard? I can think of a few possibilities. As I am not a compiler person myself, I don't have a strong preference for which possibility should be followed, but I think there should be a strategy.
> 1. Forbid aliasing between arguments (at least, in the case that one of the arguments is going to be mutated), and put the burden on the programmer not to violate the rule.
> 2. Have the compiler carry out global analysis of callers and functions and identify no-alias instances from its global analysis. In this scenario, there could be multiple instantiations of the same method, so Julia's mechanism of carrying function pointers around would become more complicated, and functions like code\_llvm would need a third argument to indicate what assumption is made about aliasing of arguments.
> 3. Do nothing, and omit compiler optimizations in Julia that require a no-aliasing assumption. It is up to the programmer to write the Julia code with the correct blocking necessary for high-performance code in matmul and similar examples.

“Currently, the Julia manual says nothing at all about aliasing among function arguments.”