12 ms·

Is Julia Really Fast?

145 points by leephillips 5y ago

leephillips 5y ago
The author gives an example of a little function written in a generic way, and shows how JIT compilation specializes it at runtime into highly optimized machine code. It’s a wonderful example of how Julia’s JIT compiler works, and how it can lead to significant speedups over even C or Fortran code in some cases.
Bostonian 5y ago
At the Fortran Wiki http://fortranwiki.org/fortran/show/Articles http://fortranwiki.org/fortran/show/Articles there are links to benchmarks comparing Fortran to Julia and other languages. Looking at https://github.com/arturofburgos/Assessment-of-Programming-Languages-for-Computational-Numerical-Dynamics https://github.com/arturofburgos/Assessment-of-Programming-L... https://www.matecdev.com/posts/numpy-julia-fortran.html https://www.matecdev.com/posts/numpy-julia-fortran.html https://github.com/zyth0s/bench_density_gradient_wfn https://github.com/zyth0s/bench_density_gradient_wfn https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks people do find Julia to be faster than Python/Numpy, but it is not uniformly faster than Fortran. And Julia's start-up time should not be ignored. Quoting the last link, "In fact the whole Fortran benchmark (300 integrations) finishes roughly in the time it takes to startup a Julia session and import all required libraries (Julia 1.5.1)."
- dnautics 5y ago
  If youre actually doing HPC, say, on a cluster, the startup time will be amortized, or else, you're doing something wrong.
  - clavigne 5y ago
    why? I commonly do things like screen 10,000 molecules for some property by calling a Fortran program 10k time. If each run takes 60s of compute, the 10s boot from Julia (over the nfs disk) would be pretty significant. Using Julia in this case basically means having to rewrite all of the other programs into it and getting rid of eg snakemake or gnu parallel or any number of other very common HPC workflows. In fact I'd venture that doing a sequence of things many times is just as common an HPC workload than single jobs running for very long times.
    - hansvm 5y ago
      Is there any particular reason you wouldn't want to wrap that workload in a function/module/... and call it in a loop? Is the problem that your commonly used tools are exposed only as command line interfaces and not as libraries?
      - clavigne 5y ago
        Yeah that's what I mean. This is the case for both commercial software (eg Q-Chem) and free software. This is not to say that the boot time is always a problem, there are plenty of applications in which it doesn't matter at all (as you point out). However that's not always the case (by a long shot) which is why tools like GNU Parallel and snakemake exist.
    - oscardssmith 5y ago
      One reason to consider Julia for workflows like this is that it's been designed to improve reproducibility. Julia makes it really easy to distribute package state (through manifest.toml files), that make it easy to get exact copies of the package versions that the original author used.
      - snicker7 5y ago
        Guix/Nix does this better across many programming languages. Unlike language-specific package managers, Guix is fully recursively reproducible ("bootstrappable"). And Nix isn't terribly far behind, either. Julia itself is not even reproducible: https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/34753 https://github.com/JuliaLang/julia/issues/34753
        oscardssmith 5y ago
        Note that those issues are about deterministic performance, not results. Also guix and nix appear to be Unix only, which severely limit their use for Windows users. One of the places Julia really excels with reproducibility is inter OS, yes there are probably some bugs, but the ability to manage versions cross OS this easily is something I'm not aware of a good alternative for.
- jvanderbot 5y ago
  Thanks for this. Not sure why its dowdownvoted. Numbers are worth looking at.
- fathead_glacier 5y ago
  Comparing different metrics is not valid across all use cases. Counting startup time but excluding development time is disingenuous. Having used both Fortan and Julia the difference between development time is staggering. Different tools for different uses cases is the best way to put it.
