7 ms·

Julia, I love you (2012)

• pav3l 14y ago
  Finally there are downloadable binaries for Windows and OSX! http://code.google.com/p/julialang/downloads/list http://code.google.com/p/julialang/downloads/list Also, previous discussion: http://news.ycombinator.com/item?id=3784349 http://news.ycombinator.com/item?id=3784349
  • simulate 14y ago
    There is also an IDE for Mac, Linux, and Windows available here: http://forio.com/julia/downloads http://forio.com/julia/downloads
• deleted 14y ago
  [deleted]
• carlob 14y ago
  Why do people think that computing Fibonacci numbers recursively is a good benchmark of anything? Doesn't it require O(n^2) function calls for something that can be computed in O(1)?
  • lukev 14y ago
    Actually being fast is not the point; naive fib is used because it's a very well known algorithm, easy to implement consistently across multiple languages, that heavily exercises both function calls and numeric addition. In other words, as much as a 10-line program can be, it's a reasonable proxy for a language's performance on algorithmic code.
    • baddox 14y ago
      Also, it's a reasonable low bar to begin with for a college-educated programmer (not that all programmers need to be college-educated), because the Fibonacci sequence in mathematics (and in everyday language) is commonly defined in its recursive form, so it's likely that people will be familiar with it.
  • Jabbles 14y ago
    It tests how well the compiler deals with function calls, and that's it. Useless for measuring a language's overall speed (as are all micro-benchmarks).
    • kragen 14y ago
      If the compiler deals with arithmetic in a very inefficient way, that will also show up.
  • codeflo 14y ago
    Note to self: If I ever implement a compiler, I'll include a special Fibonacci detection pass in the optimizer.
    • mjn 14y ago
      That kind of thing does happen when the stakes get high enough. There are a lot of rumors (and some evidence) of special-cased "cheating" on commonly used benchmarks, including the 3dMark GPU benchmarks, SPEC CPU benchmarks, even SunSpider JS benchmarks.
      • spitfire 14y ago
        Both Nvidia and ATI have been caught cheating at graphics benchmarks. Their drivers would detect when the benchmark programs were being run, and go through lower quality fast paths. You can google "quack.exe" for details on one particularly famous case.
    • lliiffee 14y ago
      Actually, it takes real effort to make GCC not completely optimize-away this kind of stuff for C: https://github.com/JuliaLang/julia/issues/1325 https://github.com/JuliaLang/julia/issues/1325
      • smosher 14y ago
        There's a simple solution to that: use Ackermann instead. It measures the same thing and is a function of its own time complexity to boot.
  • jules 14y ago
    It actually requires O(fib(n)) function calls, or equivalently about O(1.62^n) function calls.
  • mikeash 14y ago
    Fibonacci is O(log n) or so in the best case, not quite O(1). Of course you can do a simple table lookup if you're limiting yourself to 32 or 64-bit numbers, but you can go far beyond that.
    • carlob 14y ago
      Can't you do it in O(1) if you limit yourself to floats? Arbitrary n but not arbitrary precision?
      • mikeash 14y ago
        I imagine the table would still be of reasonable size then. Of course, this is still technically restricting the output to 32 or 64-bit numbers.
        • gamegoblin 14y ago
          No need for a table lookup. There is a closed form formula. Of course this is only as accurate as your float precision. You can get out pretty far, though, with some clever rounding. http://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression http://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_ex...
    • kragen 14y ago
      There's a formula from analysis that gives you the Nth Fibonacci number in closed form. It involves a couple of exponentials, which you can compute to a given accuracy in bounded time.
      • StefanKarpinski 14y ago
        You obviously haven't tried doing this or you wouldn't suggest this as a way to actually compute Fibonacci numbers. Here's a definition in Julia (hey, why not) of a closed form Fibonnaci function: cfib(n) = ((1+sqrt(5))^n - (1-sqrt(5))^n)/(2^n*sqrt(5)) Let's see how it works: julia> cfib(1) 1.0 julia> cfib(2) 1.0 julia> cfib(3) 2.0 Great! But let's look at a few more: julia> cfib(4) 3.0000000000000004 julia> cfib(5) 5.000000000000001 Oops. Those aren't integers. I guess we could round, but at some point we might be rounding to the wrong integer. In fact, once you get up to 63, this happens and worse still, at 64 you get an infinite answer. Here's a simple, reasonably efficient iterative Fibonacci function in Julia: function ifib(n) j, k = 1, 1 for l = 3:n j, k = k, j+k end return k end We know this one works up to the limits of Int64 range: julia> for n = 1:10 println(fib(n)) end 1 1 2 3 5 8 13 21 34 55 Using a doubly recursive algorithm for Fibonacci is indeed silly, but it's a good toy test of recursion performance.
  • dagw 14y ago
    Fibonacci numbers cannot be computed in O(1), only estimated. All closed form algorithms start giving imprecise answers after some value of n.
