As a general purpose language, I'd probably categorize Julia as fast, but not crazy fast. Numerical computing is definitely where most of the man hours have gone into development. As a general purpose language, Julia probably ends up at around the same place as C# (not as fast as C++, but still pretty respectable). That said, this is an area where the main thing Julia needs here is more optimization on some of the libraries that already exist, and some new libraries to extend the language's reach further. I don't think there's anything fundamental holding it back from getting closer to C++ performance in general computing. It uses the same compiler (LLVM), and it's pretty clear that you can get Julia to output the same assembly code. It's just a matter of having enough devs pushing ecosystem forward.
Re:Julia 1.6 addresses latency issues
by adgjlsfhk1 on Friday May 28, 2021 @03:28AM
(#27312645)
That's fair. That said, the fact that writing a BLAS implementation in a high level language seems like a favorable benchmark does kind of show my point that for numerical computing, Julia is really fast (especially for a high level language).
That seems to be very Julia-specific comparisons, which I'm sure will be oriented towards the use cases Julia has been designed for. I'm more interested in "neutral" benchmarks and more general-purpose computing areas.
> Furthermore, Julia has been used on some of the world's fastest super-computers (in the performance critical bits), which as far as I know isn't true of Swift/Kotlin/C#.
That's more a reflection of culture than performance though. Back when I worked with a bunch of data scientists they would happily run Python or R on our Spark cluster, consuming oodles of resources to do not very much, but balked at writing Scala, even though their code would have run much faster.