3 ms·

> I like Julia because it's extremely fast ...compared to Python, under some circumstances, disregarding startup time. Don't oversell it. Don't confuse what J

by rspeer 10y ago

> I like Julia because it's extremely fast ...compared to Python, under some circumstances, disregarding startup time. Don't oversell it. Don't confuse what Julia aspires to be with what it is, or you'll just turn people off when they feel they've been misled. There are extremely fast ahead-of-time-compiled languages that would have finished their computation while Julia is still JIT-ing its kernel.

StefanKarpinski 10y ago
Julia startup time is 0.5 seconds on a very weak laptop. That's comparable to the JVM, which is nevertheless fairly popular. You may not want to write command line tools in Julia, but there's not much else that's a serious problem since process startup time is rarely that big of a performance issue. Disregarding JIT time, Julia is as fast as compiled languages – we benchmark against C and Fortran and don't grade on a curve. This is not an aspiration, it's a well-established performance characteristic in both benchmarks [1] and real-world applications [2]. Regarding JIT time, it's important to understand that this is a fixed cost – for any computation that takes long enough to matter, the time taken by JIT will be a negligible fraction of the time. The reason to exclude JIT time when benchmarking is because most benchmarks don't take much time – tens of milliseconds, compared to which JIT is significant. But we don't actually care about the speed of things that only take tens of milliseconds – we're using benchmarks to extrapolate to things that take much longer, which is why you exclude JIT. [1] http://julialang.org/benchmarks/ http://julialang.org/benchmarks/ [2] http://juliacomputing.com/case-studies/ http://juliacomputing.com/case-studies/
- rspeer 10y ago
  When I last used it, the time to import even two modules was many seconds. I know that's JIT time, but that breaks the flow of developing with Julia like it's a dynamic language. And the JVM is popular, yes, but nobody would call it "extremely fast", particularly for interactive use, because of its startup time. The time to parse the data I needed was many minutes, slower than Python. Restarting a Jupyter kernel would break my flow every time. The benchmarks are all for numerical computing, where the hard work is typically offloaded to a BLAS library anyway, and don't involve strings or dictionaries. Let's see a JSON parser in there and not just a Mandelbrot set.
  - 3JPLW 10y ago
    When was the last time you used it? Module loading times improved significantly with precompilation in 0.4.
    - rspeer 10y ago
      Yeah, it was 0.3. So that would address the importing problem, if the modules I'm importing use the precompilation system. How is string performance doing?
      - jernfrost 10y ago
        A LOT has happened since then. For such a young language which hasn't even reached version 1.0 yet you can expect a lot of changes still. You should seriously try out Julia again. I think it really works well now. I used to have a lot of issues with it before. Stuff would break, slow startup times etc. Today I don't really have any complaints. Ok I got a few small ones. The limits on the ability to redefine stuff as you develop in the REPL can be a bit cumbersome.
      - StefanKarpinski 10y ago
        0.3 was quite some time ago – string performance was certainly a problem back then (an acknowledged one). String performance on 0.6-alpha, released last week, is very good. It should now be at least as good as scripting languages that have traditionally focused on strings (Python, Ruby, Perl). There are a few more tricks we could do in the future that could make this even faster, but they involve a fair amount of GC trickery, so we'll have to see.
      - throwaway399 10y ago
        I also stopped using after 0.3 and tried it recently again to speed up some NLP code in Python3 and it hasn't been faster than Python3. Back then I didn't like the poor support for pyjulia, slow string processing, people using unicode symbols as variables, module import system, lack of libraries for more obscure NLP algos, and startup time. I know these aren't major issues for the core users of Julia, but these were my concerns. The way I wrote the current code in Python was abusing sets and dicts a lot to take advantage of those fast data structs. Rewriting in Julia was fun because it was different and because multiple dispatch is fun. However, it was roughly the same speed as Python. Ended up sprinkling some Cython on top of Python and resulted in 10x speedup. Didn't take much time to add types/pass pointers instead of strings to functions. I am not at all familiar with C++/Cython. I think even if they speed strings/dicts up by a lot, there seem to be lots of breaking changes between releases so I wouldn't try it for something big. I think if Julia is to succeed in the near future in the same way Python is successful for data science, it needs to be more usable for general tasks. Things like web servers, fast JSON parsing, maybe static binaries or easy parallelism. Basically, some more selling points. So far, for me personally Python is faster and easier to read for most of the things I write. At least given comparable amount of work.
- pron 10y ago
  I really like the language, and I've recently used Julia in a scientific computing project, but the experience leaves much to be desired (and I'm certain it will be improved). Startup time isn't the biggest problem, although it is nowhere near "comparable to the JVM". The JVM will start cold, load a Hello World application from a JAR, run it and shut down in 60-80ms. A Julia Hello World app would take at least a second, even when precompiled into a native executable. The biggest problem, IMO, is packaging and deployment. I used BuildExecutable, which works OK most of the time (although startup times are still slow), but it results in so many shared libraries, with no easy way to cull them. Without BuildExecutable, I couldn't even find documentation on how to deploy a Julia app as a self-contained program (even not precompiled, but in a way that doesn't require Julia to be installed on the user's machine).

