Hi, (This email got a bit long. See EXECUTIVE SUMMARY below for the conclusion.)
There's a serious push to get Sage to work on Solaris and to keep it working. This involves testing spkg's and at least lower-level patches on Solaris to make sure nothing gets broken. We need to somehow reconcile this (and the associated goal of having a working Solaris port by sage-5.0) with the reality expressed by several Sage developers in a couple of discussion threads, that testing on Solaris is currently more of a time-consuming black magic than a straightforward process. In the same threads, there is some consensus that an automatic procedure would greatly simplify things, but we don't have that yet. The only Solaris machine I have access to is t2. I have been experimenting with it to see how I can include it into my Sage workflow. I still find it rather cumbersome and time-consuming, but I'd like to mention some observations and suggestions that might improve this somewhat. Building Sage on t2 takes a long time. It would be great to have a t2.math binary available for each alpha/rc/final release of Sage, which anyone can just grab and untar and start testing on *right away*. For testing, it is not immediately obvious how many threads to use. (And you do want to use parallel testing, since each thread only gets 388 BogoMips.) Here are the results of my experiments over the last couple of days, with sage-4.3.0.1 (that was the binary I had available): * 15 threads: 5199.3 seconds * 20 threads: ~4200 seconds * 25 threads: 3597.2 seconds * 32 threads: 3429.1 seconds * 50 threads: 6349.7 seconds * 100 threads: 13601.0 seconds It seems to me that the optimal setting is somewhere around 32 threads, for which "make ptestlong" then takes a bit less than an hour. Not as good as sage.math, but also not that terrible. There are a couple more things: (a) I don't know if this has been fixed since 4.3.0.1, but each run of "make ptestlong" starts by rebuilding all the documentation, which takes almost 1.5 hours. (b) I had to run all this from my home directory on t2, instead of the local /scratch disk on t2, because somehow the group ownership/permissions are messed up and I couldn't copy into /scratch. I don't know if doctesting from /scratch would be any faster, but it would be worth looking into this. (c) I can't seem to be able to use "screen" on t2, because of some problem with terminfo. (This might be a "ulimit" issue.) EXECUTIVE SUMMARY: here are suggestions for making t2 more efficient for Sage development: 1. make available a t2 binary for each development release of sage; this should have already gone through one round of "make ptestlong" so that the parallel testing timing information is already present; maybe it should also have NUM_THREADS=32 (or whatever the optimal t2 value is) preset in "makefile" 2. fix the permission issues on t2 and make it possible to run "screen" Best, Alex -- Alex Ghitza -- http://aghitza.org/ Lecturer in Mathematics -- The University of Melbourne -- Australia -- 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
