Hacker News Reader

Comment by aborsy | Hacker News Reader

Julia is better suited to numerical computation. Matlab is expensive and not really a language. Python is not designed for numerical computation and can be verbose.

The issue for Julia is, if you stay in Numpy and Scipy in Python, and can use JIT when applicable, you are basically using C. You can make it fast using C libraries and there is not whole lot of room for Julia to shine. Even with C, I had to be lately a bit careful to beat Numpy.

View on HN

I have quite the opposite experience. Numpy is terrible in terms of allocation overhead (even when you use the available, but limited, inplace operators and memory views). In Julia it is 𝚝̶𝚛̶𝚒̶𝚟̶𝚒̶𝚊̶𝚕̶ much easier to write allocation free code. And only so many operations are trivially broadcastable, after which numpy becomes very cumbersome and slow.

Numpy is a great piece of engineering, but its limitations are very noticeable when compared to Julia.

edit: not trivial, but much easier

As much as I like Julia, I think "trivial to write allocation free code" is a bit of an overstatement. Depending on what you are doing, it can be difficult, for example iteratively calling any of the LinearAlgebra methods, since there is no interface for preallocating work arrays (doing the ccall on BLAS yourself is not a fun work-around). It is also not always clear why something is allocating, even with the debugging tools.

Perhaps I misunderstand what a 'work array' is, but you can easily pre-allocate arrays, and then work on them in-place, including with LinearAlgebra functions like `mul!` et. al.

Higher level BLAS operations, such as solving a linear system, or computing svd/eigen, cannot be done in-place the way matrix multiplication can, and require additional memory of a predetermined, fixed size, called the work array. This cannot be pre-allocated in Julia, as there is no interface to do so in LinearAlgebra, so these BLAS calls will always allocate memory.

Have you looked thoroughly over https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/ ?

There's a ton of in-place operations there, including in-place solving of linear systems, and at least some stuff related to svd (though the names are pretty un-intuitive, being wrappers for BLAS and LAPACK functions).

Hah, you were not kidding about the names being unintuitive.

For anyone else interested there is a large list starting here [1]. The in-place versions will all end with `!`.

[1] https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#Linea...

Yes, many of these are "in-place" but will still allocate. I typically use the geev!/ggev!/geevx! routines, if you look at the source code you will see that the work arrays are still allocated inside the call. The in-place here (unfortunately) means only that the input is overwritten, not that there is no allocation.

The purpose of in-place operations is to avoid allocations, so this seems like an oversight.

Is this a matter of simply wrapping the 'right' LAPACK routines, or is there something missing in the interfaces that could be trivially added in principle?

It is entirely possible, but is not trivial, especially for the user who then needs to know "arcane knowledge" of BLAS/LAPACK work array sizes and flags. There was some discussion about this on github, but it sort of trailed off without a real resolution. I think it is considered too complicated/niche to be in base, and was recommended to be an external library, but nobody (myself included) seems particularly interested in what amounts to maintaining a fork of the entire BLAS package. The base devs would have more insight, but this is my view from the outside at least.

Numpy isn't actually very fast, especially if the data is small.

Reply on news.ycombinator.com