On Mon, Aug 17, 2009 at 2:10 AM, Bill Hart<goodwillh...@googlemail.com> wrote: > > 2009/8/17 William Stein <wst...@gmail.com>: >> >> On Mon, Aug 17, 2009 at 1:17 AM, Bill Hart<goodwillh...@googlemail.com> >> wrote: >>> Actually Python is often vastly slower than Lisp. It is very rarely >>> faster. The point of python is most certainly not its speed. It is >>> ease of use, through and through. The whole language was designed with >>> that in mind. >>> >>> Of course the speed problem becomes much less of a problem when you >>> can link in libraries written in C, assembler and Cython of course >>> (which compiles to C++ and fairly closely approximates it). >> >> Yep. Here's a very good chart showing SBCL Lisp being faster than >> Python on nearly every single programming challenge: >> >> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=sbcl&box=1 >> >> However, I think the table shows that the corresponding Lisp >> programmers are all much longer, and less memory efficient. >> >> Of course, if I were implementing any of those time critical >> programming challenges for Sage, I would use Cython, which is the same >> speed as C (since one can paste in any C program, with minor >> modifications). The corresponding table is >> >> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gcc&lang2=sbcl&box=1 >> >> where C is between 1 and 4 times faster than Lisp at every single benchmark. >> >> When you're trying to write code that is "faster than Magma", a factor >> of 4 matters a *huge* amount. >> >>>> Yep, those are probably some of the reasons for Python being popular. >>>> >>>>>> It has not been >>>>>> done because of a (valid) design decision to keep the syntax as close >>>>>> to python as possible (the Sage preprocessor does almost nothing). >>>>> >>>>> If it were a good decision, I think one would not have to write mpz_s >>>>> so much. >>>> >>> >>> I wonder if William only included Cython and Python files in his >>> count, or whether he also included all the compiled Cython files and >>> perhaps even the C libraries. There's only about 100 uses of mpz_add >>> across the whole of Sage in Python and Cython code. That actually >>> really surprises me, because it is so low. >> >> I just did "sage -grep", which includes everything not autogenerated >> under devel/sage/sage/, which is everything the Sage developers wrote. >> This also includes all of the official interface/header files. So, >> e.g., every single mpz_ function in all of GMP is listed in one of >> those header files, and contributes to the count. >> >>> >>>> What is wrong with writing code that uses the GMP library directly? >>>> The GMP library API is clean, mature, explicit, well thought out, >>>> offers hundreds of useful functions, is stable, and code written than >>>> uses it is often straightforward to read and understand, and is very >>>> fast. Many programmers like writing tight "inner loop" code that >>>> has to be fast against the GMP API. I *like* GMP. >>>> >>> >>> As far as I can tell, Maxima doesn't even use GMP. It must be dog slow >>> for multiprecision arithmetic. GMP and MPIR have sped up by about a >>> factor of 2 in the last year and the speed increases have been going >>> like that for years in GMP. How does maxima handle multiprecision >>> arithmetic? Or does it just do everything to single precision? >> >> The multiprecision arithmetic that Maxima uses is determined by the >> underlying lisp. When Sage used clisp, it didn't use MPIR, and was >> dog slow for large integer arithmetic. One of the technical >> advantages to Sage switching from Clisp to ECL is that ECL *does* use >> MPIR. Check this out in Sage-4.x: >> >> sage: k = 3^1000000+1 >> sage: m = maxima(3)^1000000+1 >> sage: timeit('j=k*k') >> 25 loops, best of 3: 14.2 ms per loop >> sage: timeit('j=m*m') >> 25 loops, best of 3: 17.6 ms per loop >> >> If you tried that in sage-3.x, it would take forever. >> >> Overall, Maxima+ECL is much much better for Sage than Maxima + Clisp for >> Sage. >> >> By the way, ECL = embedded common lisp. The point of "embedded" is >> that ECL is supposed to be easy to embed in C programs. We should >> thus be able to easily create a Cython interface to ECL and maybe >> somehow make the Sage <--> Maxima interface work entirely via the C >> library without using pexpect. This could speed up some things by a >> factor of 1000. >> > > Ah, that makes sense. It never occurred to me to check if any of the > lisp implementations actually used GMP or MPIR. Now I just recalled > that you recently encouraged ECL to switch from GMP to MPIR. Did they > do so? I recall PHP did switch.
I don't know what happened. ECL definitely works with MPIR, since we build it on MPIR as part of Sage. > > So ECL uses GMP or MPIR. Well maybe Lisp isn't so bad after all, eh. ;-) Indeed. See my April 1, 2009 master plan. :-) > > Bill. > > > > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
