Minh Nguyen wrote:
Hi folks,Yes, you heard right. Sage 4.3.4.alpha1 now builds on t2.math thanks to the persistent hard work of David Kirkby. Here's something to wet your appetite: [mv...@t2 sage-4.3.4.alpha1]$ ./sage ---------------------------------------------------------------------- | Sage Version 4.3.4.alpha1, Release Date: 2010-03-09 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- ********************************************************************** * * * Warning: this is a prerelease version, and it may be unstable. * * * ********************************************************************** sage: primes_first_n(100) [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541] sage: 2 + 3 5 sage: exit Exiting SAGE (CPU time 0m0.31s, Wall time 0m17.21s).
Well done Minh. That is great news.Let's hope the final release of 4.3.4 also builds - i.e. it does not get broken before the release! Are you able to check the web interface too?
I tried to build 4.3.4.alpha1 on 'mercury' (a dual 1600 MHz Sun Blade 2500) at Blastwave, and run into a problem.
gcc -std=gnu99 -G -L/home/dkirkby/sage-4.3.4.alpha1/local/lib/ -o R_X11.so dataentry.o devX11.o rotated.o rbitmap.o -lSM -lICE -L/opt/csw/lib -lpangocairo-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -lX11 -lpng12 -lz -lcairo -L/usr/openwin/lib -R/usr/openwin/lib -lX11 -lXt -lXmu -ljpeg -lpng -lz -ltiff -L../../../lib -lR -lm ld: fatal: recording name conflict: file `/home/dkirkby/sage-4.3.4.alpha1/local/lib//libpng12.so' and file `/opt/csw/lib/libpng.so' provide identical dependency names: libpng12.so.0
ld: warning: symbol `libintl_nl_default_dirname' has differing sizes:(file /opt/csw/lib/libintl.so value=0x16; file ../../../lib/libR.so value=0x1);
/opt/csw/lib/libintl.so definition taken
ld: fatal: File processing errors. No output written to R_X11.so
collect2: ld returned 1 exit status
make[6]: *** [R_X11.so] Error 1
It would appear that there is a clash of libraries, between those installed on
Blastwave, and those included as part of Sage. Note how the linker is chosing
the blastwave library in preference to the one included in Sage. I had not
specifically included /opt/csw/lib when building Sage - that is how the compiler
is set up on Blastwave. That directory has over 1000 different libraries in it -
one of which is causing a problem with Sage.
A build of the alpha0 also failed on the machine 'mark' on skynet, despite me applying all the patches necessary to get Sage to build on my own machine. The machines on 'skynet' are configured with gcc using the GNU linker, which is quite unusual on SPARC. Sun's copy of gcc uses the GNU linker, as does that from Blastwave and any I've built.
It would be nice if building on Solaris was totally foolproof, but it is not.Dennis Clarke, the director of Blastwave, is keen to get Sage into Blastwave, which would be good, as then it would be available as a package from a well know source of Solaris binaries. But at the moment, it does not want to build using their standard setup.
I'm just in the process of downloading 4.3.4.alpha1 to my Sun Blade 1000. I expect that will build ok.
There were some doctest failures on the alpha0. Some I submitted patches for, and I know some others were failing on other hardware too, so other people created patches. But I'm not sure if all doctest failures would have been resolved.
Anyway, you will know before me, as I've not even finished downloading 4.3.4.alpha1 to my home machine.
A strange thing occurred. I first set NUM_THREADS=10 in makefile. Then I issued "make ptestlong", only to see that cddlib was reinstalled. Doctesting is still running in parallel using 10 threads.
I've not tried a parallel ptestlong myself. I'll see what happens on one of my machines. I can't see why cddlib would be reinstalled.
It is probably worth using far more than 10 threads on 't2'. Although it has 16 core, there are 128 hardware threads. I've convinced myself that one needs to use at least 256 threads to get optimal performance. In fact, going to 1000 threads is very slightly quicker.
I think I posted some benchmarks I'd done before on 't2', and quite simply setting threads=cores does not give anywhere near the performance possible. Of course, you don't want to bring 't2' to its knees, but it is not heavily used.
Dave -- 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 URL: http://www.sagemath.org
