5 ms·

> It's very hard to recommend that students and colleagues grow invested in toolchains involving proprietary software that they may not reliably be able to affo

by wjn0 8y ago

> It's very hard to recommend that students and colleagues grow invested in toolchains involving proprietary software that they may not reliably be able to afford/activate/use in the future, particularly when some students may end up working in developing nations. The future is here. As a research student in a developed nation, it's very annoying to deal with MATLAB projects. Our lab has a fairly strict no-new-code-written-in-MATLAB policy. Getting a personal licence is fairly straightforward as a student (for now), but running it on a cluster, or anything beyond my personal computer is very annoying.

wanderfowl 8y ago
I love that idea, and it seems like a reasonable way to slowly move a toolchain, provided that there are clean breaks to shift from MATLAB to the next step. And cluster computing in MATLAB, I agree, is just that: a cluster.
marmaduke 8y ago
I know it’s not cheap but we have exactly one copy of MATLAB on our cluster to use their compiler and then run the compiled code on nodes without licenses.
IshKebab 8y ago
What do you use instead though? Octave is very slow, Julia is even slower and Numpy has an annoyingly verbose syntax because it has to be valid Python. Additionally I've not found a plotting solution that is as robust and fast as MATLAB. MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.
- cbkeller 8y ago
  > Julia is even slower Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..
  - 4thaccount 8y ago
    Well written Julia should definitely be faster in most cases unless Matlab is using a specific well performing algorithm that Julia doesn't have built-in. With that being said, there are a lot of Julia posts on the subreddit or stack overflow that go like "Why is this Julia code 10x slower than my Python code"? One issue is that getting good performance out of Julia isn't always obvious without a pretty good understanding of how it works. Thankfully, people are willing to help you tweak your code to make it much faster.
    - Q6T46nT668w6i3m 8y ago
      They should be similar if they both rely on standard LLVM optimizations. I assume both have their own optimization passes on some mid-level IR but I personally don’t know whether one or the other has any particular language features that dramatically improve performance over the other. I’d like to hear more!
      - 4thaccount 8y ago
        I was just saying that getting really good performance out of LLVM with Julia isn't always obvious. This isn't just a Julia thing. People starting with Python + Numpy have issues with speed when they don't take advantage of the vector primitives and drop into regular Python loops for part of the code. First time Haskell users are frequently confused when it is significantly slower to parse text than Perl as one of the default string libraries is really slow and not recommended even though it is what a new user would think should be the first choice. Overall I'm excited for Julia, but have a lot to learn. As far as Octave/Scilab type applications go, I find them useful for small systems where I need to make sure the math of what I'm doing is correct before writing it in something like Julia or Python + Numpy. Excel is also surprisingly good for the really simple stuff (Ex: inverting a small matrix and doing some matrix multiplications).
      - cbkeller 8y ago
        I assume they're referring to cases like this [1]. A few years ago I think there were some performance regressions in Julia relative to JIT'd Python (which, using LLVM like Julia, is way faster than normal Python). This seems to be mostly fixed now. In the example above, the OP was getting 2ms in Numba vs 8ms in Julia three years ago, and recommendations from Julia folks were able to get the latter down to parity with an equivalent algorithm or 386us with an improved algorithm. On my laptop today, I seem to get 2.0ms in Numba, 2.7ms with Julia 1.0, and 80us using the improved algorithm in Julia 1.0 (and, just to drive home the importance of compilation, 780ms in Python without Numba). [1] https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_loop_in_julia_slower_than_the_python/ https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_l...
