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