Well ECL uses mpz_add 11 times in 73783 lines of Lisp code *not* including system header files, which I removed, compared to 111 occurrences in Sage's 1.66M lines of Python code (to be honest I am not sure if it counted the Cython files or not, but what's another 300K lines between friends). Now
ECL : 11/73783 = 1.49x10^-4 whereas Sage : <= 111/1.66x10^6 = 6.69x10^-5. So it seems Lisp is actually a bit mpz_add heavy. I'd write to the authors and complain about that. It's clearly inefficient use of Lisp macro processing capability, especially given that ECL is only a compiler, not a computational algebra package. OK, ok, so I really should add the lines of lisp code in Maxima to that total to be fair: ECL + Maxima : 11/370000 = 2.97x10^-5 Yep Sage is bloated. Time to give it a haircut. By the way, ECL still uses GMP version 4.2.1 and also uses Brian's old Windows patches to support GMP. They really should switch, as it would give a real boost to them to do so, especially on the msvc stuff. Bill. 2009/8/17 William Stein <wst...@gmail.com>: > > 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 -~----------~----~----~----~------~----~------~--~---
