5 ms·

Julia is a high-level, high-performance dynamic programming language

92 points by bsiemon 15y ago

freehunter 15y ago
Previous discussion: http://news.ycombinator.com/item?id=3606380 http://news.ycombinator.com/item?id=3606380 Their site is down right now, so the 10 day old comments might be able to satisfy some amount of curiosity.
- dr_rezzy 15y ago
  Ditto, this site returns an error everytime I try and hit it.
  - Marwy 15y ago
    Works fine for me.
- StefanKarpinski 15y ago
  This is weird because we're using GitHub for hosting.
Flam 15y ago
Is V8 really faster than NumPy and R? Interesting..
- joelthelion 15y ago
  Wait for numpy to be ported on PyPy :)
  - bitcracker 15y ago
    Thoughts on porting NumPy to PyPy: http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-numpy-to-pypy.html http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-p...
- ulvund 15y ago
  If you have worked a lot with R you won't be surprised that anything is faster than R
- nichol4s 15y ago
  No, not really. Not only do some of the example's seem to be created specially to show the benefit of the JIT compiler (see pisum fe). Most of the example's do not really use the features of LaPack/BLAS, the one where it does (a matrix multiplication in rand_mat_mult) shows that all languages which use these optimized libraries beat Javascript and handwritten C++ with a magnitude of 2. Thus, be careful with making such a generalisation from this benchmark. Also, it is much simpler to simply work with a language with proper support for multi-dimensional matrix slicing than having to do this all by hand.
  - ViralBShah 15y ago
    That is exactly the point of julia. It provides you access to BLAS/LAPACK when you need it, and it still gives you something fast when vectorization is not natural. It basically does not require vectorization as a prerequisite for performance. Julia wouldn't be the first language to attempt this - Matlab does this reasonably well, but R, Octave, Scilab, etc. do not. Julia does have multi-dimensional arrays and slicing also. If you had to do all this by hand, it would just be simpler to use C. http://julialang.org/manual/arrays/ http://julialang.org/manual/arrays/
  - StefanKarpinski 15y ago
    As you note, the last benchmark does precisely what you suggest, comparing completely vectorized code that just calls BLAS. This is a really uninteresting benchmark, however, since everyone is close to C++ (although NumPy, Octave and R still introduce 20%, 69% and 165% overhead, respectively) — because you're really just comparing C++ against C++. One of the key concepts behind Julia is that not only the end-user, but also the numerical library writer, should benefit from using a high-level language. In Julia, almost all of the library code is in Julia, and it's as fast as the library code written for R, Matlab or NumPy in C. There are also a lot of situations where vectorized code is either awkward or inefficient — especially in terms of creating a lot of unnecessary temporary arrays. Languages where the high-level language is slow force you to do everything vectorized — in Julia, you're not forced to do that. If you want to write a C-style scalar loop, you can and it will be fast (and you don't even need type annotations to make it fast, as shown by the benchmarks). V8 is really impressively fast, but JavaScript as a language is not very well suited to scientific or technical computing.
- mbq 15y ago
  R bench is glaringly unfair -- it consists of dumb ports of scalar algorithms while R is an array language.
bleakgadfly 15y ago
Again?
anamax 15y ago
Julia is the subject of today's http://www.stanford.edu/class/ee380/ http://www.stanford.edu/class/ee380/ The webcast is delayed and there's always something interesting that happens after the camera goes off.
ableal 15y ago
ViralBShah: your account was shadow-banned in the last discussion 10 days ago. (No reason I can see to ban one of the authors. Check logged out or from another account with "showdead" on.)
SeanLuke 15y ago
Is there some reason they neglect to compare against Mathematica? Seems like a glaring omission to me.
- StefanKarpinski 15y ago
  Running Mathematica scripts automatically from the command-line is major pain. That and just writing the benchmark code. A contribution would be most welcomed.
  - SeanLuke 15y ago
    Mathematica has always had a command line. MathKernel -script "foo.m" -noprompt As to Mathematica being a pain to write code for: I've found it to be a pretty nice language, certainly a far cry better designed than MATLAB.
jhrobert 15y ago
"All indexing in Julia is 1-based" I once designed/implemented a language where the biggest mistake I made was using 1-based indexing. At first it looked like it was going to be easier to understand/use but 0-based indexing is actually much more convenient when dealing with indexes arithmetic. PS: the "metaprogramming" stuff is fabulous.