- wjn0 8y ago
  R is nice for stats stuff, even if performance can be iffy for certain tasks. The existing libraries for basic ML tasks are largely fantastic. The syntax rubs many people (including me) the wrong way. But I don't like the paradigm for basic ML tasks in scikit-learn (python) much better. Anything involving matrix computation is great to do in python because of existing libraries (numpy). I think most people who are actually writing code (i.e. grad students) don't mind the syntax because they learned it in school starting in undergrad. Octave's main appeal to me (and most people I work with) is being able to run existing MATLAB code. However, making it work for nontrivial MATLAB projects, is, well, nontrivial. It's also very slow. Julia is the language I'm most excited about. It's fast [1] even though it has a slow startup time, and that's improving quickly. It's got a nice grammar-of-graphics-based plotting library [2] that's quickly catching up to R's ggplot2. I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I like the syntax a lot, too. The data types take some getting used to, not unlike R. I also think if Julia moves away from JIT compilation, it has potential to be the language of choice for deployed NN models (right now, that's C++). As for plotting, R's ggplot2 beats MATLAB any day of the week for me. To each his own. [1] https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ [2] https://github.com/GiovineItalia/Gadfly.jl https://github.com/GiovineItalia/Gadfly.jl
  - byt143 8y ago
    > I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I think it will overtake python for NNet stuff also: https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler

by wjn0 8y ago

wanderfowl 8y ago

I love that idea, and it seems like a reasonable way to slowly move a toolchain, provided that there are clean breaks to shift from MATLAB to the next step. And cluster computing in MATLAB, I agree, is just that: a cluster.

marmaduke 8y ago

I know it’s not cheap but we have exactly one copy of MATLAB on our cluster to use their compiler and then run the compiled code on nodes without licenses.

IshKebab 8y ago

What do you use instead though? Octave is very slow, Julia is even slower and Numpy has an annoyingly verbose syntax because it has to be valid Python. Additionally I've not found a plotting solution that is as robust and fast as MATLAB. MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.

cbkeller 8y ago
> Julia is even slower Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..
- 4thaccount 8y ago
  Well written Julia should definitely be faster in most cases unless Matlab is using a specific well performing algorithm that Julia doesn't have built-in. With that being said, there are a lot of Julia posts on the subreddit or stack overflow that go like "Why is this Julia code 10x slower than my Python code"? One issue is that getting good performance out of Julia isn't always obvious without a pretty good understanding of how it works. Thankfully, people are willing to help you tweak your code to make it much faster.
  - Q6T46nT668w6i3m 8y ago
    They should be similar if they both rely on standard LLVM optimizations. I assume both have their own optimization passes on some mid-level IR but I personally don’t know whether one or the other has any particular language features that dramatically improve performance over the other. I’d like to hear more!
    - 4thaccount 8y ago
      I was just saying that getting really good performance out of LLVM with Julia isn't always obvious. This isn't just a Julia thing. People starting with Python + Numpy have issues with speed when they don't take advantage of the vector primitives and drop into regular Python loops for part of the code. First time Haskell users are frequently confused when it is significantly slower to parse text than Perl as one of the default string libraries is really slow and not recommended even though it is what a new user would think should be the first choice. Overall I'm excited for Julia, but have a lot to learn. As far as Octave/Scilab type applications go, I find them useful for small systems where I need to make sure the math of what I'm doing is correct before writing it in something like Julia or Python + Numpy. Excel is also surprisingly good for the really simple stuff (Ex: inverting a small matrix and doing some matrix multiplications).
    - cbkeller 8y ago
      I assume they're referring to cases like this [1]. A few years ago I think there were some performance regressions in Julia relative to JIT'd Python (which, using LLVM like Julia, is way faster than normal Python). This seems to be mostly fixed now. In the example above, the OP was getting 2ms in Numba vs 8ms in Julia three years ago, and recommendations from Julia folks were able to get the latter down to parity with an equivalent algorithm or 386us with an improved algorithm. On my laptop today, I seem to get 2.0ms in Numba, 2.7ms with Julia 1.0, and 80us using the improved algorithm in Julia 1.0 (and, just to drive home the importance of compilation, 780ms in Python without Numba). [1] https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_loop_in_julia_slower_than_the_python/ https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_l...
wjn0 8y ago
R is nice for stats stuff, even if performance can be iffy for certain tasks. The existing libraries for basic ML tasks are largely fantastic. The syntax rubs many people (including me) the wrong way. But I don't like the paradigm for basic ML tasks in scikit-learn (python) much better. Anything involving matrix computation is great to do in python because of existing libraries (numpy). I think most people who are actually writing code (i.e. grad students) don't mind the syntax because they learned it in school starting in undergrad. Octave's main appeal to me (and most people I work with) is being able to run existing MATLAB code. However, making it work for nontrivial MATLAB projects, is, well, nontrivial. It's also very slow. Julia is the language I'm most excited about. It's fast [1] even though it has a slow startup time, and that's improving quickly. It's got a nice grammar-of-graphics-based plotting library [2] that's quickly catching up to R's ggplot2. I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I like the syntax a lot, too. The data types take some getting used to, not unlike R. I also think if Julia moves away from JIT compilation, it has potential to be the language of choice for deployed NN models (right now, that's C++). As for plotting, R's ggplot2 beats MATLAB any day of the week for me. To each his own. [1] https://julialang.org/benchmarks/ https://julialang.org/benchmarks/ [2] https://github.com/GiovineItalia/Gadfly.jl https://github.com/GiovineItalia/Gadfly.jl
- byt143 8y ago
  > I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I think it will overtake python for NNet stuff also: https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler