Hello!

I've written a floating point test, as a console application.  I do not display anything during calculations, only the result and elapsed time, after it completes.  The big surprise is that if I run it under WinME console window, it's 50% slower than if I run same EXE under "rxvt for Win32" from MSYS package (www.mingw.org).  And this happens with any console mode Win32 application, not only the ones that are compiled with DMC.  Now the weird part: DOS extended applications run with the same speed under both shells, there's no additional slow-down in the Win32 console.  I've also tried with Cygwin bash, and the slowdown is the same, therefore I assume it's related to the console emulation, and not to the fact that COMMAND.COM is a 16-bit DOS application.  Switching to full-screen doesn't change anything, either.

Did anyone else notice this problem?  Does this also happen on WinNT family
(Win2000/XP)?

Regards,
  Laurentiu

It could be a stack alignment issue. Check that the stack is aligned to 16 bytes on both. -Walter

"Laurentiu Pancescu" <user@domain.invalid> wrote in message news:acqu7p$k8g$1@digitaldaemon.com...
> Hello!
>
> I've written a floating point test, as a console application.  I do not display anything during calculations, only the result and elapsed time, after it completes.  The big surprise is that if I run it under WinME console window, it's 50% slower than if I run same EXE under "rxvt for Win32" from MSYS package (www.mingw.org).  And this happens with any
console
> mode Win32 application, not only the ones that are compiled with DMC.  Now the weird part: DOS extended applications run with the same speed under
both
> shells, there's no additional slow-down in the Win32 console.  I've also tried with Cygwin bash, and the slowdown is the same, therefore I assume it's related to the console emulation, and not to the fact that
COMMAND.COM
> is a 16-bit DOS application.  Switching to full-screen doesn't change anything, either.
>
> Did anyone else notice this problem?  Does this also happen on WinNT
family
> (Win2000/XP)?
>
> Regards,
>   Laurentiu
>
>

Thanks, Walter!  The difference seems unrelated to stack alignment, but I noticed that the DMC stack alignment problem isn't completely solved (DMC tries to keep 8-byte alignment, AFAIK).  Please try the enclosed demo:

"sc -o -6 -ff int1 main"  (or int2, or int3, it doesn't matter - all of them
are affected)

Here's the output of int1.exe:

Stack of main() 0x64fde8
Stack of integrate: 0x64fda4 --> misalignment generated by main()
Result is 6.93147e+06
Elapsed time: 1.719 s

If I compile for X32 (sc -o -6 -ff -mx int1 main x32.lib), I get:

Stack of main() 0xfff98fdc  --> note misalignment, maybe we should ask Doug
for para alignment?
Stack of integrate: 0xfff98f90 --> next misalignment makes things right  :)
Result is 6.93147e+006
Elapsed time: 1.32 s

It seems optimizing main() does something bad - everything is fine if you compile main.cpp with no optimizations.

Best regards,
  Laurentiu



"Walter" <walter@digitalmars.com> schrieb im Newsbeitrag news:acr3tk$ouk$1@digitaldaemon.com...
> It could be a stack alignment issue. Check that the stack is aligned to 16 bytes on both. -Walter
>
> "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:acqu7p$k8g$1@digitaldaemon.com...

Ok, I'll check it out. -Walter

"Laurentiu Pancescu" <user@domain.invalid> wrote in message news:acr9e6$t9k$1@digitaldaemon.com...
> Thanks, Walter!  The difference seems unrelated to stack alignment, but I noticed that the DMC stack alignment problem isn't completely solved (DMC tries to keep 8-byte alignment, AFAIK).  Please try the enclosed demo:
>
> "sc -o -6 -ff int1 main"  (or int2, or int3, it doesn't matter - all of
them
> are affected)
>
> Here's the output of int1.exe:
>
> Stack of main() 0x64fde8
> Stack of integrate: 0x64fda4 --> misalignment generated by main()
> Result is 6.93147e+06
> Elapsed time: 1.719 s
>
> If I compile for X32 (sc -o -6 -ff -mx int1 main x32.lib), I get:
>
> Stack of main() 0xfff98fdc  --> note misalignment, maybe we should ask
Doug
> for para alignment?
> Stack of integrate: 0xfff98f90 --> next misalignment makes things right
:)
> Result is 6.93147e+006
> Elapsed time: 1.32 s
>
> It seems optimizing main() does something bad - everything is fine if you compile main.cpp with no optimizations.
>
> Best regards,
>   Laurentiu
>
>
>
> "Walter" <walter@digitalmars.com> schrieb im Newsbeitrag news:acr3tk$ouk$1@digitaldaemon.com...
> > It could be a stack alignment issue. Check that the stack is aligned to
16
> > bytes on both. -Walter
> >
> > "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:acqu7p$k8g$1@digitaldaemon.com...
>
>
>

Hello Walter!

I forgot to tell you my DMC version: 8.28, I downloaded it yesterday (CD update).  It seems stack alignment works fine if I put everything in a single CPP file.

