Opened 10 years ago

Last modified 5 years ago

#6705 new defect

ATLAS has no tuning parameters for sun4v machines

Reported by: drkirkby Owned by: tbd
Priority: major Milestone: sage-6.4
Component: porting: Solaris Keywords:
Cc: Merged in:
Authors: Reviewers:
Report Upstream: None of the above - read trac for reasoning. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

Code in ATLAS can not detect the processor type on machines like the Sun T5240 ('t2') as it

This has been passed upstream

https://sourceforge.net/tracker/?func=detail&aid=2825994&group_id=23725&atid=379483

but there is no fix yet. I probably have enough information to fix this, but have not done so yet.

Change History (10)

comment:1 Changed 10 years ago by drkirkby

  • Report Upstream set to None of the above - read trac for reasoning.

This has been closed on the ATLAS tracker, but there is still no solution.

comment:2 Changed 10 years ago by drkirkby

  • Cc david.kirkby@… added

comment:3 Changed 10 years ago by drkirkby

  • Cc david.kirkby@… removed
  • Milestone set to sage-4.3.2

comment:4 follow-up: Changed 9 years ago by mpatel

If I run ./sage -f -m spkg/standard/atlas-*.spkg on t2, where can I find the tuning parameters under spkg/build/atlas-*? Can we include them in an updated ATLAS package? I assume this will speed up the build, but please correct me if I'm wrong.

comment:5 in reply to: ↑ 4 ; follow-up: Changed 9 years ago by drkirkby

Replying to mpatel:

If I run ./sage -f -m spkg/standard/atlas-*.spkg on t2, where can I find the tuning parameters under spkg/build/atlas-*? Can we include them in an updated ATLAS package? I assume this will speed up the build, but please correct me if I'm wrong.

They end up in a .tgz file, but it's not as easy to add them as you might think. I've read the ATLAS documentation, and find it confusing. I even asked on the support tracker, and are still not sure how to do it. Apparently one Sage developer did know how (Micheal) - I don't think anyone else has succeeded!

I understand the latest ATLAS will build on 't2' in under an hour. However, I don't know if that is for 32-bit, 64-bit or both builds. I somehow suspect it might only be for 64-bit builds, as I suspect it was tested in the default method, which is 64-bit.

On my own Intel Xeon W5680 processor, I can build ATLAS in under 10 minutes on a 64-bit build, but on a 32-bit build it takes nearly two hours. Clearly the ATLAS package has the tuning parameters for my CPU when built 64-bit, but not when built 32-bit.

Given ATLAS will by default build 64-bit, I suspect the latest ATLAS will not be any faster.

I suspect that integrating the 32-bit tuning parameters to the latest ATLAS might be a lot easier than integrating them into the current version. The current code can't detect the CPU type at all, and reports it as "UNKNOWN". I think the new ATLAS should at least know what CPU type this is.

The problem with updating ATLAS is the package is so messy. I looked at building it in parallel (it's clearly designed for that, and has options specifically for parallel builds), but it failed for me. Given it takes a long time to build if the system is unknown, it would be nice to get parallel builds working. There are special configure options for using a parallel make.

I'd be tempted to re-write the whole package as /bin/sh shell script. Remove the python, remove the perl. But some might object to that. I can't see why we should have to wait for python to build before building ATLAS - it would be sensible to get ATLAS building as soon as possible.

If you look at the current build process, there's a very small python script calling a huge bash script. Those few lines of python could be removed I think. (The only small hitch I hit was generating a random number - not sure how to do that in /bin/sh, but it does not need to be a very good random number. In fact, I'm not sure I see the point of starting the build after a random delay myself). Not sure if anyone would like removing Python though. Getting a review of a re-write of spkg-install might be difficult. I'm also keen to avoid the hassle I had with #9603, where wanting to add && [ "x$UNAME" != xHP-UX ] has made a ticket last 5 weeks. Leif virtually wanted the whole thing re-written. All I originally wanted to do was get it to build on HP-UX too! I'm not denying the package is better now, but I don't think it really warranted the work. (I did add a Solaris change a couple of days back, but prior to that, it had dragged on for a month when all I wanted to add was 20 bytes or so).

I guess we could just drop the latest ATLAS source code in, and hope it works. But I actually doubt it will tune any quicker on 32-bit builds.

Hopefully, when the 64-bit issues are resolved, there wont be much point in building a 32-bit version of Sage on Solaris.

How would you feel about a re-write of the build process as a bash script, without a review process that drags on for months? (Hiding it from Leif would be nice!!)

Dave

comment:6 in reply to: ↑ 5 Changed 9 years ago by mpatel

Replying to drkirkby:

The problem with updating ATLAS is the package is so messy. I looked at building it in parallel (it's clearly designed for that, and has options specifically for parallel builds), but it failed for me. Given it takes a long time to build if the system is unknown, it would be nice to get parallel builds working. There are special configure options for using a parallel make.

Is there a system on which ATLAS does build / tune successfully in parallel?

I'd be tempted to re-write the whole package as /bin/sh shell script. Remove the python, remove the perl. But some might object to that. I can't see why we should have to wait for python to build before building ATLAS - it would be sensible to get ATLAS building as soon as possible.

We'll also need to do the same with the Fortran spkg, in order to start building ATLAS earlier in the Sage build process. If this will help generally and significantly with parallel spkg builds, we might convince others that this worthwhile. Of course, we'll need to test it well.

Can we use bash and its $RANDOM?

comment:7 Changed 6 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:8 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:9 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:10 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4
Note: See TracTickets for help on using tickets.