This post interests me. I'll write something here to follow this post. The performance gap between normal code in Python and badly-written code in Julia is something I'd like to know too. As far as I know, Python interpret does some mysterious optimizations. For example `(x**2)**2` is 100x faster than `x**4`.
On Thursday, April 30, 2015 at 9:58:35 PM UTC+2, Páll Haraldsson wrote: > > > Hi, > > [As a best language is subjective, I'll put that aside for a moment.] > > Part I. > > The goal, as I understand, for Julia is at least within a factor of two of > C and already matching it mostly and long term beating that (and C++). > [What other goals are there? How about 0.4 now or even 1.0..?] > > While that is the goal as a language, you can write slow code in any > language and Julia makes that easier. :) [If I recall, Bezanson mentioned > it (the global "problem") as a feature, any change there?] > > > I've been following this forum for months and newbies hit the same issues. > But almost always without fail, Julia can be speed up (easily as Tim Holy > says). I'm thinking about the exceptions to that - are there any left? And > about the "first code slowness" (see Part II). > > Just recently the last two flaws of Julia that I could see where fixed: > Decimal floating point is in (I'll look into the 100x slowness, that is > probably to be expected of any language, still I think may be a > misunderstanding and/or I can do much better). And I understand the tuple > slowness has been fixed (that was really the only "core language" defect). > The former wasn't a performance problem (mostly a non existence problem and > correctness one (where needed)..). > > > Still we see threads like this one recent one: > > https://groups.google.com/forum/#!topic/julia-users/-bx9xIfsHHw > "It seems changing the order of nested loops also helps" > > Obviously Julia can't beat assembly but really C/Fortran is already close > enough (within a small factor). The above row vs. column major (caching > effects in general) can kill performance in all languages. Putting that > newbie mistake aside, is there any reason Julia can be within a small > factor of assembly (or C) in all cases already? > > > Part II. > > Except for caching issues, I still want the most newbie code or > intentionally brain-damaged code to run faster than at least > Python/scripting/interpreted languages. > > Potential problems (that I think are solved or at least not problems in > theory): > > 1. I know Any kills performance. Still, isn't that the default in Python > (and Ruby, Perl?)? Is there a good reason Julia can't be faster than at > least all the so-called scripting languages in all cases (excluding small > startup overhead, see below)? > > 2. The global issue, not sure if that slows other languages down, say > Python. Even if it doesn't, should Julia be slower than Python because of > global? > > 3. Garbage collection. I do not see that as a problem, incorrect? Mostly > performance variability ("[3D] games" - subject for another post, as I'm > not sure that is even a problem in theory..). Should reference counting > (Python) be faster? On the contrary, I think RC and even manual memory > management could be slower. > > 4. Concurrency, see nr. 3. GC may or may not have an issue with it. It can > be a problem, what about in Julia? There are concurrent GC algorithms > and/or real-time (just not in Julia). Other than GC is there any big > (potential) problem for concurrent/parallel? I know about the threads work > and new GC in 0.4. > > 5. Subarrays ("array slicing"?). Not really what I consider a problem, > compared to say C (and Python?). I know 0.4 did optimize it, but what > languages do similar stuff? Functional ones? > > 6. In theory, pure functional languages "should" be faster. Are they in > practice in many or any case? Julia has non-mutable state if needed but > maybe not as powerful? This seems a double-edged sword. I think Julia > designers intentionally chose mutable state to conserve memory. Pros and > cons? Mostly Pros for Julia? > > 7. Startup time. Python is faster and for say web use, or compared to PHP > could be an issue, but would be solved by not doing CGI-style web. How > good/fast is Julia/the libraries right now for say web use? At least for > long running programs (intended target of Julia) startup time is not an > issue. > > 8. MPI, do not know enough about it and parallel in general, seems you are > doing a good job. I at least think there is no inherent limitation. At > least Python is not in any way better for parallel/concurrent? > > 9. Autoparallel. Julia doesn't try to be, but could (be an addon?). Is > anyone doing really good and could outperform manual Julia? > > 10. Any other I'm missing? > > > Wouldn't any of the above or any you can think of be considered > performance bugs? I know for libraries you are very aggressive. I'm > thinking about Julia as a core language mostly, but maybe you are already > fastest already for most math stuff (if implemented at all)? > > > I know to get the best speed, 0.4 is needed. Still, (for the above) what > are the problems for 0.3? Have most of the fixed speed issues been > backported? Is Compat.jl needed (or have anything to do with speed?) I > think slicing and threads stuff (and global?) may be the only exceptions. > > Rust and some other languages also claim "no abstraction penalty" and > maybe also other desirable things (not for speed) that Julia doesn't have. > Good reason it/they might be faster or a good reason to prefer for > non-safety related? Still any good reason to choose Haskell or Erlang? I do > not know to much about Nim language that seems interesting but not clearly > better/faster. Possibly Rust (or Nim?) would be better if you really need > to avoid GC or for safety-critical. Would there be a best complementary > language to Julia? > > > Part III. > > Faster for developer time not CPU time. Seems to be.. (after a short > learning curve). This one is subjective, but any languages clearly better? > Right metric shouldn't really be to first code that seems right but > bug-free or proven code. I'll leave that aside and safe-critical issues. > > -- > Palli. > >
