On Mon, Sep 29, 2014 at 6:25 PM, Art Kuo <[email protected]> wrote:
> I am interpreting this to mean that LLVM can't optimize as well if it > doesn't know the size of the array. I would be tempted to say that arrays > should ideally be kept fast when people aren't resizing, but nevertheless > allow resizing with perhaps a sizable performance penalty when it is used. > That sounds lovely, but that's not the tradeoff – it is the *possibility* of resizing, not the act, which prevents optimizations. If it is possible for an array to be resized whenever execution leaves the current scope, then you have to emit code to do bounds checks every time you return from another scope. For example, if arrays can be resized, then you can't hoist bounds out of loops that include function calls that aren't inlined. This isn't really a limitation in LLVM (or Julia), it's a limitation in reality. > As slow as Matlab is, my bottleneck is usually myself and my algorithms, > not juggling memory. In the long run, I would hope that a lint could let > users know of the downsides of the less performant bits. People who work > with huge data should indeed be able to work quickly and would probably > happily avoid deleteat and others like it. > Again, it's not about whether you do or don't resize arrays in your code – it's about whether arrays are resizeable or not in general. Most dynamic languages are in a rather different problem space than Julia here: bounds checks are the least of their performance concerns, many more things are monolithic built-ins, and the system knows if they do or don't modify the sizes of their arguments. As another illustration of a use case, consider the following Mathematica > snippet <http://mathworld.wolfram.com/Minor.html> from Mathworld to > evaluate the minor of a matrix : > > Minor[m_List?MatrixQ, {i_Integer, j_Integer}] := > Det[Drop[Transpose[Drop[Transpose[m], {j}]], {i}]] > > where this is actually the older version of Drop before they made it > column-friendly (hence Drop[Transpose[]]), Mathematica being > row/list-oriented. I can't remember the timeline, but it took a good decade > or so for them to Drop or even reference columns easily. These were hugely > requested features for years, and Minor shows how nice it is to have some > syntactic sugar. Using modern Drop, the code above would be even simpler. > Yes, there certainly are use cases for doing this. The question is if they are worth slowing down arrays in general. So far we've decided that the trade off isn't worth it.
