5 ms·

TL;DR - Julia nice for prototyping - but zero speed up from using GPU - sometimes faster sometimes slower on CPU - no plans to use at the moment

oivey 3y ago
This is a little reductive. The speed comparison was between the highly parallel and optimized CPU version vs GPU. The GPU’s advertised FLOPS was only 4x the CPU setup’s. That the performance is so similar isn’t all that surprising and could come down to low level optimization details. There are likely some areas in Julia’s GPU stack that could be made better, but it’s certainly already pretty performant. It’s also comparing against Fortran. Their Python comparison is 100x+ slower. That a high level language even comes close is impressive.
- jppittma 3y ago
  If only they didn’t chose 1 based array indexing, like matlab. Having worked with matlab and for that reason I can’t seem to take them seriously.
  - baggepinnen 3y ago
    But you can take Fortran seriously?
  - pjmlp 3y ago
    Plenty of serious languages have either 1 based indexing, or allow the flexibility to set lower boundary explicitly.
  - marmalade2413 3y ago
    The choice of 1 based array indexing is due to Julia having it's roots in mathematics - which is a common choice for mathematics based programming languages (e.g. Fortran, Julia, MATLAB/GNU Octave, Mathematica, R and Wolfram). The reason being is that matrix notation starts at 1 and not 0. For a comparison on array indexing in different programming languages see here: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Array_dimensions https://en.wikipedia.org/wiki/Comparison_of_programming_lang... From personal experience, I wouldn't let something as simple as starting index getting in the way of programming for a language as you'll soon start automatically switching to thinking in 1 based and 0 based indexing depending on the programming language.
  - amj7e 3y ago
    If you think 0 or 1 based indexing will hinder your ability to write a program, it's not the indexing, it's a skill issue.
- pjmlp 3y ago
  Why should it be impressive? Compiled high level languages have always been pretty fast in general, for decades, before 20 years ago it started to be trendy to use interpreted scripting languages to do their work. Anyone used to Modula-2, Object Pascal, QuickBasic, Clipper, AMOS, Lisp, Scheme, Dylan, Smalltalk, SELF, Oberon, VB, Delphi, C++, SML, Miranda, Haskell, Prolog from 1980-1990's, isn't going to be surprised about speedups over Python.
  - oivey 3y ago
    100x relative to NumPy is still quite a lot, depending on how much of their code manages to stay in the C extension. If it was pure Python the delta would likely be much, much larger. Julia is definitely built on the shoulders of giants. I don’t have experience with most of those languages, especially in high performance Lisp or Haskell. Calling C++ high level is definitely not in the same vein as Python or Julia. My understanding is that Haskell can run into all sorts of performance gotchas because lazy evaluation can be unpredictable and recursion may not always easily unroll into optimizable loops. I think the combination of features, especially borrowed from Lisp and C++, really come together as something very productive for writing fast, very high level code.
    - pjmlp 3y ago
      C++ is definitely high level, in the same vein as Python and Julia, the only thing missing is reflection (if we ignore C++/CLI, C++ Builder and custom libraries), which with some luck might still make the cut to C++26. Just because some people insist in using it like C, doesn't make it less higher level in available features and tooling. Regardless of how easy it is to optimize Haskell code, even stupid Haskell code beats an interpreted language like Python. And C bindings are not Python, regardless of how the Python community likes to think otherwise. If anything, I look forward to Julia and others to put pressure in the community to take PyPy and other JIT attempts more seriously. Or maybe it doesn't matter and in a couple of years everyone has moved into mojo, if it is successful.
      - oivey 3y ago

oivey 3y ago

This is a little reductive. The speed comparison was between the highly parallel and optimized CPU version vs GPU. The GPU’s advertised FLOPS was only 4x the CPU setup’s. That the performance is so similar isn’t all that surprising and could come down to low level optimization details. There are likely some areas in Julia’s GPU stack that could be made better, but it’s certainly already pretty performant. It’s also comparing against Fortran. Their Python comparison is 100x+ slower. That a high level language even comes close is impressive.

jppittma 3y ago
If only they didn’t chose 1 based array indexing, like matlab. Having worked with matlab and for that reason I can’t seem to take them seriously.
- baggepinnen 3y ago
  But you can take Fortran seriously?
- pjmlp 3y ago
  Plenty of serious languages have either 1 based indexing, or allow the flexibility to set lower boundary explicitly.
- marmalade2413 3y ago
  The choice of 1 based array indexing is due to Julia having it's roots in mathematics - which is a common choice for mathematics based programming languages (e.g. Fortran, Julia, MATLAB/GNU Octave, Mathematica, R and Wolfram). The reason being is that matrix notation starts at 1 and not 0. For a comparison on array indexing in different programming languages see here: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Array_dimensions https://en.wikipedia.org/wiki/Comparison_of_programming_lang... From personal experience, I wouldn't let something as simple as starting index getting in the way of programming for a language as you'll soon start automatically switching to thinking in 1 based and 0 based indexing depending on the programming language.
- amj7e 3y ago
  If you think 0 or 1 based indexing will hinder your ability to write a program, it's not the indexing, it's a skill issue.
pjmlp 3y ago
Why should it be impressive? Compiled high level languages have always been pretty fast in general, for decades, before 20 years ago it started to be trendy to use interpreted scripting languages to do their work. Anyone used to Modula-2, Object Pascal, QuickBasic, Clipper, AMOS, Lisp, Scheme, Dylan, Smalltalk, SELF, Oberon, VB, Delphi, C++, SML, Miranda, Haskell, Prolog from 1980-1990's, isn't going to be surprised about speedups over Python.
- oivey 3y ago
  100x relative to NumPy is still quite a lot, depending on how much of their code manages to stay in the C extension. If it was pure Python the delta would likely be much, much larger. Julia is definitely built on the shoulders of giants. I don’t have experience with most of those languages, especially in high performance Lisp or Haskell. Calling C++ high level is definitely not in the same vein as Python or Julia. My understanding is that Haskell can run into all sorts of performance gotchas because lazy evaluation can be unpredictable and recursion may not always easily unroll into optimizable loops. I think the combination of features, especially borrowed from Lisp and C++, really come together as something very productive for writing fast, very high level code.
  - pjmlp 3y ago
    C++ is definitely high level, in the same vein as Python and Julia, the only thing missing is reflection (if we ignore C++/CLI, C++ Builder and custom libraries), which with some luck might still make the cut to C++26. Just because some people insist in using it like C, doesn't make it less higher level in available features and tooling. Regardless of how easy it is to optimize Haskell code, even stupid Haskell code beats an interpreted language like Python. And C bindings are not Python, regardless of how the Python community likes to think otherwise. If anything, I look forward to Julia and others to put pressure in the community to take PyPy and other JIT attempts more seriously. Or maybe it doesn't matter and in a couple of years everyone has moved into mojo, if it is successful.
    - oivey 3y ago