4 ms·

How can implicit sharing have "disasterous effects on memory usage"? It will certainly break some code, hence the large amount of warning and the "pocalypse" ap

How can implicit sharing have "disasterous effects on memory usage"? It will certainly break some code, hence the large amount of warning and the "pocalypse" appellation. Note that this is how array slices work in NumPy and that ecosystem has not collapsed.

masklinn 11y ago
> How can implicit sharing have "disasterous effects on memory usage"? A small long-lived slices keeping a original arrays alive implicitly. Oracle recently undid the same optimisation in Java's strings because of that exact issue (which obviously broke code the other way around, code relying on cheap substrings would now take O(n) instead of O(1)). Erlang developers are also warned early and often about that behaviour in binaries.
- btown 11y ago
  Very true. Less of a problem in scientific computing than web services, I think, since it's not common to keep slices around: you generally process a "frame" or an iteration of a simulation (Monte Carlo, etc.) and perhaps compare it to a previous frame, but the only history you keep beyond that are aggregates of the data, rather than individual slices that might go (say) in a global dictionary and stay around for a while. I don't think I've ever seen NumPy code where array slices were used as values in a long-living in-memory key-value store or cache... whereas you see that all the time with substrings in code for webservices. Thus it hasn't been as big a problem as in the Java community. Still something that should be in bold text in Julia 0.5's readmes, though; slicing is cheap now, but it comes with this very important caveat!
- johnmyleswhite 11y ago
  The primary use case for Julia's coming array slices is to provide views into an array that you always intended to keep alive anyway. Iterating over the columns of an in-memory matrix, for example, is the use case that this change is meant to speed up.
  - masklinn 11y ago
    And so it was with Java's substring and is for Erlang's binaries sharing. I will acknowledge that array slices are less likely to cause problems than string slices, but it is still a possible issue for the unwary. Which was my point.
- StefanKarpinski 11y ago
  Totally different typical usage patterns. Taking substrings and throwing away the original string is the norm for text. Taking a column of a matrix and throwing away the original matrix is not. Different domains call for different design tradeoffs – this change stems from extensive practical experience with writing numerical algorithms.
  - lqdc13 11y ago
    would there still be an easy way to make copies? Like advanced indexing (http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#advanced-indexing http://docs.scipy.org/doc/numpy/reference/arrays.indexing.ht...) in the Python world?
    - elcritch 11y ago
      You could just use a list comprehension, e.g. `[ x for x in arrayveiw1 ]` or perhaps a copy function will be added to Base.
      - StefanKarpinski 11y ago
        There's already a copy function that does this.
        elcritch 11y ago
        Great, Julia seems to have a good assortment of those "I need XYZ" (for scientific programming) and it's already in Base. I should check the apropos more.
  - masklinn 11y ago
    Note that I am not saying it's a bad default (it still is the default of Erlang binaries). I am saying this change is not quite "just a matter of performance", that the documentation and changelogs should be very very clear about the behavioural changes and the possible issues with the new behaviour, and that there should be an easy way to "unshare" slices and force a copy.

masklinn 11y ago

> How can implicit sharing have "disasterous effects on memory usage"? A small long-lived slices keeping a original arrays alive implicitly. Oracle recently undid the same optimisation in Java's strings because of that exact issue (which obviously broke code the other way around, code relying on cheap substrings would now take O(n) instead of O(1)). Erlang developers are also warned early and often about that behaviour in binaries.

btown 11y ago
Very true. Less of a problem in scientific computing than web services, I think, since it's not common to keep slices around: you generally process a "frame" or an iteration of a simulation (Monte Carlo, etc.) and perhaps compare it to a previous frame, but the only history you keep beyond that are aggregates of the data, rather than individual slices that might go (say) in a global dictionary and stay around for a while. I don't think I've ever seen NumPy code where array slices were used as values in a long-living in-memory key-value store or cache... whereas you see that all the time with substrings in code for webservices. Thus it hasn't been as big a problem as in the Java community. Still something that should be in bold text in Julia 0.5's readmes, though; slicing is cheap now, but it comes with this very important caveat!
johnmyleswhite 11y ago
The primary use case for Julia's coming array slices is to provide views into an array that you always intended to keep alive anyway. Iterating over the columns of an in-memory matrix, for example, is the use case that this change is meant to speed up.
- masklinn 11y ago
  And so it was with Java's substring and is for Erlang's binaries sharing. I will acknowledge that array slices are less likely to cause problems than string slices, but it is still a possible issue for the unwary. Which was my point.
StefanKarpinski 11y ago
Totally different typical usage patterns. Taking substrings and throwing away the original string is the norm for text. Taking a column of a matrix and throwing away the original matrix is not. Different domains call for different design tradeoffs – this change stems from extensive practical experience with writing numerical algorithms.
- lqdc13 11y ago
  would there still be an easy way to make copies? Like advanced indexing (http://docs.scipy.org/doc/numpy/reference/arrays.indexing.html#advanced-indexing http://docs.scipy.org/doc/numpy/reference/arrays.indexing.ht...) in the Python world?
  - elcritch 11y ago
    You could just use a list comprehension, e.g. `[ x for x in arrayveiw1 ]` or perhaps a copy function will be added to Base.
    - StefanKarpinski 11y ago
      There's already a copy function that does this.
      - elcritch 11y ago
        Great, Julia seems to have a good assortment of those "I need XYZ" (for scientific programming) and it's already in Base. I should check the apropos more.
- masklinn 11y ago
  Note that I am not saying it's a bad default (it still is the default of Erlang binaries). I am saying this change is not quite "just a matter of performance", that the documentation and changelogs should be very very clear about the behavioural changes and the possible issues with the new behaviour, and that there should be an easy way to "unshare" slices and force a copy.