| Summary: | sci-libs/atlas 3.7.23 released | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | M. Edward Borasky <znmeb> |
| Component: | New packages | Assignee: | Gentoo Science Related Packages <sci> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | ediap, gentoo, rossen |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
atlas3.7.14-shared-libs.patch
blas-atlas-3.7.14.ebuild atlas3.7.14-shared-libs.patch blas-atlas-3.7.14.ebuild 3.7.15-shared-libs.patch blas-atlas-3.7.15.ebuild lapack-atlas-3.7.15.ebuild atlas-3.7.15-shared-libs.patch (updated for lapack-atlas) lapack-reference-3.0-autotool.patch |
||
********* *BEGIN ENCRYPTED or SIGNED PART* ********* Hi, Thanks for the note! "Unfortunately", starting with 3.7.12 upstream has significantly changed atlas' build system, which probably means that a major ebuild overhaul is needed. Hence, it might take a little until this guy hits portage. Would you mind filing a bug for it so we can track any progress there? Thanks, Markus -- Markus Dittrich (markusle) Gentoo Linux Developer Scientific applications ********** *END ENCRYPTED or SIGNED PART* ********** -- gentoo-science@gentoo.org mailing list Hi! To start the work on providing ATLAS 3.7.14 to Gentoo, I have ported the atlas3.6.0-shared-libs.patch to atlas3.7.14. Please find the attached patch and a draft release of blas-atlas-3.7.14.ebuild attached. Unfortunately, I encountered the following error while building shared objects in src/blas/gemv directory: gcc32 -c -DL2SIZE=4194304 -I/var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/include -I/var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/..//include -I/var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/..//include/contrib -DAdd__ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_HAMMER -DATL_CPUMHZ=1808 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632 -fomit-frame-pointer -O2 -DSCPLX -DBETA0 -DALPHA1 ATL_cgemvN.c -fPIC -DPIC -o .libs/ATL_cgemvN_b0.o /var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/..//include/contrib/camm_dpa.h: In function `dp1dpNb0': /var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/..//include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' /var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/..//include/contrib/camm_dpa.h: In function `dp2dpNb0m': /var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/..//include/contrib/camm_dpa.h:1488: error: PIC register `bx' clobbered in `asm' make[1]: *** [ATL_cgemvN_b0.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/blas-atlas-3.7.14/work/ATLAS/build/src/blas/gemv' make: *** [clib] Error 2 I googled for this and found this problem reported some time ago: http://sourceforge.net/mailarchive/forum.php?thread_id=8001623&forum_id=426 I only tried to build blas-atlas-3.7.14.ebuild with gcc-3.4.6. Will check with gcc-4.1.1 tomorrow. Looking to your comments, tests, and help with this work :) BR, /ediap Created attachment 94726 [details, diff]
atlas3.7.14-shared-libs.patch
Created attachment 94727 [details]
blas-atlas-3.7.14.ebuild
Hi Adam, Thanks for your efforts! I just finished porting the libtool stuff to 3.7.14 myself (we should have coordinated this ;-) ) and everything compiles and links fine. I've a few issued regarding parallel builds to iron out, and should be able to commit a testing ebuild to portage in a few days or so. I'll have a look at your patch and maybe I can use it to improve what I have:) The clobbering issue, btw, is related to the ASM VOLATILE code in the ebuild that you commented out. Once you move it back it should compile. Thanks, Markus Hi Markus, I have had to fix few parts of my patch and uncommented the ASM VOLATILE part in ebuild and finally was able to link the shared libraries. I will update the patch and ebuild soon. Unfortuately, I got QA Notice at the end of emerge process: QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. For more information, see http://hardened.gentoo.org/gnu-stack.xml Please include this file in your report: /var/tmp/portage/blas-atlas-3.7.14/temp/scanelf-execstack.log "RWX --- --- usr/lib/libatlas.so.0.0.0" In spite of this, the library seems to work fine (I only tested it with IT++, though). BR, /ediap Created attachment 94855 [details, diff]
atlas3.7.14-shared-libs.patch
Created attachment 94856 [details]
blas-atlas-3.7.14.ebuild
Hi Adam, Thanks a lot! I've already merged some of your previous patch with what I had and I am currently performing a last run through before committing a test version probably tonight. Your current patch is still missing some of the *srch* routines in ATLAS/tune/blas/level1/ of which there are 12 if I am not mistaken. Some of them don't matter for certain CPUs, which is probably why it didn't matter for you :) The executable stacks have been present in past versions as well. Some of the blas-atlas generated custom assembly code also has text relocations in one of the threaded libs; getting rid of these issues probably means digging deep into atlas' code generator which is likely non-trivial. Maybe I can have a look at it at some point. Thanks for all your help, Markus (In reply to comment #9) > Thanks a lot! I've already merged some of your previous patch with > what I had and I am currently performing a last run through before > committing a test version probably tonight. Before committing, please update the ebuild to atlas3.7.15, which was released today. There were not much changes, so it should compile with the same patch. I am now building from blas-atlas-3.7.15.ebuild and going to post here the ebuild and patch as soon as it finish. > Your current patch is > still missing some of the *srch* routines in ATLAS/tune/blas/level1/ > of which there are 12 if I am not mistaken. Some of them don't matter > for certain CPUs, which is probably why it didn't matter for you :) You are right. At one host I got a compilation error and fixed that already. > The executable stacks have been present in past versions as well. > Some of the blas-atlas generated custom assembly code also has text > relocations in one of the threaded libs; getting rid of these issues probably > means digging deep into atlas' code generator which is likely non-trivial. > Maybe I can have a look at it at some point. I see. Thanks for your expertise on this ;)) BTW, I am subscribed to the atlas-devel mailinglist and I wonder wheather to ask about this ASM VOLATILE patch. Do you think we can ask Clint to include this in the official atlas release? /ediap Created attachment 94883 [details, diff]
3.7.15-shared-libs.patch
Created attachment 94884 [details]
blas-atlas-3.7.15.ebuild
Markus, please commit in p.mask and use the new eselect stuff, we hope to unmask it shortly (i.e. this week). Doh, Clint is releasing atlas now faster than I can do the testing and porting:) Hopefully most of 3.7.14 stuff I have will carry over, but I will need one more day to test out 3.7.15 in depth. Donnie, the ebuild has the new eselect stuff and the p.mask for it is already in portage :) Adam, regarding the ASM VOLATILE we could talk to Clint; however, it should only matter (I think) for pic code and is hence specific to gentoo's shared lib patch. Hence he might not care. Thanks, Markus (In reply to comment #14) > Doh, Clint is releasing atlas now faster than I can do the testing and > porting:) Hopefully most of 3.7.14 stuff I have will carry over, but I will > need one more day to test out 3.7.15 in depth. One change I noticed was the addition of DESTDIR. (In reply to comment #15) > (In reply to comment #14) > > Doh, Clint is releasing atlas now faster than I can do the testing and > > porting:) Hopefully most of 3.7.14 stuff I have will carry over, but I will > > need one more day to test out 3.7.15 in depth. > > One change I noticed was the addition of DESTDIR. Yes. This was due to my proposal sent to atlas-devel list. ;-) However it is only useful when installing static libraries. Anyway, I think we can send more ideas to Clint, which he might consider as future TODO items... BTW, Markus, have you tried to update the lapack-atlas-*.ebuild, as well? BR, /ediap (In reply to comment #16) > Yes. This was due to my proposal sent to atlas-devel list. ;-) However it is > only useful when installing static libraries. > Anyway, I think we can send more ideas to Clint, which he might consider as > future TODO items... > > BTW, Markus, have you tried to update the lapack-atlas-*.ebuild, as well? > > BR, > /ediap > Unfortunately, no. It took me way longer to properly back-port all the libtool stuff and actually prevent blas-atlas from building lapack than I was expecting. I hope I can have a go at it once the new blas-atlas ebuild is committed. Markus (In reply to comment #10) > BTW, I am subscribed to the atlas-devel mailinglist and I wonder wheather to > ask about this ASM VOLATILE patch. Do you think we can ask Clint to include > this in the official atlas release? Yeah, go ahead. I'm on the Atlas mailing list too. Just out of curiosity, is Gentoo the only way you can "easily" get Atlas as shared libraries? The last time I built it from upstream source, it only made static libraries and you had to jump through some "ar" hoops to merge it with lapack. Those sort of "conveniences" that Gentoo has really ought to be part of the Atlas distribution, don't you think? Is the ebuild going to be in the regular Portage tree or the "sci" overlay? > > /ediap > (In reply to comment #18) > Yeah, go ahead. I'm on the Atlas mailing list too. Just out of curiosity, is > Gentoo the only way you can "easily" get Atlas as shared libraries? The last > time I built it from upstream source, it only made static libraries and you had > to jump through some "ar" hoops to merge it with lapack. Those sort of > "conveniences" that Gentoo has really ought to be part of the Atlas > distribution, don't you think? > Well, we could "offer" our patch to upstream and see what they say. Clint might have a reason why he doesn't build shared libraries out of the box, but I really couldn't say. > Is the ebuild going to be in the regular Portage tree or the "sci" overlay? It will be in the regular portage tree but package mask'ed until bugs are ironed out and the new eselect packages have been unmasked as well. If all goes well I'll commit the new ebuild in a few hours from now. Thanks, Markus The ebuild for 3.7.15 is now in portage - please test and let me know of
any problems.
The ebuild uses the new eselect version and will produce
errors during the install since the eselect files with the symlink maps
are currently missing from ${FILESDIR}. I assume that Donnie
will commit them soon.
I've also removed the forced CFLAGS for sun4m and sun4e since I am
not sure if they are still needed. If so, I'll move the back in but for now
the ebuild fully honors the user's CFLAGS and LDFLAGS.
Thanks,
Markus
Crap, not sure how that slipped though. Will fix ASAP. (In reply to comment #20) > The ebuild for 3.7.15 is now in portage - please test and let me know of > any problems. I have to issues: 1) blas-atlas-3.7.15 can not be emerged on machines which use some kind of CPU throttling (cpufreq, etc.), because this is checked during the configuration. In my ebuild I switched this check permanently using "-Si cputhrchk 0" appended to the configure command. It might be also good to add a warning message that users should turn of any thottling before emerging blas-atlas to have correct timings. 2) Why the configuration stage is done in src_unpack() instead of src_compile(). Is it because the C and Fortran compiler flags? BR, /ediap (In reply to comment #22) > (In reply to comment #20) > 1) blas-atlas-3.7.15 can not be emerged on machines which use some kind of CPU > throttling (cpufreq, etc.), because this is checked during the configuration. > In my ebuild I switched this check permanently using "-Si cputhrchk 0" appended > to the configure command. It might be also good to add a warning message that > users should turn of any thottling before emerging blas-atlas to have correct > timings. > Thanks for pointing this out! I didn't notice this, since none of my dev machines have CPU throttling enabled. Your suggestions of "warning + turning the check off" sounds like a workable solution and I'll put this in the ebuild sometime today. > 2) Why the configuration stage is done in src_unpack() instead of > src_compile(). Is it because the C and Fortran compiler flags? > I did this since atlas' configure not only configures in the autotools sense but also does compiling and copying of files leading to the unpleasant side effect that one can not do a "configure" in the same build directory twice (at least I can't). Hence, if the build process breaks in the src_compile() step of the ebuild it can't be restarted if configure happens in src_compile() but it can if it is in src_unpack(). Hence, as such it is mostly a convenience from a development point of view. Does that sound reasonable!? Thanks, Markus > BR, > /ediap > (In reply to comment #23) > I did this since atlas' configure not only configures in the autotools > sense but also does compiling and copying of files leading to the > unpleasant side effect that one can not do a "configure" in the same > build directory twice (at least I can't). Hence, if the build process breaks > in the src_compile() step of the ebuild it can't be restarted if configure > happens in src_compile() but it can if it is in src_unpack(). Hence, as such > it is mostly a convenience from a development point of view. Does that sound > reasonable!? Sure! /ediap I'm running into some dependency issues with "eselect-blas" and "eselect-cblas". I had to hack around them with "package.unmask", but "blas-atlas-3.7.15" itself is installing nicely. I'm going to re-run it in "init 1" mode to get accurate timings later today. (In reply to comment #25) > I'm running into some dependency issues with "eselect-blas" and > "eselect-cblas". I had to hack around them with "package.unmask", but > "blas-atlas-3.7.15" itself is installing nicely. I'm going to re-run it in > "init 1" mode to get accurate timings later today. > Thanks for testing and the new eselect functionality will be unmasked in the near future. I also just added the configure flag disabling CPU throttling + warning to the ebuild. Markus Hi! After a few hours of experiments, I managed to prepare a lapack-atlas-3.7.15.ebuild. Please find the attached ebuild and additional patches. I had to update atlas-3.7.15-shared-libs.patch with some additional changes, but they should be transparent to blas-atlas-3.7.15 ebuild. So this patch can be shared between lapack-atlas and blas-atlas packages. Besides, lapack-reference-3.0-autotools.patch from lapack-reference is now required for lapack-atlas as well. The ebuild uses sed to add "-I/usr/include/atlas" to INCLUDES in Make.inc from ATLAS and additionally it reverts "LAPACKlib = " to "LAPACKlib = $(LIBdir)/liblapack.a". I am not sure if the LAPACKlib needs to be unset while building blas-atlas. If not, it would be better to have this variable not modified by the atlas-3.7.15-shared-libs.patch. Looking for your comments and tests. BR, /ediap Created attachment 95324 [details]
lapack-atlas-3.7.15.ebuild
Created attachment 95325 [details, diff]
atlas-3.7.15-shared-libs.patch (updated for lapack-atlas)
Created attachment 95326 [details, diff]
lapack-reference-3.0-autotool.patch
(In reply to comment #27) > Hi! > > After a few hours of experiments, I managed to prepare a > lapack-atlas-3.7.15.ebuild. Please find the attached ebuild and additional > patches. I had to update atlas-3.7.15-shared-libs.patch with some additional > changes, but they should be transparent to blas-atlas-3.7.15 ebuild. So this > patch can be shared between lapack-atlas and blas-atlas packages. > Besides, lapack-reference-3.0-autotools.patch from lapack-reference is now > required for lapack-atlas as well. > > The ebuild uses sed to add "-I/usr/include/atlas" to INCLUDES in Make.inc from > ATLAS and additionally it reverts "LAPACKlib = " to "LAPACKlib = > $(LIBdir)/liblapack.a". I am not sure if the LAPACKlib needs to be unset while > building blas-atlas. If not, it would be better to have this variable not > modified by the atlas-3.7.15-shared-libs.patch. > > Looking for your comments and tests. > > BR, > /ediap > Hi Adam, Thanks a bunch, that's great :) I just skimmed over everything and from what I gathered the ebuild looks fine besides a ${FORTRANLIB} in line 110 which should be a ${FLIBS} or vice versa. Your changes to that shared libs patch also look nice. I unset LAPACKlib at some point during my quest of forcing blas-atlas not to build its lapack by default but I am not sure right now if it is actually still needed. I'll check it out tomorrow and will also have a look at the ebuild. Thanks, Markus (In reply to comment #31) > Thanks a bunch, that's great :) I just skimmed over everything and from what > I gathered the ebuild looks fine besides a ${FORTRANLIB} in line 110 > which should be a ${FLIBS} or vice versa. Your changes to that shared > libs patch also look nice. You are right here... My mistake. > I unset LAPACKlib at some point during my quest of forcing blas-atlas > not to build its lapack by default but I am not sure right now if it is > actually still needed. I'll check it out tomorrow and will also have > a look at the ebuild. I have just checked this LAPACKlib with blas-atlas and leaving this library definied does not do any harm to blas-atlas build. So, I suggest removing this change from the patch and sed statement in the lapack-atlas ebuild. BR, /ediap (In reply to comment #32) > I have just checked this LAPACKlib with blas-atlas and leaving this library > definied does not do any harm to blas-atlas build. So, I suggest removing this > change from the patch and sed statement in the lapack-atlas ebuild. > > BR, > /ediap > Hi Adam, Your lapack-atlas ebuild with a few small cosmetic changes is now in portage. I am not quite sure if we need to keep the "throttling warning" for lapack-atlas since we're re-using the blas-atlas timings and simply turning off atlas' throttling detection shouldn't cause any harm. But I'll have to check that out in detail. Thanks again for the great work :) Cheers, Markus (In reply to comment #33) > Your lapack-atlas ebuild with a few small cosmetic changes is now in > portage. I am not quite sure if we need to keep the "throttling warning" > for lapack-atlas since we're re-using the blas-atlas timings and simply > turning off atlas' throttling detection shouldn't cause any harm. But I'll > have to check that out in detail. That's fine. > Thanks again for the great work :) You are welcome. BR /ediap One more minor issue... Can something be done with this QA Notice: QA Notice: pre-stripped files found: /var/tmp/portage/lapack-atlas-3.7.15/image/usr/lib/lapack/atlas/liblapack.so.0.0.0 strip: i686-pc-linux-gnu-strip --strip-unneeded usr/lib/lapack/atlas/liblapack.a BR, /ediap (In reply to comment #35) > One more minor issue... Can something be done with this QA Notice: > > QA Notice: pre-stripped files found: > /var/tmp/portage/lapack-atlas-3.7.15/image/usr/lib/lapack/atlas/liblapack.so.0.0.0 > strip: i686-pc-linux-gnu-strip --strip-unneeded > usr/lib/lapack/atlas/liblapack.a > Hi Adam, I'll have a look to see why libatlas seems to be pre-striped but blas/cblas isn't. BTW, it looks like Clint just released 3.7.16 with support for Core2, which seems to do very well. At this point I'd rather wait a little in following up with an ebuild since Clint's email seems to imply that he's still working on improving the Core2 support, hence 3.7.17 is probably not too far away. cheers, Markus Hi Markus! (In reply to comment #36) > I'll have a look to see why libatlas seems to be pre-striped but blas/cblas > isn't. I guess this might be caused by creating the liblapack library twice, but I am not sure. The library is linked for the first time when building lapack-reference with "emake", and for the second time when manually relinking with atlas' lapack objects using libtool. > BTW, it looks like Clint just released 3.7.16 with support for Core2, which > seems > to do very well. At this point I'd rather wait a little in following up with an > ebuild since Clint's email seems to imply that he's still working on improving > the Core2 support, hence 3.7.17 is probably not too far away. Sure. We can wait a little bit. Moreover, new eselect stuff is still masked, so there is no hurry. /ediap Looks like 3.7.17 is out :) I'll test the new release and bump the ebuilds for blas-atlas/lapack-atlas over the next few days. cheers, Markus (In reply to comment #38) > Looks like 3.7.17 is out :) > I'll test the new release and bump the ebuilds > for blas-atlas/lapack-atlas over the next few days. > > cheers, > Markus > Have all the kinks in eselect/blas-config/lapack-config been worked out yet? I had to drop back to 3.7.11 to do some testing on LinBox, which uses Atlas. eselect stuff should be working fine with eselect 1.0.5. Hi Folks, I just bumped blas-atlas to 3.7.19 in portage. The ebuild now uses atlas' configure to select compiler/cflags and also uses its "-b 32/64" option to force building of 32/64 bit libraries depending on the architecture. Hopefully, this will solve the problems we've been having with 3.7.11 where atlas' configure selects the wrong architecture for some CPUs. The main reason why I haven't unmasked this snapshot yet, is the fact that (at least) one of the source files contains assembly with absolute addresses leading to .text relocations on some CPUs with sse2/sse3 instructions, which will make this a show-stopper for amd64 at the moment. I've a patch to fix this for x86 but amd64 is still missing. Thanks, Markus (In reply to comment #41) > Hi Folks, > > I just bumped blas-atlas to 3.7.19 in portage. Is lapack-atlas 3.7.19 on the way? Will there be potential issues with lapack-atlas 3.7.17 co-existing with blas-atlas 3.7.19? (In reply to comment #41) > Hi Folks, > > I just bumped blas-atlas to 3.7.19 in portage. Is lapack-atlas 3.7.19 on the way? Will there be potential issues with lapack-atlas 3.7.17 co-existing with blas-atlas 3.7.19? (In reply to comment #43) > Is lapack-atlas 3.7.19 on the way? Will there be potential issues with > lapack-atlas 3.7.17 co-existing with blas-atlas 3.7.19? > You can only have one of the blas-atlas versions installed at a time (at least if you stick with portage since they are not slotted). To me, 3.7.19 looks like a pretty good release, the configure works well and if you were happy with 3.7.17 there should be no problems. 3.7.19 works very well for me on x86, the only issue remaining is a TEXTREL in one of the sse codes that kills generation of the shared objects on amd64; x86 should be fine. Best, Markus (In reply to comment #44) > (In reply to comment #43) > > Is lapack-atlas 3.7.19 on the way? Will there be potential issues with > > lapack-atlas 3.7.17 co-existing with blas-atlas 3.7.19? > > > > You can only have one of the blas-atlas versions installed at a time > (at least if you stick with portage since they are not slotted). but now emerge world complains because lapack-atlas-3.7.17 has blas-atlas-3.7.17 as dependency which is no more in the tree. maybe we need it back until lapack is upgraded to 3.7.19? @markusle: your cleanup broke this: 29 Oct 2006; Markus Dittrich <markusle@gentoo.org> -blas-atlas-3.7.17.ebuild, +blas-atlas-3.7.19.ebuild: Version bump to latest development snapshot. Ebuild now uses atlas' build system to select compiler and flags (see bug #144314). sci-libs/lapack-atlas-3.7.17: attr(depends): nonexistant atoms [ ~sci-libs/blas-atlas-3.7.17 ] (In reply to comment #46) > @markusle: your cleanup broke this: > > 29 Oct 2006; Markus Dittrich <markusle@gentoo.org> > -blas-atlas-3.7.17.ebuild, +blas-atlas-3.7.19.ebuild: > Version bump to latest development snapshot. Ebuild now uses > atlas' build system to select compiler and flags (see bug #144314). > > sci-libs/lapack-atlas-3.7.17: attr(depends): nonexistant atoms [ > ~sci-libs/blas-atlas-3.7.17 ] > Ooops - the new lapack was in my overlay but I apparently forgot to commit it. Anyway, lapack-3.7.19 just hit portage and all should be well. My apologies for any inconvenience. cheers, Markus Folks, I've just committed 3.7.23 to portage cvs. Clint did a great job with this one and I am very happy with it on the dev boxes I've got available. Furthermore, the direct references in some of the sse3 level1 blas assembly code are gone now and with them the text relocations. Please give it a spin and let me know if there are any problems. From my point of view, 3.7.23 is good to go ~ARCH and I will remove it from package.mask soon unless somebody reports any major issues. Thanks, Markus Hi Markus, (In reply to comment #48) > From my point of view, 3.7.23 is good to go ~ARCH and I will remove > it from package.mask soon unless somebody reports any major issues. Thanks for the bump. I have tested the new ATLAS and it emerged fine. No problems with linking to the IT++ library on my x86 (Pentium M 1.6GHz) platform. From my point of view, you can go ahead and mark it as testing on ~x86. BR, /ediap Hi Adam, Thanks for testing:) I'll give it a few more days and if all goes well 3.7.23 will be removed from package.mask. Best, Markus (In reply to comment #5) > I've a few issued regarding parallel builds to iron out, and > should be able to commit a testing ebuild to portage in a few days or so. Any news on this? It's been 4 months but src_compile still calls make rather than emake. =) (In reply to comment #51) > (In reply to comment #5) > > I've a few issued regarding parallel builds to iron out, and > > should be able to commit a testing ebuild to portage in a few days or so. > > Any news on this? It's been 4 months but src_compile still calls make rather > than emake. =) > In my experience, emake doesn't really work well with atlas' makefiles. E.g. passing -jx bombs in many cases and make spews a lot of unhappy warnings and simply defaults back to -j1. atlas does have its own parallel build system and currently auto detects (as of 3.7.14 I believe) the number of make jobs based on the number of CPUs/COREs. I will change the ebuild to have atlas instead use whatever is specified via MAKEOPTS rather than auto detect it. Having said that, I'd personally rather keep a plain make to not interfere with atlas build system. Best, Markus (In reply to comment #52) > In my experience, emake doesn't really work well with atlas' makefiles. > E.g. passing -jx bombs in many cases and make spews a lot of unhappy warnings > and simply defaults back to -j1. > atlas does have its own parallel build system and currently auto detects (as > of 3.7.14 I believe) the number of make jobs based on the number of > CPUs/COREs. I will change the ebuild to have atlas instead use whatever is > specified via MAKEOPTS rather than auto detect it. > Having said that, I'd personally rather keep a plain make to not interfere with > atlas > build system. We should at least be passing in other make options from MAKEOPTS such as -k, -s, -d with something like emake -j1 ... (In reply to comment #53) > (In reply to comment #52) > > In my experience, emake doesn't really work well with atlas' makefiles. > > E.g. passing -jx bombs in many cases and make spews a lot of unhappy warnings > > and simply defaults back to -j1. > > atlas does have its own parallel build system and currently auto detects (as > > of 3.7.14 I believe) the number of make jobs based on the number of > > CPUs/COREs. I will change the ebuild to have atlas instead use whatever is > > specified via MAKEOPTS rather than auto detect it. > > Having said that, I'd personally rather keep a plain make to not interfere with > > atlas > > build system. > > We should at least be passing in other make options from MAKEOPTS such as -k, > -s, -d with something like emake -j1 ... > Good point, Donnie! emake -j1 combined with passing MAKEOPTS to atlas' intrinsic build system should work fine. I'll commit this tonight. Best, Markus I didn't realize Atlas could do a parallel make. In any event, I only have uniprocessors and when I build Atlas, I usually shut down X and as much other stuff as possible to try to keep the megaflop timers accurate. That might be superstition on my part rather than a necessity, but the build takes long enough that I don't mind letting it have the machine to itself anyway. I've just unmasked version 3.7.23 of blas/lapack-atlas. Please open new bugs should there be any problems with these versions. Thanks to all for testing! Best, Markus |
The latest version of sci-libs/atlas is out. Guys, OK, 3.7.14 is out. Here's the changelog: * Fixes/updates to ATLAS config system: - Improved cpu throttling probe - Added compiler test so only compilers that work are chosen from defaults - Added simple C interoperation test - Fixed frontend/backend tmpnam collision prob (config[1,0].tmp) - Re-enabled parallel make support - Fixed buildinfo support - Added clock speed probe to config - Enabled "make time" to produce performance summary! - Added "make check" as alias to "make test" to make more like gnu --- OOOps, this isn't there, screwed it up, sorry Kate --- RCW - Fixed error in -Si nof77 1, which caused config to die w/o f77 compiler * Added new arch defaults for P4E[32,64]SSE3 and HAMMER64SSE3, which get better performance for gcc 4.2 (perf should still be OK for gcc 3). I'm guessing anybody with x86/linux or freebsd/OSX should be able to use this guy, though I've only get arch defaults for the above 3 systems. Note that if you get the newest gcc from SVN, you can get 93% of double precision theoretical peak using the code generator and the x87 unit on an AMD64! The big news there is that the final part of the new install is in place -- "make time" works! Here's what happens if you do an install yourself, or if your arch defaults don't have benchmark data: ******************************************************************************* NAMING ABBREVIATIONS: kSelMM : selected matmul kernel (may be hand-tuned) kGenMM : generated matmul kernel kMM_NT : worst no-copy kernel kMM_TN : best no-copy kernel BIG_MM : large GEMM timing (usually N=1600); estimate of asymptotic peak kMV_N : NoTranspose matvec kernel kMV_T : Transpose matvec kernel kGER : GER (rank-1 update) kernel Kernel routines are not called by the user directly, and their performance is often somewhat different than the total algorithm (eg, dGER perf may differ from dkGER) Clock rate=2800Mhz single precision double precision ********************* ******************** real complex real complex Benchmark % Clock % Clock % Clock % Clock ========= ========= ========= ========= ========= kSelMM 304.9 291.2 172.7 167.0 kGenMM 94.0 92.7 89.6 89.0 kMM_NT 75.2 75.6 67.9 70.5 kMM_TN 90.9 89.8 79.3 80.5 BIG_MM 290.1 275.0 164.6 162.2 kMV_N 33.8 129.3 32.7 43.1 kMV_T 49.3 46.4 30.8 44.7 kGER 34.3 66.2 17.0 32.9 ******************************************************************************* ******************************************************************************* Here's what happens if you have arch default data to compare against: single precision double precision ******************************** ******************************* real complex real complex --------------- --------------- --------------- --------------- Benchmark Refrenc Present Refrenc Present Refrenc Present Refrenc Present ========= ======= ======= ======= ======= ======= ======= ======= ======= kSelMM 346.2 356.3 344.8 338.7 182.1 182.7 177.2 177.7 kGenMM 177.7 182.7 144.4 154.6 169.0 154.9 150.8 173.4 kMM_NT 138.6 134.5 144.4 145.4 118.4 114.9 131.5 134.4 kMM_TN 141.5 154.9 135.9 142.5 144.9 134.5 142.0 145.4 BIG_MM 328.9 334.8 320.4 320.7 169.9 171.4 174.3 175.6 kMV_N 54.2 54.7 144.0 143.7 46.5 47.3 90.1 92.5 kMV_T 59.2 63.5 74.3 75.4 41.9 42.8 54.1 53.9 kGER 52.3 52.9 110.3 110.8 26.7 26.7 54.3 53.7 ******************************************************************************* The first times are a P4E64SSE3, and second HAMMER64SSE3. BTW, with the help of the gcc guys, I figured out why gcc could never vectorize any code, and my initial timings show you can get some speedup now. For AMD, the single precision speedup is significant. Intel gets only modest speedup. However, right now, ATLAS can't enable gcc's vectorization, because the gcc guys have made -funsafe-math-optimizations a mandatory flag to enable it, and this flag ruins IEEE compliance, which we can't do. I've got a bug report on this at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28684 Cheers, Clint ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Math-atlas-devel mailing list Math-atlas-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/math-atlas-devel