- leephillips 5y ago
  I don’t think anyone is claiming that Julia is uniformly faster than well-written Fortran. But you can get comparable performance with code using a style that many people find easier to read, write, and reason about; and it’s interesting that sometimes this code does outperform optimized C or Fortran code. Startup time is much improved in recent Julia versions¹, but is certainly not negligible for short calculations. [1]https://lwn.net/Articles/856819/ https://lwn.net/Articles/856819/
  - jvanderbot 5y ago
    Yes, also the mentioned example's speedup (from TFA) was likely at least partially from the accessibility of Julia, making some ancillary optimization easier or almost accidental. You don't need to beat Fortran "at fortran'ing" (the innermost column oriented processing) to be overall faster. I am imagining without evidence.
    - eigenspace 5y ago
      While it certainly won’t always win, there are many documented cases where Julia beats Fortran at Fortranning, e.g. https://fortran-lang.discourse.group/t/simple-summation-8x-slower-than-in-julia/1171 https://fortran-lang.discourse.group/t/simple-summation-8x-s... https://discourse.julialang.org/t/i-just-decided-to-migrate-from-python-fortran-to-julia-as-julia-was-faster-in-my-test/61188 https://discourse.julialang.org/t/i-just-decided-to-migrate-...
- socialdemocrat 5y ago
  Of course it will not always beat Fortran, but don't think think it is damn impressive that a high level dynamic language with much higher productivity frequently matches or beats Fortran? That is a crazy achievement if you ask me. Real world systems today are going to use a lot of computing resources, such as clusters, GPUs, tensor processing units, multiple cores etc. In such a world, anything that makes that easy to deal with is going to have the performance edge in practice. Doesn't matter how fast a Fortran program would be in theory, if the Julia program is delivered years ahead of it.
Steve_Baker77 5y ago
sign in required
- jvanderbot 5y ago
  Not for me?
- arianon 5y ago
  Use Incognito Mode/Private Browsing if Medium is telling you that you ran out of free member-only stories.
  - cristoperb 5y ago
    You can also just delete your cookies for medium.com
- arjunbajaj 5y ago
  or you can try outline.com https://outline.com/R5kdau https://outline.com/R5kdau
jvanderbot 5y ago
So, the article does a bit of goalpost switching. OP provides an example of massive speedup for real applications, which I don't doubt, but constantly compares between Python ( which is fast only really when you dispatch to optimized C/C++ ) and C. "Unless you are a C/C++ wizard normal Python developers cannot fix or optimize big libraries like NumPy or TensorFlow. In Julia its users tend to contribute more to the libraries they use themselves." I am excited by Julia. It seems to have a good niche and community around it. It seems well suited for its job. That focus will probably make it better than more general alternatives in short order.
- cogman10 5y ago
  Well, further, python's performance problems tend to come from it's C/C++ interop. Python made a few mistakes early on that make JITing it really hard without making backwards incompatible concessions. Easy/Fast C interop is a blessing and a curse. Yes, you can do fast things from C with little overhead, but it also makes things like having a generational garbage collector or a JIT really hard.
  - eigenspace 5y ago
    I really don’t think that’s the problem with Python. The problem is that the actual semantics of the language make it so that if you did have a compiler, very very little could be assumed about a piece of code at compile time. Classes in Python are basically sparkling Dicts and their memory layout can change at any time so basically everything must be boxed. Anytime you write a simple loop, the runtime has to ask “okay, what am I looping over!” “what sort of object is this function inside the loop acting on?” “How big is this object?” “Where does it live in memory?”, etc. This is deeply baked into the semantics of the language, which is why only specific subsets of the Python language can actually be made blazing fast while retaining compatibility with Python semantics.
    - remexre 5y ago
      > Classes in Python are basically sparkling Dicts and their memory layout can change at any time so basically everything must be boxed. My understanding was that most JavaScript JITs solved this problem well using shapes.
