3 ms·

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 verb

by aborsy 6y ago

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.

krastanov 6y ago
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
- spacedome 6y ago
  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.
  - DNF2 6y ago
    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.
    - spacedome 6y ago
      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.
      - DNF2 6y ago
        Have you looked thoroughly over https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/ 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).
        cbkeller 6y ago
        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/#LinearAlgebra.LAPACK https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#Linea...
        spacedome 6y ago
        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.
        DNF2 6y ago
        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?
smabie 6y ago
Numpy isn't actually very fast, especially if the data is small.

by aborsy 6y ago

krastanov 6y ago

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

spacedome 6y ago
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.
- DNF2 6y ago
  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.
  - spacedome 6y ago
    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.
    - DNF2 6y ago
      Have you looked thoroughly over https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/ 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).
      - cbkeller 6y ago
        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/#LinearAlgebra.LAPACK https://docs.julialang.org/en/v1/stdlib/LinearAlgebra/#Linea...
      - spacedome 6y ago
        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.
        DNF2 6y ago
        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?

smabie 6y ago

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