by rspeer 10y ago

StefanKarpinski 10y ago

Julia startup time is 0.5 seconds on a very weak laptop. That's comparable to the JVM, which is nevertheless fairly popular. You may not want to write command line tools in Julia, but there's not much else that's a serious problem since process startup time is rarely that big of a performance issue. Disregarding JIT time, Julia is as fast as compiled languages – we benchmark against C and Fortran and don't grade on a curve. This is not an aspiration, it's a well-established performance characteristic in both benchmarks [1] and real-world applications [2]. Regarding JIT time, it's important to understand that this is a fixed cost – for any computation that takes long enough to matter, the time taken by JIT will be a negligible fraction of the time. The reason to exclude JIT time when benchmarking is because most benchmarks don't take much time – tens of milliseconds, compared to which JIT is significant. But we don't actually care about the speed of things that only take tens of milliseconds – we're using benchmarks to extrapolate to things that take much longer, which is why you exclude JIT. [1] http://julialang.org/benchmarks/ http://julialang.org/benchmarks/ [2] http://juliacomputing.com/case-studies/ http://juliacomputing.com/case-studies/

rspeer 10y ago
When I last used it, the time to import even two modules was many seconds. I know that's JIT time, but that breaks the flow of developing with Julia like it's a dynamic language. And the JVM is popular, yes, but nobody would call it "extremely fast", particularly for interactive use, because of its startup time. The time to parse the data I needed was many minutes, slower than Python. Restarting a Jupyter kernel would break my flow every time. The benchmarks are all for numerical computing, where the hard work is typically offloaded to a BLAS library anyway, and don't involve strings or dictionaries. Let's see a JSON parser in there and not just a Mandelbrot set.
- 3JPLW 10y ago
  When was the last time you used it? Module loading times improved significantly with precompilation in 0.4.
  - rspeer 10y ago
    Yeah, it was 0.3. So that would address the importing problem, if the modules I'm importing use the precompilation system. How is string performance doing?
    - jernfrost 10y ago
      A LOT has happened since then. For such a young language which hasn't even reached version 1.0 yet you can expect a lot of changes still. You should seriously try out Julia again. I think it really works well now. I used to have a lot of issues with it before. Stuff would break, slow startup times etc. Today I don't really have any complaints. Ok I got a few small ones. The limits on the ability to redefine stuff as you develop in the REPL can be a bit cumbersome.
    - StefanKarpinski 10y ago
      0.3 was quite some time ago – string performance was certainly a problem back then (an acknowledged one). String performance on 0.6-alpha, released last week, is very good. It should now be at least as good as scripting languages that have traditionally focused on strings (Python, Ruby, Perl). There are a few more tricks we could do in the future that could make this even faster, but they involve a fair amount of GC trickery, so we'll have to see.
    - throwaway399 10y ago
      I also stopped using after 0.3 and tried it recently again to speed up some NLP code in Python3 and it hasn't been faster than Python3. Back then I didn't like the poor support for pyjulia, slow string processing, people using unicode symbols as variables, module import system, lack of libraries for more obscure NLP algos, and startup time. I know these aren't major issues for the core users of Julia, but these were my concerns. The way I wrote the current code in Python was abusing sets and dicts a lot to take advantage of those fast data structs. Rewriting in Julia was fun because it was different and because multiple dispatch is fun. However, it was roughly the same speed as Python. Ended up sprinkling some Cython on top of Python and resulted in 10x speedup. Didn't take much time to add types/pass pointers instead of strings to functions. I am not at all familiar with C++/Cython. I think even if they speed strings/dicts up by a lot, there seem to be lots of breaking changes between releases so I wouldn't try it for something big. I think if Julia is to succeed in the near future in the same way Python is successful for data science, it needs to be more usable for general tasks. Things like web servers, fast JSON parsing, maybe static binaries or easy parallelism. Basically, some more selling points. So far, for me personally Python is faster and easier to read for most of the things I write. At least given comparable amount of work.
pron 10y ago
I really like the language, and I've recently used Julia in a scientific computing project, but the experience leaves much to be desired (and I'm certain it will be improved). Startup time isn't the biggest problem, although it is nowhere near "comparable to the JVM". The JVM will start cold, load a Hello World application from a JAR, run it and shut down in 60-80ms. A Julia Hello World app would take at least a second, even when precompiled into a native executable. The biggest problem, IMO, is packaging and deployment. I used BuildExecutable, which works OK most of the time (although startup times are still slow), but it results in so many shared libraries, with no easy way to cull them. Without BuildExecutable, I couldn't even find documentation on how to deploy a Julia app as a self-contained program (even not precompiled, but in a way that doesn't require Julia to be installed on the user's machine).