I certainly hope that we'll be able to close the gap and match C and Fortran in the future – there's really nothing standing in the way of this. Beating C/Fortran is a different thing entirely and less likely – largely because if you can do something to make your code go faster then it can also be done in C/Fortran. However, there may be certain cases where we can actually beat at least the straightforward thing in more static languages by jitting specialized code at runtime. A good example is Julia's sorting, which is generic yet doesn't pay the indirection cost of C's void* qsort. Of course, using templates in C++ can also get you specialization without void*/function call overhead. And you can, of course, use LLVM from C to generate custom code so there's a sense in which you literally cannot beat C.
On Tuesday, June 3, 2014, Tony Kelman <[email protected]> wrote: > Thomas, > > I think the medium-long term goal is to bring those 1.5-2 comparisons > closer to 1-1.2. If you can share some of your own benchmarks, often people > will be able to point out refactoring tweaks you can make to further > improve things, especially wrt memory allocation. Beating Fortran in serial > for pure numerical calculations is challenging. The compilers for Fortran > (are you using GNU, Intel, something else?) often perform more > sophisticated optimizations that can't always be matched by LLVM, > especially not in a JIT setting. It's taken some time even for Clang to get > close to runtime performance parity with GCC for C/C++. Eventually "static" > compilation of Julia code will hopefully be possible with a more expensive > set of LLVM and code generation optimizations enabled for use cases like > yours. > > When you're within a factor of 2 trying to wring that last bit of > performance out, and your benchmark is Fortran, it's time to start looking > at SIMD vectorization, parallelism, and what kind of hardware your code is > running on. AFAIK Fortran compilers are pretty good at auto-vectorizing for > SSE, AVX, etc but perhaps Julia and LLVM can make these more accessible and > easier to control. Is your code running in serial, or multithreaded with > OpenMP, or on a distributed cluster with MPI? I'm not sure what's the > largest HPC-class system people have run Julia on yet. > > -Tony > > > On Tuesday, June 3, 2014 2:25:19 AM UTC-7, Thomas Moore wrote: >> >> Julia is still a very young language, and it's common to hear people >> talking of hoped for improvements in the compiler which will further speed >> up the language. According to the current benchmarks, Julia is consistently >> (and incredibly!) within a factor 1.5-2 or Fortran's speed, and this is >> consistent with my observations. I'm wondering if anyone has any idea of >> how much we can realistically expect this to improve? Are there any >> fundamental barriers which will prevent Julia catching up or even >> overtaking Fortran on the raw speed front? >> >> I ask as I'm currently doing some work in numerical simulations, where we >> run experiments whose run-time is measured in weeks. For this work, Julia >> running slower by a factor of 1.5 or 2 is not really tolerable. >> >> Thanks! >> >
