added support for blas-atlas lapack-atlas + some other enchantments Reproducible: Always
Created attachment 131706 [details] New gromacs ebuild
Unified diff against current ebuild, please.
Created attachment 131707 [details, diff] patch against portage version
Created attachment 131866 [details] Updated ebuild Updated ebuild to state closer to current portaeg state
Created attachment 131867 [details, diff] patch against portage fo updated ebuild
Compiling gromacs with blas-atlas and lapack-atlas give us about 10% of performance PS There are no reaseon to build 4! versions of gromacs single double mpi_single mpi_double. We only need one version. Everybody can deside what actuali version does he need =)
http://www.gromacs.org/ By the way Yesterday gromacs 3.3.2 was realeased
I'll hook it up when I get some time.
Created attachment 134104 [details] Updated ebuild (In reply to comment #7) > http://www.gromacs.org/ > > By the way > Yesterday gromacs 3.3.2 was realeased > Unfortunately they have no changelog at all, but the sse-type seems to be fixed now. I changed your ebuild accordingly and it works on my amd64 box. I noticed, that the mpi version is now the only one and has no special suffix anymore if one compiles with USE="mpi"... I'm not sure if this is desired by all users.
(In reply to comment #9) > Created an attachment (id=134104) [edit] > Updated ebuild > > (In reply to comment #7) > > http://www.gromacs.org/ > > > > By the way > > Yesterday gromacs 3.3.2 was realeased > > > > Unfortunately they have no changelog at all, but the sse-type seems to be fixed > now. > I changed your ebuild accordingly and it works on my amd64 box. I noticed, that > the mpi version is now the only one and has no special suffix anymore if one > compiles with USE="mpi"... I'm not sure if this is desired by all users. > well, mpi version can function as a serial one if it invoked without mpiexec =) at least with mpich2 and mvapich2 so it is not necesary to build more then one version of mdrun binary most of gromacs users uses double precision version =) and this version is recomended
please do not put this ebuild in the tree. we need two versions of mdrun. the single precision version is the default one. it runs more than 50% faster than the double precision version(at least on x86). the only reason to use double precision version is if your system crashes because of numerical instability. (In reply to comment #10) > well, mpi version can function as a serial one if it invoked without mpiexec thats true, i've checked this. this was not the case before 3.3. so i think we can drop the mpi versions and provide only one mdrun executable for each precision. > so it is not necesary to build more then one version of mdrun binary no > most of gromacs users uses double precision version =) nearly no one uses doule precision at our place > and this version is recomended who recomends this? i will write an ebuild for 3.3.2 which includes the external blas and keeps the multiple precision version. unfortunately this has to wait until wednesday.
(In reply to comment #11) > please do not put this ebuild in the tree. we need two versions of mdrun. the > single precision version is the default one. it runs more than 50% faster than > the double precision version(at least on x86). the only reason to use double > precision version is if your system crashes because of numerical instability. > (In reply to comment #10) > > well, mpi version can function as a serial one if it invoked without mpiexec > thats true, i've checked this. this was not the case before 3.3. so i think we > can drop the mpi versions and provide only one mdrun executable for each > precision. > > so it is not necesary to build more then one version of mdrun binary > no > > most of gromacs users uses double precision version =) > nearly no one uses doule precision at our place > > and this version is recomended > who recomends this? > > i will write an ebuild for 3.3.2 which includes the external blas and keeps the > multiple precision version. unfortunately this has to wait until wednesday. > Yes on x86 single precision version two times faster but on x86_64 it has the same speed single precision version may be build throu addding use flag single-prcision so peple that want two versions must set two USE flags single-prcision double precision since building four(!) or two(!) versions by default its annoying
Most people use single-precision, so I won't be changing the ebuild in this regard. Adding blas/lapack will be interesting.
(In reply to comment #12) > Yes on x86 single precision version two times faster > but on x86_64 it has the same speed i can not reproduce this. according to my benchmarks the double precision version is 40% slower on x86_64(athlon64 X2) > single precision version may be build throu addding use flag single-prcision unfortunately there is no use flag for single-precision > since building four(!) or two(!) versions by default its annoying we can drop the mpi versions. that means if you want to have double precision you need to build two versions. if building gromacs is annoying to you im wondering how often you build gromacs. i have finished the ebuild for 3.3.2. it passes the test cases from the gromacs test set on amd64 in single and double precision in serial and parallel but fails in some cases on x86. i try to find the problem. then i will integrate the modifications for external blas and lapack. this needs some time, because i have to make sure that the binaries produce correct results. so please be patient.
i have done some testing, revised the current 3.3.1 ebuild and integrated the blas and lapack use flags. i will now explain the changes: - i included flag-o-matic because if no use CFLAGS are set gromacs is build with "-O3 -inline-functions -funroll-all-loops" and on x86 additionally "-malign-double" which results in 10% faster binaries compared to "-O2 -march=xxx" -i removed the compilation of the inner loops with fortran in case no assembler is used. inner fortran loops are slower than assembler and only faster than c loops if you have a high performance fortran compiler which unfortunately gfortran is not. - i removed binutil dependency because binutil is in system and should be recent enough on all systems - i added virtual/blas and virtual/lapack to DEPEND and modified IUSE - i removed the special mpi versions of mdrun. if mpi is in USE flags mdrun will be build against mpi. mdrun is also able to run serial if invoked without mpirun/mpiexec. - if double-precision is in USE than the whole program is build again with and suffixed with _d i will attach the ebuild and a diff against the current ebuild in the tree. btw, i didn't find any performance improvement with blas or lapack, but everyone can try this on his own. i also did some tests with 3.3.2 and 3.3.2 only runs fine on amd64 and segfaults on x86.
Created attachment 137105 [details] gromacs-3.3.1-r2.ebuild
Created attachment 137106 [details, diff] patch against 3.3.1-r1
(In reply to comment #15) Why we stil build two versions of gromacs? may it will be better if user can chose what he need? only double precision, only single or both versions? BTW on 64bit arches single precisin doesnt make any sense since native precision is double... There are only diffremce for 32bit arches (about 2x slower if we use double precision)
(In reply to comment #18) > (In reply to comment #15) > > Why we stil build two versions of gromacs? Because benchmarks show that single precision is adequate most of the time. Many people who use 64bit processors find that the single-precision code is faster, and that the level of error is quite tolerable. (1 in 10^6 or so) To me, it doesn't make any sense to change the established ebuild behavior.
Created attachment 137179 [details] modifyed multiprecision gromacs 3.3.2 Ok this ebuild provide ability t build both single and duble precision if you enable only one use flag only one version will be build =)
Created attachment 143119 [details] gromacs-3.3.2-r1.ebuild New improved version of gromacs ebuild This version has abbility to choose gromacs version with USE=single-precision it build single version of gromacs with USE=double-precision it build double version of gromacs without binnary suffixes but if both use set then it build single version without suffix and double version with suffix _d
Created attachment 143122 [details] gromacs-3.3.2-r1.ebuild Typo fix in previous ebuild =) + some cosmetic and style changes =)
Created attachment 143126 [details] gromacs-3.3.2-r1.ebuild repoman warnings fixed =)
Created attachment 145087 [details] gromacs-3.3.3.ebuild GROMACS-3.3.3 Released (Bugfix Release) New ebuild attached
*** Bug 223119 has been marked as a duplicate of this bug. ***
Created attachment 154703 [details] gromacs-3.3.3.ebuild ebuild that defaults to single
Created attachment 154705 [details] gromacs-3.3.3-r1.ebuild same one but with eselect mpi support =)
i will have a look in the ebuild an write what i think about it: first of all we want to have single precision by default and double by use flag. this is the case now. now we can also prevent the installation of single precision by use flag which is more flexible than before. thats why i think it is a good idea. in the src_unpack() function we find: epatch "${FILESDIR}"/"${PN}"-ppc64-altivec.patch this tries to patch a file include/ppc_altivec.h which is not in in the source tree. so the ebuild will fail?? (don't know exactly how epatch handle this case) on ppc and i think we can remove this. in the part for the different precision source trees you copy two times and in the end delete the source. why not move one time and copy one time?
the next question would be: how should we handle fortran? i don't believe that anyone really wants to have the inner loops compiled by fortran, while assembler is available. and in the case of amd64 and ia64 assembler is selected by default. the --enable-axp-asm seems not to be in gromacs any more. so we should delete it. asembler is available for x86, amd64, ppc and ia64. is there a reason why we should keep fortran?
Created attachment 154823 [details] my suggestion for gromacs-3.3.3.ebuild this works at least on amd64 for single and double precision. i have not tested with system blas and lapack, because it was not fast wit external blas and lapack in the past. please note, that with changing the path for symolic links of libraries in tools/Makefile.am the sandbox violations still occur on my system. one has to modify them in tools/Makefile.in i will now test on x86, because there used to be segfaults with 3.3.3 on x86 during the runs of the gmxtest set.
only a short comment for x86: it still segfaults in the gmxtest set
Hey guys, With your help I'm dropping a new gromacs-3.3.3.ebuild in the science overlay. Here are some thoughts... Since the mpi.eclass probably won't make it into the tree until after the gromacs update, I can't use it yet. I'm pretty sure mpi in the ebuild needs some help, but it has been a long day :) I didn't see configure overwriting any user CFLAGS so I commented out the append-flags stuff. I haven't tested the blas or lapack stuff at all. Thanks, and Good Luck! je_fro
(In reply to comment #32) > Hey guys, > With your help I'm dropping a new gromacs-3.3.3.ebuild in the science overlay. > Here are some thoughts... > Since the mpi.eclass probably won't make it into the tree until after the > gromacs update, I can't use it yet. I'm pretty sure mpi in the ebuild needs > some help, but it has been a long day :) > I didn't see configure overwriting any user CFLAGS so I commented out the > append-flags stuff. > I haven't tested the blas or lapack stuff at all. > > Thanks, and Good Luck! > je_fro > ebuild from science overlay brocken in some ways version that i posted here works for example if you try to merge ebuild from overlay with USE="-single-precision double-precision" emerge -v1 gromacs then it will fail in install phase since my hoocks was modyfyed
Created attachment 159596 [details] gromacs-3.3.3.ebuild new one ebuild it works so please put it into science overlay
Moving to portage tree.
