[gmx-developers] MASM assembly syntax

[Erik Lindahl]

Hi,

I would also be _extremely_ surprised if there was any significant  
difference with a different assembler :-)

Per definition, the assembler just translates the instruction  
mnemonics to binary opcodes, so apart from some minor stuff (like  
macro expansion and constants) the generated code should be identical.

x86 is also a bit special since it has extremely good dynamic  
instruction scheduling, so there isn't really much to gain by smarter  
ordering of the assembly instructions either (god knows we've tried,  
though :-)

The compiler can have a huge influence on neighborsearching, though,  
and to a lesser extent particle-mesh-ewald, so you might see a  
slightly larger effect e.g. on a big ion channel system (less water,  
complex molecules).

On the other hand, I never believe compiler vendors' performance  
claims. My guess is that you'd only see 25% difference on a code that  
was completely unoptimized and horribly written to start with :-)

Cheers,

Erik



On Jul 30, 2007, at 2:59 PM, Mark Abraham wrote:

> chris.neale at utoronto.ca wrote:
>> This is not a particular request, but may be an interesting  
>> starting point for those wanting to tweak the speed of gromacs.  
>> This thread seemed like a reasonable place to post this information.
>> Regarding compilers, what about Sun Studio 12 (for linux boxes)?  
>> They tell our sys admin that they can acheive 25% faster runs than  
>> icc or gcc. However, their assembler doesn't handle the gromacs  
>> assembly code. I have assembled the assembly portion using gcc and  
>> then compile using sun studio by escaping the initial (see mothod  
>> at end). It runs fine, but doesn't go any faster than gcc alone.
>
> This isn't surprising. If you look at the statistics printed at the  
> end of typical gromacs runs, the large majority of the run time is  
> spent in those assembly inner loops. That's why the developers have  
> gone to town optimizing there. Everything else in the C code is  
> just so much glue for those inner loops. Thus the extent of the  
> return for any better compiler is strictly limited.
>
> Also, if you want to actually produce useful benchmarks as a  
> function of C compiler, you'll want to quote compiler version  
> numbers and what optimization flags configure was using for each of  
> them. Better still is to use the GROMACS benchmark suite, so people  
> also know how long the simulations were that produced your rates.
>
> Mark
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the www  
> interface or send it to gmx-developers-request at gromacs.org.