Inlining Code Test

Nick Voronin elfy.nv at gmail.com
Fri Dec 17 03:25:05 PST 2010


Looks like alignment of local variables is somewhat broken.

import std.stdio;

void main()
{
	int a;
	double d;
	writeln(&a," ", &d);
}

> testdl.exe
12FE70 12FE78

> testdl
12FE74 12FE7C

It's not like double is not aligned, otherwise it would be placed right  
after int, 4 bytes apart, but it is aligned with some assumption which may  
or may not hold depending on command line. Bug? I hope doubles _should_ be  
aligned by compiler?


On Fri, 17 Dec 2010 09:50:53 +0300, Nick Voronin <elfy.nv at gmail.com> wrote:

> Third... Now here is a funny thing. Absolute times and difference  
> between implementation depends on how do you run the program. I was  
> dumbfounded as of how does it matter, but the fact is that  
> aforementioned avg 5% difference I get if I run it with command line as  
> "inline.exe". If I run it as "inline" without extension I get difference  
> around 15% and absolute times are notably smaller.
>
>
> X:\d\tests\craig>inline.exe
> Sorting with Array.opIndex: 6533
> Sorting with pointers: 6264
> 4.11756 percent faster
>
> X:\d\tests\craig>inline
> Sorting with Array.opIndex: 5390
> Sorting with pointers: 4674
> 13.2839 percent faster
>
> Something like that. It's not a fluke. I tested it on my old AthlonXp  
> with XP SP2 and saw exactly the same picture (btw, difference in %  
> between implementation was about the same).
>
> I ran both variants under stracent and found no difference except one  
> pointer on the stack when LeaveCriticalSection and GetCurrentThreadId  
> are called was always off by 4 bytes. This made me thinking. The only  
> observable difference is length of command line. And indeed, renaming  
> program showed that only length of command line is a reason, not the  
> content.
>
> Further tests suggest that some value is either aligned to 8 byte or not  
> depending on length of command line and this makes all the difference  
> (which happens to be greater than difference between implementations of  
> sorting). I couldn't find what value causes slowdown though.
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list