Don't apologize; instead, tell us more about what Go does, and how you think things can be better. Those of us who don't know Go will thank you for it.
Best, --Tim On Thursday, April 30, 2015 09:42:47 PM Harry B 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 > > > > > > > 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.