In this example, the performance improvement with proper alignment isn't that big, as you can see from X32 program output; probably because everything fits in the microprocessor's cache, and misaligned memory accesses are not performed inside the calcation loop.  Just a guess... :)

Regards,
  Laurentiu


"Walter" <walter@digitalmars.com> wrote in message news:acsikl$27pe$1@digitaldaemon.com...
> Ok, I'll check it out. -Walter
>
> "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:acr9e6$t9k$1@digitaldaemon.com...
> > Thanks, Walter!  The difference seems unrelated to stack alignment, but
I
> > noticed that the DMC stack alignment problem isn't completely solved
(DMC
> > tries to keep 8-byte alignment, AFAIK).  Please try the enclosed demo:
> >
> > "sc -o -6 -ff int1 main"  (or int2, or int3, it doesn't matter - all of
> them
> > are affected)
> >
> > Here's the output of int1.exe:
> >
> > Stack of main() 0x64fde8
> > Stack of integrate: 0x64fda4 --> misalignment generated by main()
> > Result is 6.93147e+06
> > Elapsed time: 1.719 s
> >
> > If I compile for X32 (sc -o -6 -ff -mx int1 main x32.lib), I get:
> >
> > Stack of main() 0xfff98fdc  --> note misalignment, maybe we should ask
> Doug
> > for para alignment?
> > Stack of integrate: 0xfff98f90 --> next misalignment makes things right
> :)
> > Result is 6.93147e+006
> > Elapsed time: 1.32 s
> >
> > It seems optimizing main() does something bad - everything is fine if
you
> > compile main.cpp with no optimizations.
> >
> > Best regards,
> >   Laurentiu
> >
> >
> >
> > "Walter" <walter@digitalmars.com> schrieb im Newsbeitrag news:acr3tk$ouk$1@digitaldaemon.com...
> > > It could be a stack alignment issue. Check that the stack is aligned
to
> 16
> > > bytes on both. -Walter
> > >
> > > "Laurentiu Pancescu" <user@domain.invalid> wrote in message news:acqu7p$k8g$1@digitaldaemon.com...
> >
> >
> >
>
>

"Walter" <walter@digitalmars.com> wrote in message news:acsikl$27pe$1@digitaldaemon.com...
> Ok, I'll check it out. -Walter

Gee... I hope you didn't get angry with me about this!  At least, does it also happen on your machine, when compiling my test programs?  I've noticed that stack is correctly aligned in many more programs (Win32 only, X32 it something different), so I'm not sure this wasn't just a special case.

Laurentiu

"Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adf86b$p60$1@digitaldaemon.com...
>
> "Walter" <walter@digitalmars.com> wrote in message news:acsikl$27pe$1@digitaldaemon.com...
> > Ok, I'll check it out. -Walter
> Gee... I hope you didn't get angry with me about this!  At least, does it also happen on your machine, when compiling my test programs?  I've
noticed
> that stack is correctly aligned in many more programs (Win32 only, X32 it something different), so I'm not sure this wasn't just a special case.

I'm annoyed with myself, not you, for there being a bug in the alignment process. I'm just glad you took the time to point it out and prepare a test case for me.

You got me scared for a moment! <g>.  I didn't create those small demos for testing alignment; I just read a nice article at www.oonumerics.org, about different strategies to achieve in C++ similar performance with that of FORTRAN.  And I wrote those 3 small programs, and compared the results (also between different compilers).

I hope you'll find that bug...

Oh, related to X32: do you have some docs related to what's required from an X32 drop-in replacement?  It seems the extender is no longer maintained, and maybe we could come up with an open-source, state-of-the-art one.

Regards,
  Laurentiu


"Walter" <walter@digitalmars.com> wrote in message news:adg5dm$1ot1$2@digitaldaemon.com...
>
> "Laurentiu Pancescu" <user@nowhere.near> wrote in message news:adf86b$p60$1@digitaldaemon.com...
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:acsikl$27pe$1@digitaldaemon.com...
> > > Ok, I'll check it out. -Walter
> > Gee... I hope you didn't get angry with me about this!  At least, does
it
> > also happen on your machine, when compiling my test programs?  I've
> noticed
> > that stack is correctly aligned in many more programs (Win32 only, X32
it
> > something different), so I'm not sure this wasn't just a special case.
>
> I'm annoyed with myself, not you, for there being a bug in the alignment process. I'm just glad you took the time to point it out and prepare a
test
> case for me.
>
>

"Laurentiu Pancescu" <user@domain.invalid> wrote in message news:adge5s$226v$2@digitaldaemon.com...
> You got me scared for a moment! <g>.  I didn't create those small demos
for
> testing alignment; I just read a nice article at www.oonumerics.org, about different strategies to achieve in C++ similar performance with that of FORTRAN.  And I wrote those 3 small programs, and compared the results
(also
> between different compilers).
>
> I hope you'll find that bug...
>
> Oh, related to X32: do you have some docs related to what's required from
an
> X32 drop-in replacement?  It seems the extender is no longer maintained,
and
> maybe we could come up with an open-source, state-of-the-art one.

There aren't any docs other than the library source code.