[gmx-users] intel compiler + amd64: help needed.
leafyoung81-group at yahoo.com
Wed May 31 22:51:22 CEST 2006
I can understand your sentiment after seeing these texts from Mars. I
shared the same when I was trying aggressive optimization (with Gentoo
Linux, FYI) and later with whatever software. But don't keep trying such
as it is not worthy the efforts you put (knowing the intrinsics of
system is generally not a bad idea, but keeping do so is wast of time).
I have used (very recently) ICC's profiled optimization and in exchange,
I have got back 5% performance with two complete compilation and many
profiled runs. It still isn't worthy because you lost agility and
generality (building software like GROMACS can be just done with a
script) and has a potential of incorrect result. Speed or stability, for
science, you shall know the answer. I have vowed to myself that's my
last quest for optimization (though I still got a handful switches for
Use GCC, support GNU/FSF! (my little propaganda =)
Jones de Andrade wrote:
> Hi all!
> Ok, got what should be done. But now I have a (big) question: this
> code compiles properly with gcc. Ok, maybe that means difference of
> tolerance between different compilers. But the code also compiles with
> intel on intel machines, and seems to work properly on older amd
> machines (not quite sure if they need to be so old that there is no
> SSE even).
> Is there any possibility the compiler is messing out with us somehow?
> Cause the same machine, different compilers, would mean bogus or
> something comiler, but same compiler, differente machines (or
> different cpu manufacturer?), seems to mean evil economics practices. :(
> Is there any chance this "suppositions" could be right? And so, it
> would be useless to try to crack our heads on "debugging" for one
> specific compiler the more optimized code of the world?
> Thanks for everything in advance.
> On 5/31/06, *David Mathog* <mathog at caltech.edu
> <mailto:mathog at caltech.edu>> wrote:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00002aaaab15a88c in __find_specmb () from /lib64/tls/libc.so.6
> > (gdb) where
> > #0 0x00002aaaab15a88c in __find_specmb () from /lib64/tls/libc.so.6
> > #1 0x00002aaaab140e6f in vfprintf () from /lib64/tls/libc.so.6
> > #2 0x00002aaaab15e2a9 in vsprintf () from /lib64/tls/libc.so.6
> > #3 0x00002aaaab149568 in sprintf () from /lib64/tls/libc.so.6
> > #4 0x000000000040248b in mknb_code (format=0x40cd2e "s") at
> > mknb_metacode.c:282
> This says that there's a call to sprintf() at mknb_metacode.c line
> 282. Just before that call check all the parameters that will
> be passed to sprintf. You can do that in the debugger, but you
> might find it easier to just put a bunch of printf's in at that point.
> Looks like there's a a bad pointer in there somewhere. Once you
> figure out which variable is bogus trace back up through the following
> code with the debugger (or more printf's)
> > #5 0x0000000000401aaf in mknb_declare_real (name=0x7fffffffd0d0
> > "ix1,iy1,iz1,fix1,fiy1,fiz1") at mknb_metacode.c:104
> > #6 0x0000000000403e62 in mknb_declare_variables () at
> > mknb_declarations.c:258
> > #7 0x0000000000400fef in mknb_write_function () at mknb.c:154
> > #8 0x00000000004017cf in main (argc=1, argv=0x7fffffffd628) at
> until you find out where things have gone wrong.
> David Mathog
> mathog at caltech.edu <mailto:mathog at caltech.edu>
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> gmx-users mailing list gmx-users at gromacs.org
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-users-request at gromacs.org.
> Can't post? Read http://www.gromacs.org/mailing_lists/users.php
More information about the gromacs.org_gmx-users