There was also this PR by Steven Johnson where the use of a macro/meta-programming capabilities allowed for a Julia version that beat out 2 other well-known C implementations (in Matlab and SciPy).
This point is crucial to me as I think over a longer-term horizon. Sure performance is king and there will always be a push to improve, but don't discount ease of use and a powerful language design, with features like meta-programming, which can lead to much easier development cycles and sometimes even winning the performance game. -Jacob On Tue, Jun 3, 2014 at 4:57 PM, Stefan Karpinski <[email protected]> wrote: > 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! >>> >>
