6 ms·

So how is julia nowadays? I stopped using and following it sometime ago as I found it as slow as python, or worse, for anything that wasn't numerical computing.

• eigenspace 6y ago
  I think julia has evolved a ton over the past few years and a lot of work has gone into making things that aren't numerical computing feel like first class uses of the language. A very popular thing right now in the community is people making websites, dashboards, visualization tools, etc. with julia. There's a lot of people thinking about things like string handling due to NLP, bioinformatics and a few other technical fields that don't use the same standard datatypes you'd expect from an engineer or whatever. I do a lot of random hobby programming, often building random tools that aren't necessarily numerical programming related and I find it quite natural and easy to make these things highly performant (often with no runtime overhead).
• socialdemocrat 6y ago
  If you are not being specific it is impossible to know what you are talking about. It could be a library thing or it could be that your are really just describing the initial latency of the JIT compilation. If you look at the well known language shootout you will see Julia today beats almost everything even on multicore. The clear exception is anything related to garbage collection. But you can circumvent this with turning off the garbage collector temporarily.
• leephillips 6y ago
  First time I've heard anything like that. Most people report a massive speedup without doing anything special. Maybe try the current version?
  • cbkeller 6y ago
    I had an experience slightly like that at first where I was surprised to only be going 1-2x faster than my old MATLAB, but then I realized my code was full of trivially avoidable type instabilities and got another 100x speedup in Julia.
  • zetalemur 6y ago
    Probably because it is mostly compared to Python - which is arguably a low bar to beat.
    • ddragon 6y ago
      Python is a high bar to beat though, since no one understands beating Python as beating some hypothetical Python-only numerical library, it's beating mature precompiled C/C++/Fortran libraries with a small overhead in Python. And there are very few dynamic languages that can even compete on this level (without needing the FFI), and even static languages will have trouble dealing with the level of optimization that went on those libraries. But everything has compromises, and in Julia case is the JIT lag from aggressively optimizing compilation, making it a slow language for simple do once tasks (which is the part that is usually written in Python) and a fast language for when runtime performance is the most important (which is the part done by the libraries in C/C++/Fortran), making it slower in some situations. Though new releases are attacking this issue, including the ability to not optimize this do once tasks (like plotting) and improving pre-compiling. But as for now, the ability to not have black boxes and not being required to twist my code to a particular style in order to not be prohibitive slow makes up for the slow startup (plus using Revise.jl to automatically compile code in a REPL, and keep the session alive for all my programming routine makes it not that much of a deal during development).
  • rich_sasha 6y ago
    FWIW that was my experience too. And the JIT was too slow for my pace of code changes. Also really wanted to love it. Maybe I need to try the new version.
    • socialdemocrat 6y ago
      You need to start using Revise.jl that is the key to using Julia effectively. If the JIT is too slow then, then I really wonder what you are doing. I have no performance issues but on a 5 year old computer, apart from the famous first time to plot or bringing in a whole new library. I don’t have issues with modifying my own code however when using Revise.jl
  • datanecdote 6y ago
    Let me second GP’s sentiment. I find Julia really slow for my purposes. I don’t know his reasoning, but I will explain mine. None of this is surprising and is oft discussed. Julia (at least by default) is constantly recompiling everything. This is a huge pain in a REPL style setup where you want to tweak one thing and see the changes, again and again. I know the Julia ecosystem is working on better caching etc to fix this problem but it’s a problem. Also, despite the marketing claims around the language, expertly crafted C usually beats Julia in performance. So if your “python” program is spending most of its time in Numpy/PyTorch/etc, it will beat Julia, unless you’re writing a fancy “put a differential equation in a neural network in a Bayesian Monte Carlo” program that benefits from cross compiling across specialized libraries. Finally, the Julia libraries are just not as mature as python’s. Armies of developers and larger armies of users have battle tested and perfected python’s crown jewel libraries over many years. Often when someone posts a bad benchmark to the Julia forums they can “fix” it in the library implementation, proving the correctness of the theoretical case for Julia. But in reality many such problems remain to be fixed. Julia is really cool and does have many inherent advantages over python. But it’s not the silver bullet many of its proponents suggest it to be. At least not yet. Every few years I check out Julia and I hope one day it does become that perfect language. I think it will. I just fear it will take longer than many others hope.
    • timholy 6y ago
      I appreciate your well-balanced critique, thanks. > Julia (at least by default) is constantly recompiling everything. This is a huge pain in a REPL style setup where you want to tweak one thing and see the changes, again and again. I know the Julia ecosystem is working on better caching etc to fix this problem but it’s a problem. Maybe try Revise.jl? There are a few changes it can't handle, but you can do a lot of development without ever restarting. (Disclaimer: I'm its main author.) > expertly crafted C usually beats Julia in performance This isn't generically true, and there are now quite a few examples of the converse. I linked to it above as well, but check out the benchmarks in LoopVectorization's documentation (https://chriselrod.github.io/LoopVectorization.jl/latest/examples/matrix_multiplication/#Matrix-Multiplication-1 https://chriselrod.github.io/LoopVectorization.jl/latest/exa...) for examples of beating MKL, one of the most carefully-engineered libraries in existence. I think an exciting area of growth for Julia will be exploiting the fact that Julia's compiler, written mostly in Julia, is more "morphable" than most and may develop its own plug-in architecture. This seems likely to provide performance opportunities that many fields seem hungry for. > the Julia libraries are just not as mature as python’s On balance I agree. While there are already many examples where Julia makes things easier than Python, as of today there are many more examples to the contrary. Julia's libraries are advancing rapidly, but I expect it will take a few more years of development until it's no longer so one-sided.
  • teorema 6y ago
    My experience with Julia is that for many (most?) things, you do get a free speedup basically. With other things though, it's about the same. What this means in practice is that if you expand your use cases enough, and integrate enough libraries, you'll incorporate some bottleneck that slows it down. This is true of a lot of languages, python included, but I think when part of the language's selling point is something like "c-like speed with python-like syntax" it can be a little (although not entirely) misleading. Having said that, I still prefer Julia over python (at least for numerical computing, not so sure about other things). I just like the language more. I also think, with some exceptions, that I don't have the same dependency hell problems that I've run into with python. Even now, I'm in the process of switching over to Julia from python for a project because the python library I'm using depends on about 6 different other libraries, but only specific versions, that you have to run in a specific standalone conda environment to avoid using the wrong combination of packages, all of which are pre-python3, and so forth and so on. Even then, when you manage to thread the needle, it still falls apart later for unknown reasons. This is surely this particular package, but my experience with Julia is that things are much cleaner (R is similarly problem-free usually but it's a lot slower and Julia as a language is more coherent to me). I'd really prefer something like Nim to be seeing the attention that Julia is getting, something more general-purpose, but there's no consensus of momentum around something like that at the moment. Maybe in the near future ocaml will pick up steam, or maybe the next version of C++ will essentially make it look like python, or maybe there will be something not quite on people's radar at the moment, but at the moment it is what it is.
