Can't one just make a private copy of a SAGE_ROOT of an already built installation? (The only requirement is that everything in SAGE_ROOT is world- readable.)
Dima On Mar 13, 7:36 am, Alex Ghitza <aghi...@gmail.com> wrote: > 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
