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. -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
