12 ms·

Julia: A fresh approach to numerical computing

215 points by sveme 12y ago

StefanKarpinski 12y ago
Despite having a very similar title, this is a rather different paper from http://arxiv.org/abs/1209.5145 http://arxiv.org/abs/1209.5145. We had to upload a version of this paper for a grant application, but it's still somewhat in progress.
- ViralBShah 12y ago
  That's right. The purpose was to have twin papers - one for the Computer Science community focussed on language implementation, which is the earlier paper. This paper focusses on motivating the design of Julia for the larger scientific community. Any comments will be incredibly valuable in improving the quality of the paper.
  - trurl42 12y ago
    It's great to have a paper like this on the arXiv, I believe this is the right way to reach the scientific community. Some ideas for improvements: The package directory could be mentioned more prominently. It's a bit tricky to select code in the PDF, not sure if much can be done about this?
    - ViralBShah 12y ago
      I guess we can publish the IJulia notebooks with the examples and even just the code as plain .jl files.
monochr 12y ago
What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn't.
- sgt101 12y ago
  I would say Julia sucks for embedded programming :); building graphical clients - although not badly as there are various js libaries that it can chat to, games programming, it's not great at data base interaction although once you have the data in it it is fine (frames). The last point is a bit of a development area I would expect to see because Julia has a console and this means that interactive querying would be great - like SQL on steroids but currently without the sql unfortunatley. Julia shines at developing efficient reusable code for crunching numbers. The type system is really nice, and the syntax is very clean and natural (to me!)
  - ViralBShah 12y ago
    There is work happening on the UI side in Julia. While we are some ways away from building graphical clients in Julia, we do have GTK bindings and such. For some interesting ideas borrowed from Elm, do see: https://github.com/shashi/Patchwork.jl https://github.com/shashi/Patchwork.jl
    - infinite8s 12y ago
      Is anyone working on direct Qt bindings (I don't consider using PyCall a viable option). Qt is a bit harder to wrap since it is C++, but it look like Lua has been able to auto generate bindings based on the Qt headers.
      - StefanKarpinski 12y ago
        Keno Fischer, who recently created the Cxx package [1] used to be a Qt dev, so I wouldn't be terribly surprised if we see such bindings materialize in the future, using Cxx, of course. That said, I don't want to speak for him, so if someone wants this, they should maybe go ahead and start working on it! [1] https://github.com/Keno/Cxx.jl https://github.com/Keno/Cxx.jl
- amelius 12y ago
  What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.
deleted 12y ago
[deleted]
af3 12y ago
How it's better than Fortran?
wbhart 12y ago
I've been playing around with the Cxx library (currently only works with a source build of bleeding edge Julia) https://github.com/Keno/Cxx.jl https://github.com/Keno/Cxx.jl It allows you to basically embed ordinary C++ code in Julia code, to interface with C++ libraries at runtime, and to slurp in entire .h files unmodified. (It also in theory allows a C++ REPL mode to be written, though such a thing does not exist for Julia yet.) It makes very clever use of a really amazing new language feature in Julia 0.4, namely staged functions. At first it looked like it was manipulating C++ via strings sent to the Clang compiler at runtime, which sounded really slow and awful. But then it dawned on me how it really worked, and I was amazed. I've actually convinced three or four of my colleagues (mathematicians) to work on building a computer algebra system with Julia that will interface to various packages such as Pari/GP, flint, Singular, possibly Gap. We meet weekly to discuss design and to try and work on an initial implementation. The rate at which Julia is improving and the community is increasing is astonishing. We are at the stage where Julia is offering us language features we haven't even dreamed up a use for! And yet the language remains elegant and easy to learn.
- one-more-minute 12y ago
  For reference, a staged function is something sorta similar to a macro, except it lets you take advantage of Julia's inferred type info. Contrived (and wholly redundant) example: stagedfunction foo(x) if x == Int :(2x) else :x end end y = 1 foo(y) == 2 y = 1. foo(y) == 1.0 Again, just like a macro, except that before `x` is quoted you work with the type of y instead of the symbol `y`. This means you can do even more crazy code specialisation, including on e.g. matrix dimensions or generating appropriate FFI calls based on arbitrary input types. It has zero overhead and you can use it just like a regular function. Very cool, and I think people will do really interesting things with this (especially after mixing them with macros).
  - infinite8s 12y ago
    This sounds very similar to an approach called Lightweight Modular Staging (pioneered in Scala by the Oderski group - http://scala-lms.github.io/ http://scala-lms.github.io/ and also in Lua - http://terralang.org/ http://terralang.org/). While this is great for specializing numeric code based on runtime invariants like dimensionality, I think people are finally looking at using the idea in other domains - for example, runtime generation of DSL code on a per instantiation basis. Imagine taking a high level SQL query, building the operator tree in a Julia DSL and optimizing that, and then JITing the entire thing taking into account low level storage details and the particular sets of operators and joins (http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf). This is very exciting to see in another typed language!
edelman 12y ago
Yes, this paper, as the title suggests, was written perhaps for the community as a whole, but perhaps in particular for the numerical computing community. Most especially, there are many ideas in this paper that are entirely unfamiliar to that community, and this paper hopes to change that. Hope you enjoy the reading. (We probably will make some updates. The spelling fix of the title was already processed yesterday and will appear tomorrow or Monday.)
Blahah 12y ago
Nice paper guys. Any plan to get something peer-reviewed? It would be useful for motivating biologists. Anyone interested in using Julia for bioinformatics is invited to contribute to, or follow the progress of, the BioJulia project: https://github.com/BioJulia/Bio.jl https://github.com/BioJulia/Bio.jl
- ViralBShah 12y ago
  Yes, we do want to submit it to a SIAM journal. It does seem that we are already getting interesting feedback here. The BioJulia team will probably write a paper on Julia in Biology and publish in a related journal, just like Miles Lubin and Iain are doing with JuMP in the OR community.
  - Blahah 12y ago
    Yup, we'll definitely do one for BioJulia - but we've got a way to go before we reach that stage :)
- deleted 12y ago
  [deleted]
EvanMiller 12y ago
For anyone in the Chicago area, Leah Hanson is giving a free Julia workshop next weekend (11/15): http://www.meetup.com/JuliaChicago/events/216950712/ http://www.meetup.com/JuliaChicago/events/216950712/ Should be a great way to get introduced to the language and pose your nagging questions to a community expert.
- willis77 12y ago
  Her blog is also a great resource to pick up some of the more useful parts of the language.
  - StefanKarpinski 12y ago
    Not to mention her forthcoming O'Reilly book, "Learning Julia"!
mearnsh 12y ago
anyone know where I can get a juliabox.org invite code?
- ViralBShah 12y ago
  Shoot me an email - viral@mayin.org
  - kartikkumar 12y ago
    Mind if I shoot you an email too for an invite?
    - ViralBShah 12y ago
      Yes - happy to share codes with anyone. Also, we will be simplifying the invite system in the next few days so that JuliaBox will let you in without any code by default. In the rare cases of a surge, such as an HN mention, it will auto-release account approvals as the surge subsides in a few hours. Once you do have access, you will continue to have access, even during surges. Basically, we are just trying to manage our compute budget better.
wbhart 12y ago
From the article: " A pervasive idea that Julia wishes to shatter is that technical computing languages are “prototyping” languages and one must switch to C or Fortran for performance. The consequences to scientific computing have been more serious than many realize." I think this provides a very succinct summary of the Julia paradigm at a very high level.
- carterschonwald 12y ago
  I'm trying to push haskell for that too. But the more decent tools and choices, the better for everyone. :-)
jostmey 12y ago
I've been using Julia for a few months and I love it! Being able to process arrays in a function as if it was a single variable is super awesome, and as a result my code uses far fewer for/while loops.
ForHackernews 12y ago
Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.
- StefanKarpinski 12y ago
  Gadfly is an excellent ggplot2-style plotting package: http://gadflyjl.org http://gadflyjl.org Winston is a most traditional plotting API: http://winston.readthedocs.org/en/latest/examples.html http://winston.readthedocs.org/en/latest/examples.html You can also plot seamlessly via Python using PyPlot: https://github.com/stevengj/PyPlot.jl https://github.com/stevengj/PyPlot.jl They are all quite well documented.
  - tomrod 12y ago
    Still working my way through them myself. Useful examples working through docs would be useful. Most seem to presume a lot of knowledge of the libraries.
    - ViralBShah 12y ago
      You are right - package documentation has some ways to go. Currently we don't yet have a mechanism to do `help()` on a package function, but we expect that to change in 0.4.
      - tomrod 12y ago
        Would love to help in some way.
  - ForHackernews 12y ago
    Thanks. I guess I would disagree with the assertion that Gadfly is "quite well documented". It has some docs, but they are mostly just a list of parameters (with no indication of what values you could/should set them to) and maybe one example, e.g. http://gadflyjl.org/geom_boxplot.html http://gadflyjl.org/geom_boxplot.html Perhaps it's all very obvious if you're already familiar with ggplot2, but as somebody without an R background, I found their docs extremely spartan.
science404 12y ago
is it just me or is arxiv.org down? HN effect?
- science404 12y ago
  for anyone experiencing issues with arxiv.org, mirror: http://uk.arxiv.org/abs/1411.1607 http://uk.arxiv.org/abs/1411.1607
dagw 12y ago
Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations helped but I never got closer than 50% slower than Octave. In earlier test I've seen cases where Julia was literally 12 times slower than python/numexpr in real world code. I really want to love Julia and everything I read about it makes me think it's the language for me, but every time I try to write non-toy code the performance is always worse than python.
- jostmey 12y ago
  I've observed a huge performance boost over python -- I wrote a simple artificial neural network trained using backpropagation in both languages and my Julia code ran orders of magnitude faster. Something is clearly screwed up with your implementation of Julia. There is no way octave should be running faster.
  - grayclhn 12y ago
    Octave occasionally runs faster than Julia for transliterated vectorized vector and matrix operations. Julia then runs much faster when those operations are devectorized or replaced with builtin functions. But that's a pretty common source of these issues (at least on the mailing list.)
    - ViralBShah 12y ago
      It would be good to know where we are slow, so that we can fix it. Can you for an issue with an example on github?
      - grayclhn 12y ago
        I'll do it right now. These aren't issues I've personally run across, though, just stuff on julia-users. edit: Nevermind! On rereading the mailing list thread (especially this message [1]), I might have mischaracterized the issue slightly. It probably came from speed issues with small integer powers (i.e., there are faster ways to exponentiate small integer powers than there are for general exponentiation that Julia hadn't been using but other software like matlab and octave were), and that issue in Julia seems to be fixed now.[2] [1] https://groups.google.com/d/msg/julia-users/n3LfteWJAd4/jag6AZNvSEsJ https://groups.google.com/d/msg/julia-users/n3LfteWJAd4/jag6... [2] https://github.com/JuliaLang/julia/issues/2741 https://github.com/JuliaLang/julia/issues/2741
