Hmm, wait a minute, there is a good chance there's a lot of duplicate files there, due to HG or something. Perhaps there's only 300K of python and cython lines of code.
So maybe 111 occurrences is actually a bit high based on this (silly) metric. Bill. 2009/8/17 Bill Hart <goodwillh...@googlemail.com>: > 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 -~----------~----~----~----~------~----~------~--~---