• deleted 14y ago
  [deleted]
• dhotson 14y ago
  I've just started learning Julia and I'm also loving it so far. It's really well designed with loads of great features (and decent libraries) for scientific computing.
• dylangs1030 14y ago
  I can understand the need for new programming languages to be continually developed, especially with differing power continuums. So I have nothing against this post, or Julia itself. But when someone advertises that they want x feature and y feature in one language, such that the respective languages of x and y are essentially obsolete, I get a little skeptical. I'm certainly not the type of person who tries to vaguely advocate all languages are more or less the same and it's just taste; not at all. But I think there are reasons why it's intrinsically difficult to design a language to have both the speed of C and the abstraction power of Lisp, for example. Things come at a price; this doesn't mean there isn't generally a clear victor for what you're trying to do, just that getting a paragon of linguistic design is very difficult. But his test of Julia is promising, though honestly I'd really like to see a speed comparison on at least 100 lines of code, preferably a full application really.
  • StefanKarpinski 14y ago
    Miles Lubin and Iain Dunning gave an excellent presentation at MIT's IAP tutorial on Julia in January where they benchmarked rather non-trival code for doing linear programming in a variety of languages: https://github.com/JuliaLang/julia-tutorial/blob/master/NumericalOptimization/presentation.pdf http://bit.ly/VQ9rDd (shortened version since that's cut off) See page 7, "Simplex Benchmarks". Essentially, they implemented the basics you need to do a fast simplex linear programming algorithm in each of C++, Julia, Matlab and Python. Their results were in line with the Julia home page benchmarks: Julia is between 1-2x slower than good C/C++ code. PyPy and Matlab are 10-20x slower. Python is 80-400x slower. The code can be found here: https://github.com/mlubin/SimplexBenchmarks These results are fairly typical.
    • dylangs1030 14y ago
      1-2x slower is still remarkable given what Julia (apparently) has the power to do. Thanks for the citations!
    • pygy_ 14y ago
      Remove the four spaces before the long URL, it will be properly displayed and linkified. Meanwhile: https://github.com/JuliaLang/julia-tutorial/blob/master/NumericalOptimization/presentation.pdf https://github.com/JuliaLang/julia-tutorial/blob/master/Nume... https://github.com/mlubin/SimplexBenchmarks https://github.com/mlubin/SimplexBenchmarks
