It is true that we have not yet done enough to optimize the worst and worse performance cases. The bright side of that is that we have room to improve; it's not that we've run out of ideas and techniques.
Tim is right that the complexity of our dispatch system makes julia potentially slower than python. But in dispatch-heavy code I've seen cases where we are faster or slower; it depends. Python's string and dictionary operations, in particular, are really fast. This is not surprising considering what the language was designed for, and that they have a big library of well-tuned C code for these things. I still maintain that it is misleading to describe an *asymptotic* slowdown as "800x slower". If you name a constant factor, it sounds like you're talking about a constant factor slowdown. But the number is arbitrary, because it depends on data size. In theory, of course, an asymptotic slowdown is *much worse* than a constant factor slowdown. However in the systems world constant factors are often more important, and are often what we talk about. You say "a lot of the algorithms are O(n) instead of O(1)". Are there any examples other than length()? I disagree that UTF-8 has no space savings over UTF-32 when using the full range of unicode. The reason is that strings often have only a small percentage of non-BMP characters, with lots of spaces and newlines etc. You don't want your whole file to use 4x the space just to use one emoji. On Fri, May 1, 2015 at 12:42 AM, Harry B <[email protected]> wrote: > Sorry my comment wasn't well thought out and a bit off topic. On > exceptions/errors my issue is this > https://github.com/JuliaLang/julia/issues/7026 > On profiling, I was comparing to Go, but again off topic and I take my > comment back. I don't have any intelligent remarks to add (yet!) :) > Thank you for the all the work you are doing. > > On Thursday, April 30, 2015 at 7:00:01 PM UTC-7, Tim Holy wrote: >> >> Harry, I'm curious about 2 of your 3 last points: >> >> On Thursday, April 30, 2015 05:50:15 PM Harry B wrote: >> > (exceptions?, debugging, profiling tools) >> >> We have exceptions. What aspect are you referring to? >> Debugger: yes, that's missing, and it's a huge gap. >> Profiling tools: in my view we're doing OK (better than Matlab, in my >> opinion), >> but what do you see as missing? >> >> --Tim >> >> > >> > Thanks >> > -- >> > Harry >> > >> > On Thursday, April 30, 2015 at 3:43:36 PM UTC-7, Páll Haraldsson wrote: >> > > It seemed to me tuples where slow because of Any used. I understand >> > > tuples >> > > have been fixed, I'm not sure how. >> > > >> > > I do not remember the post/all the details. Yes, tuples where slow/er >> > > than >> > > Python. Maybe it was Dict, isn't that kind of a tuple? Now we have >> > > Pair in >> > > 0.4. I do not have 0.4, maybe I should bite the bullet and install.. >> > > I'm >> > > not doing anything production related and trying things out and using >> > > 0.3[.5] to avoid stability problems.. Then I can't judge the speed.. >> > > >> > > Another potential issue I saw with tuples (maybe that is not a problem >> > > in >> > > general, and I do not know that languages do this) is that they can >> > > take a >> > > lot of memory (to copy around). I was thinking, maybe they should do >> > > similar to databases, only use a fixed amount of memory (a "page") >> > > with a >> > > pointer to overflow data.. >> > > >> > > 2015-04-30 22:13 GMT+00:00 Ali Rezaee <[email protected] >> > > <javascript:>>: >> > >> They were interesting questions. >> > >> I would also like to know why poorly written Julia code >> > >> sometimes performs worse than similar python code, especially when >> > >> tuples >> > >> are involved. Did you say it was fixed? >> > >> >> > >> 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. >> >