gct 12y ago
The one based indexing pretty much kills the entire thing for me.
- CyberDildonics 12y ago
  Then you are missing out on a wonderful programming tool for a very superficial reason. I wish indices were offsets like C and not indexes like Lua, but I'll deal with it for all the language gives.
- ninjaplease 12y ago
  why?
kartikkumar 12y ago
The biggest challenge I'm facing now is how to convince those around me to take the leap and step over to Julia. We have a wealth of legacy code in MATLAB, C++ and Fortran. I've seen the various methods to call these codes from Julia, but in the case of C++, it seems that only rudimentary support is provided. My goal is to port a lot of my code to set up astrodynamics simulations. I've even created a placeholder Github repo for it [1]. Just have to find the right strategy to involve the dev in my existing projects and get my colleagues to chip in. [1] https://github.com/kartikkumar/Astro.jl https://github.com/kartikkumar/Astro.jl
vegabook 12y ago
I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothing to be ashamed of versus any of the newer kids on the block. I have been weary of the Julia pitch which was basically "lets brew R, Python, and Matlab (all >20 years old with massive and unrivalled ecosystems and all serving their purposes very well, thank you) into one "new" language and put a nice logo on it". How is this language seriously the leap forward that one needs to abandon the current awesome toolsets, with all their battle tested libraries, other than a nebulous "speed" argument which in many cases, judging by the comments and my own experience in financial data matrix operations, is not even fully accurate? Ready to be persuaded otherwise if I can be shown that other than "speed" there are hefty reasons to move from Python and abandon the almost endless choice of richly varied tools that I have at my disposal already.
- one-more-minute 12y ago
  You should read the paper, but Julia's also a really nicely designed language in general. It's hard to communicate how great multiple dispatch + a powerful type system is without trying it out (though, again, the paper does a good job), but yeah, it really helps you get a lot of generality as well as performance. When you use Cython, you immediately lose that generality. Then there's the really powerful metaprogramming capabilities, which are absent from the languages you've mentioned. I can't emphasise it enough: the paper this comment thread is about does a great job of explaining why these things are compelling. Also, you may be interested in [1], an argument that language performance is valuable even if you don't need it yourself. [1]: https://medium.com/the-julia-language/performance-matters-more-than-you-think-a556e6cdcd10 https://medium.com/the-julia-language/performance-matters-mo...
  - vegabook 12y ago
    Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperative (though R's vectorisation-everywhere is impressive - wish it was all just faster); I hope Julia will give me something dramatically more interesting. I say that because the LLVM has ushered in a period of radically easier language development, so we are likely to be spoiled for choice in the next 5 years. I hope Julia has done enough to put itself way out there in in terms of innovation to make the sizeable investment of time for myself and library developers, worthwhile. Altogether however I cannot be anything other than impressed with the dogged and convincing pitch that you and others are making for it, which somewhat lowers the risk of investing time in a dead end. And even if it doesn't work out all hunky, at least I'll know that Python will face serious competition, and that can only be good, even for Python.

215 points by sveme 12y ago

Despite having a very similar title, this is a rather different paper from http://arxiv.org/abs/1209.5145 http://arxiv.org/abs/1209.5145. We had to upload a version of this paper for a grant application, but it's still somewhat in progress.

ViralBShah 12y ago
That's right. The purpose was to have twin papers - one for the Computer Science community focussed on language implementation, which is the earlier paper. This paper focusses on motivating the design of Julia for the larger scientific community. Any comments will be incredibly valuable in improving the quality of the paper.
- trurl42 12y ago
  It's great to have a paper like this on the arXiv, I believe this is the right way to reach the scientific community. Some ideas for improvements: The package directory could be mentioned more prominently. It's a bit tricky to select code in the PDF, not sure if much can be done about this?
  - ViralBShah 12y ago
    I guess we can publish the IJulia notebooks with the examples and even just the code as plain .jl files.

monochr 12y ago

What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there. Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn't.

sgt101 12y ago
I would say Julia sucks for embedded programming :); building graphical clients - although not badly as there are various js libaries that it can chat to, games programming, it's not great at data base interaction although once you have the data in it it is fine (frames). The last point is a bit of a development area I would expect to see because Julia has a console and this means that interactive querying would be great - like SQL on steroids but currently without the sql unfortunatley. Julia shines at developing efficient reusable code for crunching numbers. The type system is really nice, and the syntax is very clean and natural (to me!)
- ViralBShah 12y ago
  There is work happening on the UI side in Julia. While we are some ways away from building graphical clients in Julia, we do have GTK bindings and such. For some interesting ideas borrowed from Elm, do see: https://github.com/shashi/Patchwork.jl https://github.com/shashi/Patchwork.jl
  - infinite8s 12y ago
    Is anyone working on direct Qt bindings (I don't consider using PyCall a viable option). Qt is a bit harder to wrap since it is C++, but it look like Lua has been able to auto generate bindings based on the Qt headers.
    - StefanKarpinski 12y ago
      Keno Fischer, who recently created the Cxx package [1] used to be a Qt dev, so I wouldn't be terribly surprised if we see such bindings materialize in the future, using Cxx, of course. That said, I don't want to speak for him, so if someone wants this, they should maybe go ahead and start working on it! [1] https://github.com/Keno/Cxx.jl https://github.com/Keno/Cxx.jl
amelius 12y ago
What I'd like to know when learning a new language is: why can't this be done in an existing language? Take for example the R programming language. Things you do in this language can be perfectly well done in e.g. Python too. Same goes for the MATLAB language.

deleted 12y ago

[deleted]

af3 12y ago

How it's better than Fortran?

wbhart 12y ago

I've been playing around with the Cxx library (currently only works with a source build of bleeding edge Julia) https://github.com/Keno/Cxx.jl https://github.com/Keno/Cxx.jl It allows you to basically embed ordinary C++ code in Julia code, to interface with C++ libraries at runtime, and to slurp in entire .h files unmodified. (It also in theory allows a C++ REPL mode to be written, though such a thing does not exist for Julia yet.) It makes very clever use of a really amazing new language feature in Julia 0.4, namely staged functions. At first it looked like it was manipulating C++ via strings sent to the Clang compiler at runtime, which sounded really slow and awful. But then it dawned on me how it really worked, and I was amazed. I've actually convinced three or four of my colleagues (mathematicians) to work on building a computer algebra system with Julia that will interface to various packages such as Pari/GP, flint, Singular, possibly Gap. We meet weekly to discuss design and to try and work on an initial implementation. The rate at which Julia is improving and the community is increasing is astonishing. We are at the stage where Julia is offering us language features we haven't even dreamed up a use for! And yet the language remains elegant and easy to learn.

one-more-minute 12y ago
For reference, a staged function is something sorta similar to a macro, except it lets you take advantage of Julia's inferred type info. Contrived (and wholly redundant) example: stagedfunction foo(x) if x == Int :(2x) else :x end end y = 1 foo(y) == 2 y = 1. foo(y) == 1.0 Again, just like a macro, except that before `x` is quoted you work with the type of y instead of the symbol `y`. This means you can do even more crazy code specialisation, including on e.g. matrix dimensions or generating appropriate FFI calls based on arbitrary input types. It has zero overhead and you can use it just like a regular function. Very cool, and I think people will do really interesting things with this (especially after mixing them with macros).
- infinite8s 12y ago
  This sounds very similar to an approach called Lightweight Modular Staging (pioneered in Scala by the Oderski group - http://scala-lms.github.io/ http://scala-lms.github.io/ and also in Lua - http://terralang.org/ http://terralang.org/). While this is great for specializing numeric code based on runtime invariants like dimensionality, I think people are finally looking at using the idea in other domains - for example, runtime generation of DSL code on a per instantiation basis. Imagine taking a high level SQL query, building the operator tree in a Julia DSL and optimizing that, and then JITing the entire thing taking into account low level storage details and the particular sets of operators and joins (http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf). This is very exciting to see in another typed language!

edelman 12y ago

Yes, this paper, as the title suggests, was written perhaps for the community as a whole, but perhaps in particular for the numerical computing community. Most especially, there are many ideas in this paper that are entirely unfamiliar to that community, and this paper hopes to change that. Hope you enjoy the reading. (We probably will make some updates. The spelling fix of the title was already processed yesterday and will appear tomorrow or Monday.)

Blahah 12y ago

Nice paper guys. Any plan to get something peer-reviewed? It would be useful for motivating biologists. Anyone interested in using Julia for bioinformatics is invited to contribute to, or follow the progress of, the BioJulia project: https://github.com/BioJulia/Bio.jl https://github.com/BioJulia/Bio.jl

ViralBShah 12y ago
Yes, we do want to submit it to a SIAM journal. It does seem that we are already getting interesting feedback here. The BioJulia team will probably write a paper on Julia in Biology and publish in a related journal, just like Miles Lubin and Iain are doing with JuMP in the OR community.
- Blahah 12y ago
  Yup, we'll definitely do one for BioJulia - but we've got a way to go before we reach that stage :)
deleted 12y ago
[deleted]

EvanMiller 12y ago

For anyone in the Chicago area, Leah Hanson is giving a free Julia workshop next weekend (11/15): http://www.meetup.com/JuliaChicago/events/216950712/ http://www.meetup.com/JuliaChicago/events/216950712/ Should be a great way to get introduced to the language and pose your nagging questions to a community expert.

willis77 12y ago
Her blog is also a great resource to pick up some of the more useful parts of the language.
- StefanKarpinski 12y ago
  Not to mention her forthcoming O'Reilly book, "Learning Julia"!

mearnsh 12y ago

anyone know where I can get a juliabox.org invite code?

ViralBShah 12y ago
Shoot me an email - viral@mayin.org
- kartikkumar 12y ago
  Mind if I shoot you an email too for an invite?
  - ViralBShah 12y ago
    Yes - happy to share codes with anyone. Also, we will be simplifying the invite system in the next few days so that JuliaBox will let you in without any code by default. In the rare cases of a surge, such as an HN mention, it will auto-release account approvals as the surge subsides in a few hours. Once you do have access, you will continue to have access, even during surges. Basically, we are just trying to manage our compute budget better.

wbhart 12y ago

From the article: " A pervasive idea that Julia wishes to shatter is that technical computing languages are “prototyping” languages and one must switch to C or Fortran for performance. The consequences to scientific computing have been more serious than many realize." I think this provides a very succinct summary of the Julia paradigm at a very high level.

carterschonwald 12y ago
I'm trying to push haskell for that too. But the more decent tools and choices, the better for everyone. :-)

jostmey 12y ago

I've been using Julia for a few months and I love it! Being able to process arrays in a function as if it was a single variable is super awesome, and as a result my code uses far fewer for/while loops.

ForHackernews 12y ago

Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.

StefanKarpinski 12y ago
Gadfly is an excellent ggplot2-style plotting package: http://gadflyjl.org http://gadflyjl.org Winston is a most traditional plotting API: http://winston.readthedocs.org/en/latest/examples.html http://winston.readthedocs.org/en/latest/examples.html You can also plot seamlessly via Python using PyPlot: https://github.com/stevengj/PyPlot.jl https://github.com/stevengj/PyPlot.jl They are all quite well documented.
- tomrod 12y ago
  Still working my way through them myself. Useful examples working through docs would be useful. Most seem to presume a lot of knowledge of the libraries.
  - ViralBShah 12y ago
    You are right - package documentation has some ways to go. Currently we don't yet have a mechanism to do `help()` on a package function, but we expect that to change in 0.4.
    - tomrod 12y ago
      Would love to help in some way.
- ForHackernews 12y ago
  Thanks. I guess I would disagree with the assertion that Gadfly is "quite well documented". It has some docs, but they are mostly just a list of parameters (with no indication of what values you could/should set them to) and maybe one example, e.g. http://gadflyjl.org/geom_boxplot.html http://gadflyjl.org/geom_boxplot.html Perhaps it's all very obvious if you're already familiar with ggplot2, but as somebody without an R background, I found their docs extremely spartan.

science404 12y ago

is it just me or is arxiv.org down? HN effect?

science404 12y ago
for anyone experiencing issues with arxiv.org, mirror: http://uk.arxiv.org/abs/1411.1607 http://uk.arxiv.org/abs/1411.1607

dagw 12y ago

Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations helped but I never got closer than 50% slower than Octave. In earlier test I've seen cases where Julia was literally 12 times slower than python/numexpr in real world code. I really want to love Julia and everything I read about it makes me think it's the language for me, but every time I try to write non-toy code the performance is always worse than python.

jostmey 12y ago
I've observed a huge performance boost over python -- I wrote a simple artificial neural network trained using backpropagation in both languages and my Julia code ran orders of magnitude faster. Something is clearly screwed up with your implementation of Julia. There is no way octave should be running faster.
- grayclhn 12y ago
  Octave occasionally runs faster than Julia for transliterated vectorized vector and matrix operations. Julia then runs much faster when those operations are devectorized or replaced with builtin functions. But that's a pretty common source of these issues (at least on the mailing list.)
  - ViralBShah 12y ago
    It would be good to know where we are slow, so that we can fix it. Can you for an issue with an example on github?
    - grayclhn 12y ago
      I'll do it right now. These aren't issues I've personally run across, though, just stuff on julia-users. edit: Nevermind! On rereading the mailing list thread (especially this message [1]), I might have mischaracterized the issue slightly. It probably came from speed issues with small integer powers (i.e., there are faster ways to exponentiate small integer powers than there are for general exponentiation that Julia hadn't been using but other software like matlab and octave were), and that issue in Julia seems to be fixed now.[2] [1] https://groups.google.com/d/msg/julia-users/n3LfteWJAd4/jag6AZNvSEsJ https://groups.google.com/d/msg/julia-users/n3LfteWJAd4/jag6... [2] https://github.com/JuliaLang/julia/issues/2741 https://github.com/JuliaLang/julia/issues/2741

