On Apr 1, 7:19 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 31, 2008 at 11:21 PM, root <[EMAIL PROTECTED]> wrote:
<SNIP>
[Apologies in advance for going somewhat off topic in this thread and
ranting a little too much :)]
Hi Tim,
> > Both Axiom
> > and Maxima have implementations on top of GCL. GCL includes a
> > routine that will output the lisp type declarations and if these
> > are loaded into the image with a recompile the resulting code is
> > even faster. So if you use Maxima, use the GCL version.
>
> Unfortunately we've had a lot of problems building GCL on all
> our target platforms and have worries since it hasn't had a single
> official release in about 3 years. GCL's fine on Linux, but not
> elsewhere. I would have very very much liked to use GCL
> for Sage originally, but for the life of me I couldn't get it to build
> on the Sage platforms, unfortunately. We've tried several times
> in the subsequent years, but always failed. Maybe it is time to
> try yet again...
I am pretty sure it is well known that gcl is faster than clisp if you
start looking around a little.
> > CMUCL/SBCL are capable of slightly tighter optimizations because
> > they grew out of the SPICE Lisp project (under Scott Fahlman)
> > and concentrated on code optimizations. Under CMUCL I managed to
> > optimize a function down to a single machine instruction so it IS
> > possible to get maximal optimizations. But GCL also lays down some
> > very tight code since proper declarations can usually eliminate
> > type dispatch, which is important in the inner loops.
>
> > You can see the generated code by calling (disassemble ....)
>
> > On the other hand you're likely to get small factors of improvements
> > by changing to compiled lisps (but certainly much faster than python).
> > My experience shows that its the algorithm changes that matter most.
>
> Very interesting. I wouldn't what the differences are in
> speed between gcl and clisp maxima... A factor of 2 or 10,
> or maybe it varies a lot depending on the operation...
>
>
>
> > On a related note, I found it odd that someone commented that
> > they wish to remove Lisp from Sage. Do you have any idea what
> > might motivate that?
>
> Michael Abshoff made that comment.
My exact comment was
We are currently in the process of implementing symbolic
caculus in Sage itself and will hopefully in the next year move
differentiation, limits and integration and so on away from Maxima
into the Sage core. This is motivated by the need for performance and
the fact that we want to dump any lisp based code from the core of
Sage in the long term.
See
http://groups.google.com/group/sci.math.symbolic/browse_thread/thread/11d3054c63e76aff/922f2b5de7b38ac2#922f2b5de7b38ac2
for the whole thread that is still on going and is quite an
interesting read.
"we" in that context wasn't meant as an officially sanctioned
statement from the Sage community, but it certainly expresses the
opinion several other people and I have. The motivation is not hatred
of lisp since I have never used it beyond playing around with it a
little in Emacs. I understand it solves certain problems quite nicely,
but in the end it isn't part of my tool set and due to my experiences
listed below which do include the porting issues I am not very bullish
on lisp.
> He's motivated by wanting
> to port Sage to a wide range of architectures and keep everything
> maintainable, since he works incredibly hard on that. He suffers
> a huge amount trying to deal with build issues on various platforms
> such as solaris, Linux PPC, etc. I'm sure you understand well
> how hard building complicated math software is on a range of platforms!
After having played extensively with compiling open source lisp
implementations [only on Solaris, Linx and OSX, much less *BSD, AIX
and so on] let me give you my impression: I know of five open source
implementations of lisp:
Do not need to bootstrap themselves
a) gcl: no Solaris support, depends on libbfd [and elf precursor!], no
stable release in nearly five years. I broke the compilation trivially
on RedHat Enterprise 5 - a platform which should be well supported.
The issue was easy to fix, but that is a different story.
b) clisp: broken with gcc 4.2.x and gcc 4.3.0 for at least six months.
In effect a single developer. compiles on Solaris with gcc 4.2.2, but
segfaults in make check more or less instantly, segfaults building
Maxima when build with gcc 3.4.6 and also doing "make check" [but
later than with gcc 4.2.2]. gcc specific stack pointer code, so no
option to use the Sun Forte compiler on Solaris. This has been fixed
in CVS two, three days ago, but now the autoconf script for Solaris is
broken.
c) ecls: the ray of hope? But Maxima can't be build on top of it due
to same issues with save and load image. FriCAS has been ported to it.
Slower than clisp at the moment, but things are improving [Waldek
Hebisch gave a lot of input on pretty printing and closures over the
last two months or so and consequently things did improve in that area
*a lot*]. Like clisp in effect a single developer is working on this,
so the code has a bad bus factor.
Needs an existing lisp machine to boot and compile itself
d) sbcl - it works well on Solaris. But since it needs another lisp
instance it doesn't fit our requirements. Of the open lisp
implementations this seems to be the most portable and generally
delivers very good performance.
c) cmucl - it runs, but I managed to segfault it with the current
Maxima on Solaris.
So: that limits my choices of lisp on Solaris to (d) - which makes it
useless for Sage. There are commercial implementations, but those do
not ship with sources and are not acceptable for certain parties for
that reason.
If Maxima were ported to ecls I would put a lot of energy to switch
from clisp to ecls, regardless of potential performance problems in
the short term. Maxima isn't competitive as is for many things and a
constant slowdown by a factor of three will more than make up for the
reduced pain to compile clisp IMHO. This is also not the official Sage
opinion, but I am sure William will not disagree with me.
So what is my conclusion from all of the above: The the lisp ecosystem
is not exactly thriving because its tools which it depends upon are in
bad shape. Look for binaries for some more exotic arches [i.e. non x86
and x86-64 Linux] for cmucl or sbcl. If you don't find any people do
not care for those platforms and that is allways a bad sign. There are
probably blastwave binaries available [for clisp it is an ancient
2.39, but as non-root I cannot install those].
From my experience porting Sage or any other code I have worked on I
have drawn the following conclusion: If projcet X compiles fine,
passes it test suite and valgrinds clean it *does not* mean that the
code is even remotely close to bug free. It just means that you have
by design not found the bugs that do not affect you or are hidden by
your particular choice of compiler. Exposing Sage to Solaris or even
PPC Linux has pointed me to an rather large number of bugs. Other code
I have worked on has improved by porting it to Sun Forte's compiler,
MSVC or also IBM's C compiler. So that leaves me to believe that
porting Sage to platforms [PPC Linux for example] of insignificant
commercial value [i.e. no commercial software vendor would port their
mathematical code to it, i.e. No Maple or Mathematica for PPC Linux]
might seem like a waste of resources, but it makes the code better. In
my experience it is only a question of time until some bug that is
hidden by your choice of tool set bites you in the ass. A prime
example is
http://trac.sagemath.org/sage_trac/ticket/1337
which was caught instantly on PPC Linux since it segfaulted Sage on
exit every time. Depending on which patches you merged it would do the
same on x86-64. We didn't merge a fix for a huge leak in the coercion
system because of that bug. There was a lot of discussion about that
bug off list and During SD7 and 8 and we finally fixed it because I
really, really wanted to merge that bugfix. But that is the reason I
consider exotic arches the "canary in the coal mine" for Sage and
really any other piece of code in general. Right now Solaris has
exposed a bunch of issues regarding alignment, endianess issues,
assumptions about pointer size and ints and so on. And all of them can
potentially become a problem for you favorite arch. So dismissing
arches because they are not mainstream is a bad thing.
> By the way, his comment was not an "official opinion" of the
> Sage project or anything, and packages don't leave Sage without
> a lot of discussion, voting, etc.
And even if it were to happen it will be a long, drawn out process.
> -- William
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