• dklend122 6y ago
  It used to have slower dicts and string handling like around version 0.5. It's come a very very long way since then. Now at 1.5. It's much faster for arbitrary code
• fantod 6y ago
  Really? My only experience with Julia was porting a simulation from Python and the speedup was incredible. Admittedly, that's an instance of numerical computing, but I would wonder why it was slow for you.
  • rich_sasha 6y ago
    This is only meta analysis, but some topics come up more frequently when people say how impressed they are with Julia. Simulations, ODEs, tight for-loops seem to be high on the lists. “Generic” data science doesn’t, or indeed general, unscientific programming. Perhaps this is not right, or outdated, but my impression is that Julia is perhaps very well suited to _some_ scientific programming, not necessarily all of it, despite the broad statements.
    • jakobnissen 6y ago
      I think ODEs and numerical computing gets mentioned because it was the first area where Julia packages outshined all alternatives. It originated among physicists and mathematicians, so it has a "head start" in these areas. Julia is a general-purpose programming language, despite having roots in scientific programming. Its performance characteristics with its high latency and runtime memory overhead makes it unsuitable for a number of non-scientific applications. But not all. I think Julia would work excellent as a webserver backend, for example. I mostly use it for DNA sequence processing, which is not really numerical programming, but more string processing. There it shines. I wouldn't want to make a video game in Julia or fly a plane using Julia software.
  • goatinaboat 6y ago
    Really? My only experience with Julia was porting a simulation from Python and the speedup was incredible. The bang-for-your-buck of adding Numba to existing Python code is why we passed on Julia. Give it a try.
    • jakobnissen 6y ago
      The problem with Numba is that it only really works in small, limited usecases. Good for e.g. Numpy arrays, but can it provide these massive speedups with custom classes? Arrays of strings? Sets? Probably not, since both Julia and Numba relies on inferring the data types of all objects, and on them being stored efficiently in memory. The Julia type system allows easy type inference, and all custom structs are stored efficiently in memory. In Python, neither of those are true.
• jakobnissen 6y ago
  In my experience, the big "problem" with Julia's performance is that while it's actually a compiled language, it's also dynamic. In most compiled languages, if you write code the compiler can't completely infer, it just won't compile. Conversely, once your program compiles, you don't have to worry about the compiler anymore when running the binary - you know your program is compiled effectively. A Julia program, on the other hand, will run just fine if the compiler can't figure out the types at compile time. It will just infer whatever it can, run that, and then use runtime values when it needs to. That's a big plus for people like me where performance doesn't matter 95% of the time, but it's a bit of a performance trap for newbies. Almost all cases of people complaining about Julia being slow come from them inadvertantly writing code the compiler can't infer properly. Luckily, Julia has interactive tools to check the inference of functions. In my experience, once you get used to writing Julia, it's rare that you accidentally write non-inferrable code.
  • cbkeller 6y ago
    Yeah, I think type instability is definitely the biggest culprit when someone's ported over some Python or Matlab code for the first time and isn't getting as much of a speedup as expected. It isn't hard to fix, you just have to know about it (and how to check for it with `@code_warntype`). That and perhaps the excess unnecessary allocations from array indexing on the right hand side of an assignment, if you don't know about `view`s.