🚀 go-pugleaf

Andrue Cope [TeamB] wrote:

>  long double bigNumber=*( sourceDate++ );
>
>  for( WORD l1=1;
>       l1<8;
>       ++l1,++sourceDate )
>    bigNumber+=( pow( 2, ( long double )( ( l1*8 ) ) )*( *sourceDate )
>);
>  long double secondsSince1601=bigNumber/10000000L;
>....
>
>It occurred to me that replacing this with
>
>void NTDate2APC( BYTE         *sourceDate,
>                 TAPCDateTime *targetDate )
>{
>  QWORD secondsSince1601=
>    ( *reinterpret_cast<QWORD *>( sourceDate ) )/10000000ui64;
>
>would offer a performance improvement.
>
>It doesn't. In fact it gives a performance hit. On my standard NTFS
>test image the old code averages 38 seconds over ten runs. The new code
>averages 34 seconds over ten runs.

The first version uses the FPU which overlaps it's execution with the
cpu, so some of the divide time is "free" while the 
cpu continues on with whatever the ...  entails.
The second method uses 64bit integer division which is quite slow on a
non-64bit cpu.  (As an exercise, try dividing two 16 bit numbers using
only 8 bit registers. Or, with paper and pencil, divide two 4 digit
numbers, looking at only 2 digits at a time. Multiply, not so bad, but
divide is a bear.)
The FPU is also a >64bit unit, so it can handle the division speedily.

>I can appreciate that empirical testing is going to be innaccurate but
>the results seem pretty clear cut. I just don't see how the original
>code can be faster.

The new code will be faster in the future  :-)