lasagnaphil 5y ago
One of the gripes that I have with Julia is that if you write linear algebra code naively, you will have tons of unnecessary temporary allocations, while in Eigen (a C++ library) you can avoid most of these without sacrificing too much readability. (It even optimizes how to run matrix kernels on the fly!) Sure, you can rewrite your Julia code in C-style to remove those temporary allocations, but then the code becomes even less readable than what you can achieve in C++. Here's an example: https://ronanarraes.com/tutorials/julia/my-julia-workflow-readability-vs-performance/ https://ronanarraes.com/tutorials/julia/my-julia-workflow-re... The naive Julia version has unnecessary allocations and therefore is 23% slower than the optimized version: @inbounds for k = 2:60000 Pp .= Fk_1 * Pu * Fk_1' .+ Q K .= Pp * Hk' * pinv(R .+ Hk * Pp * Hk') aux1 .= I18 .- K * Hk Pu .= aux1 * Pp * aux1' .+ K * R * K' result[k] = tr(Pu) end In order for this loop to match the C++ version you need to use C-style functions: for k = 2:60000 # Pp = Fk_1 * Pu * Fk_1' + Q mul!(aux2, mul!(aux1, Fk_1, Pu), Fk_1') @. Pp = aux2 + Q # K = Pp * Hk' * pinv(R + Hk * Pp * Hk') mul!(aux4, Hk, mul!(aux3, Pp, Hk')) mul!(K, aux3, pinv(R + aux4)) # Pu = (I - K * Hk) * Pp * (I - K * Hk)' + K * R * K' mul!(aux1, K, Hk) @. aux2 = I18 - aux1 mul!(aux6, mul!(aux5, aux2, Pp), aux2') mul!(aux5, mul!(aux3, K, R), K') @. Pu = aux6 + aux5 result[k] = tr(Pu) end ... which is quite dirty. But you can write the same thing in C++ like this (and even be a bit faster than Julia!): for(int k = 2; k <= 60000; k++) { Pp = Fk_1*Pu*Fk_1.transpose() + Q; aux1 = R + Hk*Pp*Hk.transpose(); pinv = aux1.completeOrthogonalDecomposition().pseudoInverse(); K = Pp*Hk.transpose()*pinv; aux2 = I18 - K*Hk; Pu = aux2*Pp*aux2.transpose() + K*R*K.transpose(); result[k-1] = Pu.trace(); } which is much more readable than Julia's optimized version. If Julia had a linear-algebra-aware optimizing compiler (without the sheer madness of C++ template meta-programming that Eigen uses), then Julia's standing in HPC would be much, much better. I admit that it's a hard goal to achieve, since I haven't seen any language trying this (the closest I've seen is LLVM's matrix intrinsics (https://clang.llvm.org/docs/MatrixTypes.html https://clang.llvm.org/docs/MatrixTypes.html), but it's only a proposal)
- deleted 5y ago
  [deleted]
plafl 5y ago
I'm extremely happy with Julia performance. I'm using it right now to prototype some new algorithms for my PhD. How fast is fast? Well in my case I'm trying to come up with things related to collision detection and I'm getting <30ns using SAT between OBBs (Oriented Bounding Boxes) and <300ns for minimum distance computation using the GJK algorithm again between OBBs. In the context of recommender systems I did an experiment when I started learning Julia comparing against Cython and wrote about it, although I was a newbie and I should update it: https://plopezadeva.com/julia-first-impressions.html https://plopezadeva.com/julia-first-impressions.html
dandanua 5y ago
If only Julia had a fluent static compilation it would be in the top 10 of languages. It's too bad there are not so much investment into a really important stuff that will benefit the world. All the investment goes to bubbles and financial pyramids.
- cbkeller 5y ago
  I hope it'll get there! If anyone wants to help out, check out (e.g.) https://github.com/tshort/StaticCompiler.jl/pull/46 https://github.com/tshort/StaticCompiler.jl/pull/46
- socialdemocrat 5y ago
  If PackageCompiler.jl was more polished you mean?
anon321321323 5y ago
Julia is faster than python for what I've done so far, so yes. I actually prefer Elixir but I use both.
- canadianfella 5y ago
  Faster than Python doesn’t mean fast.