gct 12y ago

The one based indexing pretty much kills the entire thing for me.

CyberDildonics 12y ago
Then you are missing out on a wonderful programming tool for a very superficial reason. I wish indices were offsets like C and not indexes like Lua, but I'll deal with it for all the language gives.
ninjaplease 12y ago
why?

kartikkumar 12y ago

The biggest challenge I'm facing now is how to convince those around me to take the leap and step over to Julia. We have a wealth of legacy code in MATLAB, C++ and Fortran. I've seen the various methods to call these codes from Julia, but in the case of C++, it seems that only rudimentary support is provided. My goal is to port a lot of my code to set up astrodynamics simulations. I've even created a placeholder Github repo for it [1]. Just have to find the right strategy to involve the dev in my existing projects and get my colleagues to chip in. [1] https://github.com/kartikkumar/Astro.jl https://github.com/kartikkumar/Astro.jl

vegabook 12y ago

I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothing to be ashamed of versus any of the newer kids on the block. I have been weary of the Julia pitch which was basically "lets brew R, Python, and Matlab (all >20 years old with massive and unrivalled ecosystems and all serving their purposes very well, thank you) into one "new" language and put a nice logo on it". How is this language seriously the leap forward that one needs to abandon the current awesome toolsets, with all their battle tested libraries, other than a nebulous "speed" argument which in many cases, judging by the comments and my own experience in financial data matrix operations, is not even fully accurate? Ready to be persuaded otherwise if I can be shown that other than "speed" there are hefty reasons to move from Python and abandon the almost endless choice of richly varied tools that I have at my disposal already.