• StefanKarpinski 14y ago
  This is a repost of a rather old blog entry. John Myles White has subsequently become one of Julia's most prolific core developers, having created and contributed a variety of very high quality stats and machine learning packages for (and in) Julia: https://github.com/johnmyleswhite/BloomFilters.jl https://github.com/johnmyleswhite/BloomFilters.jl https://github.com/johnmyleswhite/Calculus.jl https://github.com/johnmyleswhite/Calculus.jl https://github.com/johnmyleswhite/Clustering.jl https://github.com/johnmyleswhite/Clustering.jl https://github.com/HarlanH/DataFrames.jl https://github.com/HarlanH/DataFrames.jl https://github.com/johnmyleswhite/DimensionalityReduction.jl https://github.com/johnmyleswhite/DimensionalityReduction.jl https://github.com/JuliaStats/Distributions.jl https://github.com/JuliaStats/Distributions.jl https://github.com/johnmyleswhite/FileFind.jl https://github.com/johnmyleswhite/FileFind.jl https://github.com/JuliaStats/GLM.jl https://github.com/JuliaStats/GLM.jl https://github.com/johnmyleswhite/Graphs.jl https://github.com/johnmyleswhite/Graphs.jl https://github.com/johnmyleswhite/KLDivergence.jl https://github.com/johnmyleswhite/KLDivergence.jl https://github.com/JuliaStats/LM.jl https://github.com/JuliaStats/LM.jl https://github.com/johnmyleswhite/Languages.jl https://github.com/johnmyleswhite/Languages.jl https://github.com/johnmyleswhite/Loss.jl https://github.com/johnmyleswhite/Loss.jl https://github.com/doobwa/MCMC.jl https://github.com/doobwa/MCMC.jl https://github.com/johnmyleswhite/NHST.jl https://github.com/johnmyleswhite/NHST.jl https://github.com/johnmyleswhite/Optim.jl https://github.com/johnmyleswhite/Optim.jl https://github.com/johnmyleswhite/RDatasets.jl https://github.com/johnmyleswhite/RDatasets.jl https://github.com/johnmyleswhite/Resampling.jl https://github.com/johnmyleswhite/Resampling.jl https://github.com/johnmyleswhite/TextAnalysis.jl https://github.com/johnmyleswhite/TextAnalysis.jl https://github.com/johnmyleswhite/kNN.jl https://github.com/johnmyleswhite/kNN.jl The moral of the story might be that John puts his money where is mouth is. He thought Julia was awesome and now he's done a huge amount to make it even more so.
• EvanMiller 14y ago
  Julia's math library is starting to shape up: http://docs.julialang.org/en/latest/stdlib/base/#mathematical-functions http://docs.julialang.org/en/latest/stdlib/base/#mathematica... It even has a digamma, Riemann zeta, and Bessel functions with fractional orders, which you won't find in Excel. The statistics built-ins are a bit weak, however.
  • hammerbacher 14y ago
    What's missing from the statistics built-ins?
  • KenoFischer 14y ago
    Have you looked at the various statistics-related packages? We moved most of the statistics stuff (and may other areas as well) into packages.
• mynameishere 14y ago
  Lord knows there aren't enough Bobby Sherman references. http://www.youtube.com/watch?v=f7PLcHnMNKE http://www.youtube.com/watch?v=f7PLcHnMNKE
• nnq 14y ago
  Am I the only one with hopes of Julia actually evolving into a general purpose programming language? With almost C++ level performance and homoiconicity it seems really sweet and I'd love to see it used instead of Go. Though 1-indexed arrays are definitely annoying as fuck...
  • KenoFischer 14y ago
    Well, if you're feeling really sadistic baremodule MyWay ref(x::AbstractArray, i::Int) = Base.ref(x,i+1) ref(args...) = Base.ref(args...) end is not that far away (I'm oversimplifying a little, but not much). However, please don't do this as it breaks coherence within the community. I found 1-based indexes annoying at first, but have grown quite fond of them since.
    • nnq 14y ago
      yeah, having mixed 1-indexes and 0-indexes code would be 10x worse than just getting used to 1-based, so hope people don't do that :)
  • snogglethorpe 14y ago
    1-based arrays are one of the more lambasted traits of Lua (an otherwise supremely elegant language), and as a long-time C/C++ programmer, I personally find 0-based arrays very natural. However what I've found from doing lots of Lua programming, is that I just don't notice very much in practice. To some degree, at least, I guess this reflects that one writes different sorts of code in different programming languages. The sort of offset-based address calculations one might do a lot in C just don't seem to happen very much in Lua. So while my natural inclination is to dislike 1-based arrays, I no longer consider them an automatic demerit....
    • davidw 14y ago
      Erlang has 1-based lists as well.
      • 14y ago