- jnxx 5y ago
  Well, Common Lisp or Racket are a lot faster than Python, too, and both are general-purpose languages which has many advantages over a language specific for numerical computing.
  - dTal 5y ago
    Like what advantages? Julia is a "general purpose language" too, every bit as much as any of those other languages. It all boils down to the availability of polished utility libraries, and I don't exactly think Common Lisp or Racket have an indisputable edge there.
  - socialdemocrat 5y ago
    I don't get this argument. Maybe you could elaborate. I tried for a long time to get used to Racket. I really like the idea of LISP. The reason why I started using Julia wasn't because it was good at numerical programming. I was because it was a much better GENERAL PURPOSE programming language than Racket. Unless you do a lot of meta programming stuff, I don't find Racket to be advantageous to use. Julia syntax is much friendlier towards general-purpose programming. It is easier to do mathematics as well as string manipulation with Julia. Multiple dispatch also makes it a lot easier to write code. Getting into the LISP heavy thinking of Racket is harder than jumping onboard Julia. I find that I have been able to learn functional programming, meta programming and other things that make LISP/Scheme famous in Julia than I ever managed in Racket.
effnorwood 5y ago
depends on who is chasing her
streamofdigits 5y ago
If julia could become a native vector/gpu programming language that is usable by mere mortals this could be a niche that might eventually grow into mainstream. But I can't help but notice that e.g. nvidia's github mentions only: Python, C++, C, Go, Cuda. (not sure the order matters).
- eigenspace 5y ago
  Julia has excellent CUDA support[1], I have no idea why nvidia doesn't promote it more. It's fast, flexible and very featureful. There was a recent thread about it here: https://news.ycombinator.com/item?id=27496679 https://news.ycombinator.com/item?id=27496679 The AMD [2] and Intel [3] support is younger, but developing quickly. There's also [4] for a unified API that works across different GPU vendors to avoid lockin [1] https://cuda.juliagpu.org/dev/ https://cuda.juliagpu.org/dev/ [2] https://github.com/JuliaGPU/AMDGPU.jl https://github.com/JuliaGPU/AMDGPU.jl [3] https://github.com/JuliaGPU/oneAPI.jl https://github.com/JuliaGPU/oneAPI.jl [4] https://github.com/JuliaGPU/KernelAbstractions.jl https://github.com/JuliaGPU/KernelAbstractions.jl

145 points by leephillips 5y ago

The author gives an example of a little function written in a generic way, and shows how JIT compilation specializes it at runtime into highly optimized machine code. It’s a wonderful example of how Julia’s JIT compiler works, and how it can lead to significant speedups over even C or Fortran code in some cases.

Bostonian 5y ago

At the Fortran Wiki http://fortranwiki.org/fortran/show/Articles http://fortranwiki.org/fortran/show/Articles there are links to benchmarks comparing Fortran to Julia and other languages. Looking at https://github.com/arturofburgos/Assessment-of-Programming-Languages-for-Computational-Numerical-Dynamics https://github.com/arturofburgos/Assessment-of-Programming-L... https://www.matecdev.com/posts/numpy-julia-fortran.html https://www.matecdev.com/posts/numpy-julia-fortran.html https://github.com/zyth0s/bench_density_gradient_wfn https://github.com/zyth0s/bench_density_gradient_wfn https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks https://github.com/PIK-ICoNe/NetworkDynamicsBenchmarks people do find Julia to be faster than Python/Numpy, but it is not uniformly faster than Fortran. And Julia's start-up time should not be ignored. Quoting the last link, "In fact the whole Fortran benchmark (300 integrations) finishes roughly in the time it takes to startup a Julia session and import all required libraries (Julia 1.5.1)."

