2009/8/17 William Stein <[email protected]>: > > On Mon, Aug 17, 2009 at 1:17 AM, Bill Hart<[email protected]> 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. So ECL uses GMP or MPIR. Well maybe Lisp isn't so bad after all, eh. ;-) Bill. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
