Bill Hart wrote: > 2009/7/17 Dr. David Kirkby <david.kir...@onetel.net>:
>> The build speed problem is due to ATLAS. Here is the list of packages >> currently built on t2 (it's building now). Look at the times between them <SNIP> >> What you may notice is a huge time between lapack-20071123.p0 @ 2315 and >> atlas-3.8.3.p5 @ 0743 the next day. In other words ATLAS is taking 8.5 hours >> to build. It is the 'tuning' process which is taking 90% of that time. >> >> That could be reduced dramatically if we could save the temporary files it >> builds, produce a set of tuning values for the sun4v architecture, then >> ATLAS would not need to be tuned every time. But despite trying, and asking >> for some help, I can't stop Sage deleting the intermediate files. See my >> thread: >> >> "Can I keep build data once a package is installed ok?" >> >> There is a bit of code in $SAGE_ROOT/local/bin/sage-spkg >> >> >> DELETE_TMP=1 >> >> changing that to zero, which is what William suggested to do, causes a >> syntax error. I can't work out what's happening. I suspect fixing this >> should be a high priority. > > I agree, this is should be a high priority. I've just create a trac ticket for this. http://sagetrac.org/sage_trac/ticket/6550 Any help appreciated. >> I'll create a trac ticket for this. >> >>> I'm not the right person to be reviewing this. >>> >>> I'm also completely unsure whether the patch is valid or not. David >>> has done things like turn testing on which I've no idea is the right >>> thing to do or not, from a Sage point of view. That should be bundled >>> as a separate patch in my view. >> I did *not* turn testing on. Perhaps I should have made that clearer. > > I am referring to the trac ticket which says: > > "A few others things are done in this patch. > > Removed a comment at the bottom of spkg-install to bypass the checks > on release systems. Given failures have occurred, it would be unwise > to bypass any checks > Add a comment to remind people not to bypass the tests. > Update the source to use the latest patches, as strongly recommenced > in the INSTALL file. This brings the code to MPFR 2.4.1 patch level 5, > though I'm considering it mpfr-2.4.1p0 for Sage purposes." I realised I confused you, but the testing was already taking place. Had it not, the problem with the test failures would never been observed. >> My personal opinion is that given >> >> * Sage takes many hours to almost build >> * Testing take about 10 minutes, >> * Failures have been seen in mpfr >> >> I feel it's best to leave mpfr testing on permanently. > > I agree totally. But some sage devs complain that building Sage takes > too long, so there is always a tradeoff between better testing and > taking too long to build. It all adds up. True. But when a particular package is known to have caused problems, and the exact reason is not fully understood, it's worth keep it on in my opinion. >> The gcc guys don't think it is. They appear to think it is a bug in Solaris, >> as they think the assembly code is correct. > > Oh dear. Groan. Yes. >> One concern I have over not patching is that using gcc 4.2.4 might break the >> build of polybori. I believe it does, but I am in the process of doing a >> fresh build from scratch and verifying this. Polybori is seriously broken in >> too many ways to list, but Alexander Dreyer is looking at fixing that. He >> now has an account on t2. >> > > I see, so you are saying we'd actually have to use an earlier version > of gcc 4.2.4 or earlier. No, polybori builds with gcc 4.4.0 if the Sun compiler suite can't be found in the path. Should polybori find SunStudio, it will * Start building with C++ files with g++ * Switching to using Sun's 'CC' to build C++ files * Use GNU -specific flags when using the Sun tools * Use Sun-specific flags on the GNU tools. Polybori is seriously broken with gcc 4.4.0, but I am not convinced it will build at all with 4.2.4. I'm not 100% sure of this. > In retrospect, I think your patch is the right way to go, and I'd have > no issue with using a later gcc (4.3.1 or later) on T2. The most > important thing which needs to be done is to fix the ATLAS issue, then > someone can begin to test some of these patches you have been coming > up with. > > An alternative might just be to not bother testing the patch as part > of the review process, on t2, but only test that it doesn't break the > build on some other (non-t2) machine. I mean, it is not like this > patch is going to stop sage building on t2, as it doesn't build > anyway. > > I'm prepared to sign off on the fact that the premise behind the patch > is fine. If someone else will glance at the actual patch code and test > it against an already working sage on a non-t2 machine, perhaps people > will allow the patch to pass review without further testing. > > Bill. The patch consists of a lot of nested 'IF' statements, but the most outer ones are: if [ `uname` = "SunOS" ]; then fi So if the system is not Solaris, then nothing will happen at all. Dave --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send 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 -~----------~----~----~----~------~----~------~--~---