dnautics 5y ago
If youre actually doing HPC, say, on a cluster, the startup time will be amortized, or else, you're doing something wrong.
- clavigne 5y ago
  why? I commonly do things like screen 10,000 molecules for some property by calling a Fortran program 10k time. If each run takes 60s of compute, the 10s boot from Julia (over the nfs disk) would be pretty significant. Using Julia in this case basically means having to rewrite all of the other programs into it and getting rid of eg snakemake or gnu parallel or any number of other very common HPC workflows. In fact I'd venture that doing a sequence of things many times is just as common an HPC workload than single jobs running for very long times.
  - hansvm 5y ago
    Is there any particular reason you wouldn't want to wrap that workload in a function/module/... and call it in a loop? Is the problem that your commonly used tools are exposed only as command line interfaces and not as libraries?
    - clavigne 5y ago
      Yeah that's what I mean. This is the case for both commercial software (eg Q-Chem) and free software. This is not to say that the boot time is always a problem, there are plenty of applications in which it doesn't matter at all (as you point out). However that's not always the case (by a long shot) which is why tools like GNU Parallel and snakemake exist.
  - oscardssmith 5y ago
    One reason to consider Julia for workflows like this is that it's been designed to improve reproducibility. Julia makes it really easy to distribute package state (through manifest.toml files), that make it easy to get exact copies of the package versions that the original author used.
    - snicker7 5y ago
      Guix/Nix does this better across many programming languages. Unlike language-specific package managers, Guix is fully recursively reproducible ("bootstrappable"). And Nix isn't terribly far behind, either. Julia itself is not even reproducible: https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/25900 https://github.com/JuliaLang/julia/issues/34753 https://github.com/JuliaLang/julia/issues/34753
      - oscardssmith 5y ago
        Note that those issues are about deterministic performance, not results. Also guix and nix appear to be Unix only, which severely limit their use for Windows users. One of the places Julia really excels with reproducibility is inter OS, yes there are probably some bugs, but the ability to manage versions cross OS this easily is something I'm not aware of a good alternative for.
jvanderbot 5y ago
Thanks for this. Not sure why its dowdownvoted. Numbers are worth looking at.
fathead_glacier 5y ago
Comparing different metrics is not valid across all use cases. Counting startup time but excluding development time is disingenuous. Having used both Fortan and Julia the difference between development time is staggering. Different tools for different uses cases is the best way to put it.
leephillips 5y ago
I don’t think anyone is claiming that Julia is uniformly faster than well-written Fortran. But you can get comparable performance with code using a style that many people find easier to read, write, and reason about; and it’s interesting that sometimes this code does outperform optimized C or Fortran code. Startup time is much improved in recent Julia versions¹, but is certainly not negligible for short calculations. [1]https://lwn.net/Articles/856819/ https://lwn.net/Articles/856819/
- jvanderbot 5y ago
  Yes, also the mentioned example's speedup (from TFA) was likely at least partially from the accessibility of Julia, making some ancillary optimization easier or almost accidental. You don't need to beat Fortran "at fortran'ing" (the innermost column oriented processing) to be overall faster. I am imagining without evidence.
  - eigenspace 5y ago
    While it certainly won’t always win, there are many documented cases where Julia beats Fortran at Fortranning, e.g. https://fortran-lang.discourse.group/t/simple-summation-8x-slower-than-in-julia/1171 https://fortran-lang.discourse.group/t/simple-summation-8x-s... https://discourse.julialang.org/t/i-just-decided-to-migrate-from-python-fortran-to-julia-as-julia-was-faster-in-my-test/61188 https://discourse.julialang.org/t/i-just-decided-to-migrate-...
socialdemocrat 5y ago
Of course it will not always beat Fortran, but don't think think it is damn impressive that a high level dynamic language with much higher productivity frequently matches or beats Fortran? That is a crazy achievement if you ask me. Real world systems today are going to use a lot of computing resources, such as clusters, GPUs, tensor processing units, multiple cores etc. In such a world, anything that makes that easy to deal with is going to have the performance edge in practice. Doesn't matter how fast a Fortran program would be in theory, if the Julia program is delivered years ahead of it.

Steve_Baker77 5y ago

jvanderbot 5y ago
Not for me?
arianon 5y ago
Use Incognito Mode/Private Browsing if Medium is telling you that you ran out of free member-only stories.
- cristoperb 5y ago
  You can also just delete your cookies for medium.com
arjunbajaj 5y ago
or you can try outline.com https://outline.com/R5kdau https://outline.com/R5kdau

jvanderbot 5y ago

