I see the suggestion “use
@views” often, to fix a performance problem; possibly for people coming from Python (is it also the default in MATLAB?).
I know the difference, and support having a (at least a conceptional) copy by default, since it seems safer, no overwriting the original array by accident (also was done for historical reasons, to keep compatibility). But you need to explain this difference. So still could views be automatic?
I’ll start with a simplified/non-multithreaded picture:
If you do not use
@view (e.g. in a loop), then you make a copy, O(n), which is of course slow, but on top of that, you make an allocation for that copy and rely on the GC to clean up.
What seems could happen, since you allocated in a loop (assuming you didn’t call others giving out a pointer to the copy, or return the array from your function), the compiler could do a Libc.free on it at the end of the loop-iteration, since there’s only one owner of the copy. That would at least reduce the GC pressure. This would also work in the multi-threaded picture.
But I’m thinking why do the copy at all? If you return a read-only array view, then things will be as fast as in Python? But we broke compatibility since you were promised a copy you could write to. But that’s very often not done anyway, so this seems cool. You could copy-on-write to an actual copy, on demand, if you would want to support both ways, but I’m thinking, should the compiler notice there’s no write to the array, and only do this read-only view if you never try to write to it? Otherwise just do status quo.
Now for the multi-threaded view.
When you take a
@view to an array, you are taking a risk, threads could be changing the array you are basing on while you use the view, i.e. a race condition. A copy seems safer, but it actually seems to have the same problem, just that then you are only exposed to the problem while it’s being copied (i.e. while done for you).
So having an implicit
@view is slightly less safe, I’m not sure if that should be considered a breaking change, since it’s a matter of degree, not that you were adding risk and had none before. This might though be likely to break code, and not be tested enough, since multi-threading is not yet the default… and it would always be a potential problem thereafter or if people enable.
So I’m thinking should not just only views, but arrays too, be read-only from the start? I think this has been suggested already. Here, right now, I’m focusing on what the compiler should do (with no help; or possibly with such a flag for each array). Could it see such a read-only flag that users would not ever have to worry about?