• mrothe 14y ago
  I don't think many projects with such a horrible() distribution system succeeded in the past. ()horrible for package maintainers. Try to create a package from this... There are no releases. I don't see any use of DESTDIR. And bundled libraries are also a major setback. It seems like the developers want to make it as hard as possible to distribute their software. And I see more and more software going this direction. :(
  • pygy_ 14y ago
    Up to this point, the language and standard library was in flux, hence the perpetual v0.0.0. v0.1 is around the corner, though, so, hopefully, things will start to stabilize.
• zvrba 14y ago
  Wow, the list of modules has gotten very respectable since the first time I heard about Julia. I have one concern though: how well-tested are they? There's one really prominent contributor (John Myles White), who has written a rather large number of packages. But there are only a limited number of bug-free LOCs that a human can write in a given time-span. So Julia might well be a better language than R, but is it standard library as reliable? And how much time will it take until it becomes as trusted as that of R?
• sandGorgon 14y ago
  Can anyone venture a guess on how successful this will be ? Given that R is pretty widespread right now, and Scipy/Numpy/Blaze is looking to win in the future (with the Darpa funding for Continuum[1]). Wonder if Julia was considered for the Darpa grant. [1] http://www.itworld.com/big-data/340570/python-gets-big-data-boost-darpa http://www.itworld.com/big-data/340570/python-gets-big-data-...
• ww2 14y ago
  Julia's benchmarks just turned me off. They are ignoring the "reasonable idioms" of each language, and specifically focusing only on RECURSIVE and ITERATIVE algos. And also ignoring other competing peers like lua based GSL Shell. Please read https://groups.google.com/forum/#!topic/julia-dev/2MJQ_uADH40 https://groups.google.com/forum/#!topic/julia-dev/2MJQ_uADH4...
  • ihnorton 14y ago
    > Julia's benchmarks just turned me off. They are ignoring the "reasonable idioms" of each language, specifically focusing only on RECURSIVE and ITERATIVE algos. I read the benchmarks as an invitation to experiment (which I am) - not as a call to language war; if it doesn't float your boat, then that's cool (but you might want to check it out again in a year or two). Your concerns are specifically addressed on the front page in the benchmark discussion (http://julialang.org http://julialang.org): "These benchmarks, while not comprehensive, do test compiler performance on a range of common code patterns, such as function calls, string parsing, sorting, numerical loops, random number generation, and array operations. It is important to note that these benchmark implementations are not written for absolute maximal performance (the fastest code to compute fib(20) is the constant literal 6765). Rather, all of the benchmarks are written to test the performance of specific algorithms, expressed in a reasonable idiom in each language. ... The point of these benchmarks is to compare the performance of specific algorithms across language implementations, not to compare the fastest means of computing a result, which in most high-level languages relies on calling C code." We all know C compilers make fast machine code, so it seems kind of silly to tediously write apple-oranges benchmarks in ways which will usually just end up benchmarking language X FFI anyway. Excepting BLAS stuff (as noted) pure Julia is within 2x of C, and that is really the take-home message of the benchmarks. Here's why these small, hot-point benchmarks matter: the reasonable idiom in Julia is to rewrite slow algorithms in the same language. See this recent contribution for a great example of what is possible: https://github.com/lindahua/Devectorize.jl https://github.com/lindahua/Devectorize.jl This combination of meta-programming expressiveness with speed in one language is really quite profound. Among other things, I think it will go a long way towards reducing the impedance-mismatch between "C core developers" and "end-user" communities in other technical computing environments (see NumPy,R). Julia has a beautiful, small, and stunningly accessible language implementation in C (isolated C++ for LLVM stuff); and it is certainly pragmatic by using BLAS,FFTW, etc. where appropriate --- but the numerical core is defined in Julia itself, and - IMHO - that is a very fundamental shift for building an open-source computing environment and community. (LuaJIT is a masterpiece and it would be cool to see it in the benchmarks, but there are many reasons why I personally have no interest in numerical work using Lua)