So, the article does a bit of goalpost switching. OP provides an example of massive speedup for real applications, which I don't doubt, but constantly compares between Python ( which is fast only really when you dispatch to optimized C/C++ ) and C. "Unless you are a C/C++ wizard normal Python developers cannot fix or optimize big libraries like NumPy or TensorFlow. In Julia its users tend to contribute more to the libraries they use themselves." I am excited by Julia. It seems to have a good niche and community around it. It seems well suited for its job. That focus will probably make it better than more general alternatives in short order.

cogman10 5y ago
Well, further, python's performance problems tend to come from it's C/C++ interop. Python made a few mistakes early on that make JITing it really hard without making backwards incompatible concessions. Easy/Fast C interop is a blessing and a curse. Yes, you can do fast things from C with little overhead, but it also makes things like having a generational garbage collector or a JIT really hard.
- eigenspace 5y ago
  I really don’t think that’s the problem with Python. The problem is that the actual semantics of the language make it so that if you did have a compiler, very very little could be assumed about a piece of code at compile time. Classes in Python are basically sparkling Dicts and their memory layout can change at any time so basically everything must be boxed. Anytime you write a simple loop, the runtime has to ask “okay, what am I looping over!” “what sort of object is this function inside the loop acting on?” “How big is this object?” “Where does it live in memory?”, etc. This is deeply baked into the semantics of the language, which is why only specific subsets of the Python language can actually be made blazing fast while retaining compatibility with Python semantics.
  - remexre 5y ago
    > Classes in Python are basically sparkling Dicts and their memory layout can change at any time so basically everything must be boxed. My understanding was that most JavaScript JITs solved this problem well using shapes.

lasagnaphil 5y ago

One of the gripes that I have with Julia is that if you write linear algebra code naively, you will have tons of unnecessary temporary allocations, while in Eigen (a C++ library) you can avoid most of these without sacrificing too much readability. (It even optimizes how to run matrix kernels on the fly!) Sure, you can rewrite your Julia code in C-style to remove those temporary allocations, but then the code becomes even less readable than what you can achieve in C++. Here's an example: https://ronanarraes.com/tutorials/julia/my-julia-workflow-readability-vs-performance/ https://ronanarraes.com/tutorials/julia/my-julia-workflow-re... The naive Julia version has unnecessary allocations and therefore is 23% slower than the optimized version: @inbounds for k = 2:60000 Pp .= Fk_1 * Pu * Fk_1' .+ Q K .= Pp * Hk' * pinv(R .+ Hk * Pp * Hk') aux1 .= I18 .- K * Hk Pu .= aux1 * Pp * aux1' .+ K * R * K' result[k] = tr(Pu) end In order for this loop to match the C++ version you need to use C-style functions: for k = 2:60000 # Pp = Fk_1 * Pu * Fk_1' + Q mul!(aux2, mul!(aux1, Fk_1, Pu), Fk_1') @. Pp = aux2 + Q # K = Pp * Hk' * pinv(R + Hk * Pp * Hk') mul!(aux4, Hk, mul!(aux3, Pp, Hk')) mul!(K, aux3, pinv(R + aux4)) # Pu = (I - K * Hk) * Pp * (I - K * Hk)' + K * R * K' mul!(aux1, K, Hk) @. aux2 = I18 - aux1 mul!(aux6, mul!(aux5, aux2, Pp), aux2') mul!(aux5, mul!(aux3, K, R), K') @. Pu = aux6 + aux5 result[k] = tr(Pu) end ... which is quite dirty. But you can write the same thing in C++ like this (and even be a bit faster than Julia!): for(int k = 2; k <= 60000; k++) { Pp = Fk_1*Pu*Fk_1.transpose() + Q; aux1 = R + Hk*Pp*Hk.transpose(); pinv = aux1.completeOrthogonalDecomposition().pseudoInverse(); K = Pp*Hk.transpose()*pinv; aux2 = I18 - K*Hk; Pu = aux2*Pp*aux2.transpose() + K*R*K.transpose(); result[k-1] = Pu.trace(); } which is much more readable than Julia's optimized version. If Julia had a linear-algebra-aware optimizing compiler (without the sheer madness of C++ template meta-programming that Eigen uses), then Julia's standing in HPC would be much, much better. I admit that it's a hard goal to achieve, since I haven't seen any language trying this (the closest I've seen is LLVM's matrix intrinsics (https://clang.llvm.org/docs/MatrixTypes.html https://clang.llvm.org/docs/MatrixTypes.html), but it's only a proposal)