92 points by bsiemon 15y ago

Previous discussion: http://news.ycombinator.com/item?id=3606380 http://news.ycombinator.com/item?id=3606380 Their site is down right now, so the 10 day old comments might be able to satisfy some amount of curiosity.

dr_rezzy 15y ago
Ditto, this site returns an error everytime I try and hit it.
- Marwy 15y ago
  Works fine for me.
StefanKarpinski 15y ago
This is weird because we're using GitHub for hosting.

Flam 15y ago

Is V8 really faster than NumPy and R? Interesting..

joelthelion 15y ago
Wait for numpy to be ported on PyPy :)
- bitcracker 15y ago
  Thoughts on porting NumPy to PyPy: http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-porting-numpy-to-pypy.html http://technicaldiscovery.blogspot.com/2011/10/thoughts-on-p...
ulvund 15y ago
If you have worked a lot with R you won't be surprised that anything is faster than R
nichol4s 15y ago
No, not really. Not only do some of the example's seem to be created specially to show the benefit of the JIT compiler (see pisum fe). Most of the example's do not really use the features of LaPack/BLAS, the one where it does (a matrix multiplication in rand_mat_mult) shows that all languages which use these optimized libraries beat Javascript and handwritten C++ with a magnitude of 2. Thus, be careful with making such a generalisation from this benchmark. Also, it is much simpler to simply work with a language with proper support for multi-dimensional matrix slicing than having to do this all by hand.
- ViralBShah 15y ago
  That is exactly the point of julia. It provides you access to BLAS/LAPACK when you need it, and it still gives you something fast when vectorization is not natural. It basically does not require vectorization as a prerequisite for performance. Julia wouldn't be the first language to attempt this - Matlab does this reasonably well, but R, Octave, Scilab, etc. do not. Julia does have multi-dimensional arrays and slicing also. If you had to do all this by hand, it would just be simpler to use C. http://julialang.org/manual/arrays/ http://julialang.org/manual/arrays/
- StefanKarpinski 15y ago
  As you note, the last benchmark does precisely what you suggest, comparing completely vectorized code that just calls BLAS. This is a really uninteresting benchmark, however, since everyone is close to C++ (although NumPy, Octave and R still introduce 20%, 69% and 165% overhead, respectively) — because you're really just comparing C++ against C++. One of the key concepts behind Julia is that not only the end-user, but also the numerical library writer, should benefit from using a high-level language. In Julia, almost all of the library code is in Julia, and it's as fast as the library code written for R, Matlab or NumPy in C. There are also a lot of situations where vectorized code is either awkward or inefficient — especially in terms of creating a lot of unnecessary temporary arrays. Languages where the high-level language is slow force you to do everything vectorized — in Julia, you're not forced to do that. If you want to write a C-style scalar loop, you can and it will be fast (and you don't even need type annotations to make it fast, as shown by the benchmarks). V8 is really impressively fast, but JavaScript as a language is not very well suited to scientific or technical computing.
mbq 15y ago
R bench is glaringly unfair -- it consists of dumb ports of scalar algorithms while R is an array language.

bleakgadfly 15y ago

Again?

anamax 15y ago

Julia is the subject of today's http://www.stanford.edu/class/ee380/ http://www.stanford.edu/class/ee380/ The webcast is delayed and there's always something interesting that happens after the camera goes off.

ableal 15y ago

ViralBShah: your account was shadow-banned in the last discussion 10 days ago. (No reason I can see to ban one of the authors. Check logged out or from another account with "showdead" on.)

SeanLuke 15y ago

Is there some reason they neglect to compare against Mathematica? Seems like a glaring omission to me.

StefanKarpinski 15y ago
Running Mathematica scripts automatically from the command-line is major pain. That and just writing the benchmark code. A contribution would be most welcomed.
- SeanLuke 15y ago
  Mathematica has always had a command line. MathKernel -script "foo.m" -noprompt As to Mathematica being a pain to write code for: I've found it to be a pretty nice language, certainly a far cry better designed than MATLAB.

jhrobert 15y ago

"All indexing in Julia is 1-based" I once designed/implemented a language where the biggest mistake I made was using 1-based indexing. At first it looked like it was going to be easier to understand/use but 0-based indexing is actually much more convenient when dealing with indexes arithmetic. PS: the "metaprogramming" stuff is fabulous.