This was my suspicion - I imagine that over the last 50 years a lot of clever people have been striving very hard to make Fortran run as fast as possible, and unless everyone's missed something you're never really going to be able to beat them by much. It is encouraging to hear that Julia is structured in such a way that there's no *fundamental* reason it couldn't match its speed. And surely being able to throw together some code quickly, make a few plots and save them in an IJulia notebook and have it all still run fast must count for *something*. :)
On Wednesday, 4 June 2014 06:57:06 UTC+10, Stefan Karpinski 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] <javascript:>> > 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! >>> >>
