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 <[email protected]> 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/
