Hi, Jones
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
gcc now)
Use GCC, support GNU/FSF! (my little propaganda =)
Regards,
Yang Ye
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.
Jones
On 5/31/06, *David Mathog* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
mknb.c:348
until you find out where things have gone wrong.
Regards,
David Mathog
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Manager, Sequence Analysis Facility, Biology Division, Caltech
------------------------------------------------------------------------
_______________________________________________
gmx-users mailing list gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
_______________________________________________
gmx-users mailing list gmx-users@gromacs.org
http://www.gromacs.org/mailman/listinfo/gmx-users
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [EMAIL PROTECTED]
Can't post? Read http://www.gromacs.org/mailing_lists/users.php