deleted 5y ago
[deleted]

plafl 5y ago

I'm extremely happy with Julia performance. I'm using it right now to prototype some new algorithms for my PhD. How fast is fast? Well in my case I'm trying to come up with things related to collision detection and I'm getting <30ns using SAT between OBBs (Oriented Bounding Boxes) and <300ns for minimum distance computation using the GJK algorithm again between OBBs. In the context of recommender systems I did an experiment when I started learning Julia comparing against Cython and wrote about it, although I was a newbie and I should update it: https://plopezadeva.com/julia-first-impressions.html https://plopezadeva.com/julia-first-impressions.html

dandanua 5y ago

If only Julia had a fluent static compilation it would be in the top 10 of languages. It's too bad there are not so much investment into a really important stuff that will benefit the world. All the investment goes to bubbles and financial pyramids.

cbkeller 5y ago
I hope it'll get there! If anyone wants to help out, check out (e.g.) https://github.com/tshort/StaticCompiler.jl/pull/46 https://github.com/tshort/StaticCompiler.jl/pull/46
socialdemocrat 5y ago
If PackageCompiler.jl was more polished you mean?

anon321321323 5y ago

Julia is faster than python for what I've done so far, so yes. I actually prefer Elixir but I use both.

canadianfella 5y ago
Faster than Python doesn’t mean fast.
jnxx 5y ago
Well, Common Lisp or Racket are a lot faster than Python, too, and both are general-purpose languages which has many advantages over a language specific for numerical computing.
- dTal 5y ago
  Like what advantages? Julia is a "general purpose language" too, every bit as much as any of those other languages. It all boils down to the availability of polished utility libraries, and I don't exactly think Common Lisp or Racket have an indisputable edge there.
- socialdemocrat 5y ago
  I don't get this argument. Maybe you could elaborate. I tried for a long time to get used to Racket. I really like the idea of LISP. The reason why I started using Julia wasn't because it was good at numerical programming. I was because it was a much better GENERAL PURPOSE programming language than Racket. Unless you do a lot of meta programming stuff, I don't find Racket to be advantageous to use. Julia syntax is much friendlier towards general-purpose programming. It is easier to do mathematics as well as string manipulation with Julia. Multiple dispatch also makes it a lot easier to write code. Getting into the LISP heavy thinking of Racket is harder than jumping onboard Julia. I find that I have been able to learn functional programming, meta programming and other things that make LISP/Scheme famous in Julia than I ever managed in Racket.

effnorwood 5y ago

depends on who is chasing her

streamofdigits 5y ago

If julia could become a native vector/gpu programming language that is usable by mere mortals this could be a niche that might eventually grow into mainstream. But I can't help but notice that e.g. nvidia's github mentions only: Python, C++, C, Go, Cuda. (not sure the order matters).

eigenspace 5y ago
Julia has excellent CUDA support[1], I have no idea why nvidia doesn't promote it more. It's fast, flexible and very featureful. There was a recent thread about it here: https://news.ycombinator.com/item?id=27496679 https://news.ycombinator.com/item?id=27496679 The AMD [2] and Intel [3] support is younger, but developing quickly. There's also [4] for a unified API that works across different GPU vendors to avoid lockin [1] https://cuda.juliagpu.org/dev/ https://cuda.juliagpu.org/dev/ [2] https://github.com/JuliaGPU/AMDGPU.jl https://github.com/JuliaGPU/AMDGPU.jl [3] https://github.com/JuliaGPU/oneAPI.jl https://github.com/JuliaGPU/oneAPI.jl [4] https://github.com/JuliaGPU/KernelAbstractions.jl https://github.com/JuliaGPU/KernelAbstractions.jl