one-more-minute 12y ago
You should read the paper, but Julia's also a really nicely designed language in general. It's hard to communicate how great multiple dispatch + a powerful type system is without trying it out (though, again, the paper does a good job), but yeah, it really helps you get a lot of generality as well as performance. When you use Cython, you immediately lose that generality. Then there's the really powerful metaprogramming capabilities, which are absent from the languages you've mentioned. I can't emphasise it enough: the paper this comment thread is about does a great job of explaining why these things are compelling. Also, you may be interested in [1], an argument that language performance is valuable even if you don't need it yourself. [1]: https://medium.com/the-julia-language/performance-matters-more-than-you-think-a556e6cdcd10 https://medium.com/the-julia-language/performance-matters-mo...
- vegabook 12y ago
  Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperative (though R's vectorisation-everywhere is impressive - wish it was all just faster); I hope Julia will give me something dramatically more interesting. I say that because the LLVM has ushered in a period of radically easier language development, so we are likely to be spoiled for choice in the next 5 years. I hope Julia has done enough to put itself way out there in in terms of innovation to make the sizeable investment of time for myself and library developers, worthwhile. Altogether however I cannot be anything other than impressed with the dogged and convincing pitch that you and others are making for it, which somewhat lowers the risk of investing time in a dead end. And even if it doesn't work out all hunky, at least I'll know that Python will face serious competition, and that can only be good, even for Python.