As evidence of my claims that Julia is technically capable of doing generic programming faster than you can do it in C, I offer Fateman benchmark times for various systems.
Julia 0.3 was released today and gives a nice speedup over 0.2, hence the better times for Julia. Fateman benchmark ================ Magma: 247s Pari/GP: 161s Sage: 135 s Bland (generic C + flint): 42s Nemo (Julia 0.3 + flint): 36s The Fateman benchmark for us is to precompute f = 1 + x + y + z + t; p = f^30; and then to time p*(p + 1); Whilst you can compute the Fateman benchmark faster than this with a special bignum structure and sparse distributed format for the polynomials, the point here is that the generic C version in Bland and the Julia version in Nemo both use flint's fmpz integer type, recursive dense format (!) and the same algorithms. Another benchmark, called the Pearce benchmark, which computes f = (x + y + 2z^2 + 3t^3 + 5u^5 + 1)^16; g = (u + t + 2z^2 + 3y^3 + 5x^5 + 1)^16; and then times f*g; dropped from 90s down to 72s. This is a sparse benchmark, but we are just using recursive dense representation. I claim it's possible for Julia to do better still. And I'm sure we'll see that in a later release. Bill. On Friday, 22 August 2014 02:12:04 UTC+2, Bill Hart wrote: > > I just found time to actually read the links posted by the OP on Graydon > Hoare's history of programming language development, culminating in Julia. > > Oh I wish I could write like that! The guy is clearly a genius of immense > proportions. > > I truly, truly wish that the computer algebra and number theoretic > communities were engaging people like this and leveraging their insight and > vision to the fullest. > > Bill. > > On Friday, 22 August 2014 01:19:22 UTC+2, Bill Hart wrote: >> >> Another thing that I think is terribly important is that the entire >> technology stack, LLVM, all its libraries and packages, its console, the >> IJulia web interface and Julia itself, all work out of the box on Windows >> 64, natively, not as a Cygwin app (they use MinGW64/MSYS2 to build Julia). >> >> And I've personally verified this. After some initial troubles due to the >> fact that flint.dll is not built correctly on Windows 64, Nemo works >> perfectly on Windows and from the IJulia interface running on my local >> Windows 64 machine. >> >> This doesn't solve any problems for Sage, as many mathematical libraries >> still don't natively support Windows 64 despite it being a decade old. But >> it is a significant feature of Julia (and of the Nemo project I am writing >> with Julia). >> >> Bill. >> >> On Friday, 22 August 2014 00:26:23 UTC+2, Bill Hart wrote: >>> >>> >>> >>> On Friday, 22 August 2014 00:08:20 UTC+2, Bill Hart wrote: >>>> >>>> >>>> >>>> My cursory look into Julia only poped out JIT stuff, not a real >>>>> complier... >>>>> >>>> >>>> Static compilation is coming to Julia. But not because it will speed >>>> things up. It already has all the speed of an optimising compiler at the >>>> console, as you type! >>>> >>> >>> I should qualify that. Technically, jit compilation and type inference >>> begin at the function boundary in Julia. So stuff you type at the top level >>> is not optimised. I think that is a mistake, as it's unnecessary. In the >>> language I was working on (using LLVM) type inference and optimisation >>> begin at the top level (which for me is a function). There is a small >>> runtime hit with global variables, but that is all. >>> >>> In particular, in the language I was working on, loops at the top level >>> are jit compiled. In Julia they are not. But it's almost irrelevant, except >>> when doing timing experiments to see how fast Julia really goes. You might >>> easily think to type a loop into the top level and time it and wonder what >>> all the fuss is about. Put that loop inside a function and you'll soon see. >>> >>> julia> function sumit(n::Int) >>> s = 0 >>> for i = 1:n >>> s += i >>> end >>> return s >>> end >>> sumit (generic function with 1 method) >>> >>> julia> @time sumit(1000000000) >>> elapsed time: 0.913325036 seconds (78060 bytes allocated) >>> 500000000500000000 >>> >>> Bill. >>> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
