I'm not sure what the state of AVX-512 codegen was in the CLR/JVM back in early 2017, but given that LLVM's was still in buggy early stages, I would guess that it was a WIP at best so performance was probably not ideal (we had to work quite hard to get decent quality code generation). On KNL, you're either running AVX512 all the time or you're pretty much dead in terms of performance.
I work in HPC, and, well, Java and C# are more or less irrelevant in that space. Well, there is a little bit of Java, some people are using things like Hadoop or Spark, but otherwise, no.
"Hard-core" computing is almost all C/C++/Fortran (and of course CUDA for GPU's etc.). Python and R are fairly popular, but in those cases (hopefully) most of the heavy lifting is done by library code (again, C/C++/Fortran, or increasingly CUDA via ML libraries such as tensorflow) rather than the interpreter. Julia is very promising in this space, as it offers a solution to the "two-language" problem. I'm hopeful for Julia to make more of an impact, but it's of course a slow process.
(There is a (tiny) bit of ASM, but that's more or less exclusively done for widely used performance-critical libraries like BLAS, or FFT, not for application code.)
Is Julia a JIT compiler? How is Julia different than Pypy or even the JVM? There is also the new GraalVM in the landscape.
I don't see the plus value in Julia compared to Python or Java. It will still be slower than C/C++, probably less portable, and all the legacy libraries have to be rewritten in Julia.
If Julia is only a new syntax, to me Python is already very simple. If Julia is a JIT compiler, why not participate to already available compilers?
Julia is still there, so I guess it adds value, but I don't know where to place that effort in the grand scheme of things.
Thsee questions pop up every time Julia comes on HN and have been answered time and again for example by Chris Rackauckas [1], at the end of the day there will always be pros and cons and people unwilling to change from languages they’re proficient at. Personally I’ve been using Julia for scientific computing for 4 years and I’m hooked.
This question implicitly presumes that language design doesn't matter—that you can just hook a JIT up to any language syntax and semantics and presto... it’s as fast as C. But it doesn't work like that. You can't just take an arbitrary language and "rub some LLVM on it" and make if fast. The dozens of failed efforts to speed up Python and R with LLVM and other JITs over the decades proves that the source language matters. (PyPy is the only one with any real success, and they had to give up on CPython ecosystem compatibility.) It's Python and R semantics that are the problem and this can't be fixed with a JIT. Java is much better in terms of performance, of course, but still has issues. (The lack of value types is a big one, for example; being forced to go through a VM runtime is another problem at the highest levels of performance demands.) Julia can be seen as an experiment which proves that if you design a high-level dynamic language from the start to be compiled and run efficiently, then you can do much better than you can by bolting a JIT onto an existing slow dynamic language after the fact.
Thank you for the detailed answer. Here's my feedback on some of the points :
> I don't see how you can put Python and Java in the same bag.
What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills.
> Who cares? 99.99% of HPC are Linux clusters anyway. And Julia runs on macOS and Linux, that cover the overwhelming majority of the concerned users.
But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM.
> and all the legacy libraries have to be rewritten in Julia.
If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm.
> But will Julia be able to output the necessary instructions for the future hardware accelerators, which could be totally different architectures? I'm thinking of all the new neural networks cores, the DSP, fpgas, and heterogeneous computing from different rival vendors. It seems Julia is deeply dependant of LLVM.
Yes. Watch HN in the next week or two for an announcement that may interest you ;).
> What I meant is that the trio Python/Java/C is ubiquitous for many people in both entreprises and scientific fields, from embedded to web servers. It allows for great reusability of codes and people's skills.
That's true. But it's also Academia's role to try (and fail or succeed) at developing and evaluating new solutions; and in the case of Julia, I have to concede I'm pretty excited to see where they will be going. The solution of mixing the ‶glue″ and the ‶high performances″ languages in a single one while still letting people call upon older C ABI libs is a little revolution in this context.
> If you have to reuse C and Fortran libraries, why not just use Python which can do the same, or even Lua, or Lisp. Python is already the defacto language to glue libraries together onto a higher level algorithm.
Because Julia is far faster, and because no GIL.
Of course, like in every other tech, what floats my boat doesn't necessarily floats your, so maybe for your usecase Python/Lisp/Lua/Ruby/... is better.
Tbh, I just don't see any usage of Java or C# on HPC systems. Python is used a bit but in embarrassingly parallel mode. Part of it might just be cultural/biases but it just isn't used, especially since there isn't much of a need to create and manage a complex software architecture that enterprise systems leverage.
