Yes, there is a non-trivial area where it's *possible* to do something really clever and fast in C/Fortran but so annoying that no one ever actually does it. Having macros and jit can make these things convenient, thereby making it possible for mere mortals to benefit from these kinds of tricks.
On Tuesday, June 3, 2014, Jacob Quinn <[email protected]> wrote: > 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] > <javascript:_e(%7B%7D,'cvml','[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] >> <javascript:_e(%7B%7D,'cvml','[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! >>>> >>> >
