Tim Lovell-Smith wrote:
> Yes, I have made my own cryptlite project, based on the cryptlib
> project, and separate project for the exe. I will post a few numbers,
> which I should have done last time.
>
> First, baseline cryptlite command line & exe command lines before
> Wei's changes (with the best parameters I tried):
>
> /O2 /Ob2 /Oi /Os /Oy /GL /D "NDEBUG" /D "_WINDOWS" /D "WIN32" /D
> "_VC80_UPGRADE=0x0600" /GF /FD /EHsc /MT /Gy /Fp".\Release/
> cryptlib_lite.pch" /Fo".\Release/" /Fd".\Release/" /W3 /nologo /c /Zi /
> TP /errorReport:prompt
>
> /O2 /Ob2 /Oi /Os /Oy /GL /I "../CryptoCPP" /D "WIN32" /D "NDEBUG" /D
> "_CONSOLE" /D "_UNICODE" /D "UNICODE" /GF /FD /EHsc /MT /Gy /Fo"Release
> \\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /
> errorReport:prompt
>
> You can see a few differences, but importantly optimization parameters
> are the same between projects. The exe code is the minimal hashing
> example at the top of the thread. Result: an 80 kb exe (81,920 bytes
> according to explorer).
>
> Now I (manually) add iterhash.cpp to the lib project and apply Wei
> Dai's patches to iterhash.{h,cpp}, and rebuild the entire solution
> (lib and exe). Result: an 80kb exe
>
> This is a negative result if you will - the patch is not yet proven to
> affect code size at all, with the same settings between projects.
>
> Now, keeping Wei Dai's patch, I one by one change my exe optimization
> settings closer to what you describe:
> set /Ob1 for the exe -> 80.0 KB (81,920 bytes, a suspiciously round
> number)
> set /Ob1 and /Ox for the exe -> the same, 80.0 KB (81,920 bytes)
>
> Next step, I change the favour fast/small code option in the cryptlib
> project settings to 'Neither' -> 84.0 KB (86,016 bytes).
>
> OK, so far, if you're with me, I have increased code size, but I
> haven't proven a positive result: that the patch affects code size
> when you have different settings, so I need one last experiment: keep
> the optimizations constant with the last experiment, and undo the
> patch. Note that with the patch, the 'lib' project's optimizations
> will apply to iterhash.cpp code, not the 'exe' project's. Result ->
> 83.5 KB (85,504 bytes).
>
> A positive result if you will. The patch is shown to affect code size
> -- WITH different settings between projects. Because which project it
> gets built in changes.
>
> A final experiment: override the per .cpp file optimizations on
> iterhash.cpp, and put it back to 'favor small code', which should have
> the same effect as reversing wei's patch.. result: -> 84.0 KB (86,016
> bytes), as expected.
So (after an absence), it would appear from my results and your
exhaustive analysis that the Crypto++ library would be better left the
way it was (WRT iterhash.{cpp,h}, anyway), in that it gives the library
user more control of how the code is actually generated... and if the
user has said that they would [e.g.] rather favor size over speed, then
the more code of the library that is left "exposed" this way (getting
compiled with client apps), the more this can happen.
So I will renew my request of Wei Dai to please revert the
iterhash.{cpp,h} changes, given that
a) it's not clear that the problem they were trying to solve needed to
be solved or was requested to be solved,
b) it's not clear that they had the intended effect in any case, and
c) it does seem clear that they *can* have a deleterious effect on
Crypto++ client apps
> On Oct 5, 7:53 pm, Robert Roessler <[EMAIL PROTECTED]> wrote:
>> Tim Lovell-Smith wrote:
>>> I think I was wrong before. It isn't whether the linker is discarding
>>> functions or not - it's the code generation.
>>> If I apply Wei's changes, AND am careful to have exactly the same C/C+
>>> + options enabled in my .exe project as my .lib project, I get exactly
>>> the same output .exe size.
>> I have been careful about holding everything constant *except* the most
>> recent changes to iterhash.{cpp,h} - and observe the 2K change as reported.
>>
>> I do NOT have identical options in my client project as the "cryptlite"
>> static lib project - but they are quite close. My client settings are
>> what they are for historical reasons, and the "cryptlite" settings are
>> duplicated so as to match the main Crypto++ settings.
>>
>> They match in all the key particulars: multi-threaded NON-dll, linker
>> code generation, omit frame pointers, enable intrinsics... the library
>> uses -O2 and "any suitable" for inline expansion, favor size or speed is
>> "neither". My client uses -Ox and "only __inline" along with "favor
>> small code". And everyone is using -Gy for function-level linking.
>>
>>> Also, telling the optimizer to optimize for speed, but favour size
>>> over speed (weird how you can do that) shaves off a few more KB.
>> I have been using this for quite some time... I guess I have assumed it
>> means if multiple sequences could be emitted that are *close* in speed,
>> use the smallest one (whereas if there is a larger expected difference
>> in speed, use the faster version even if it is larger).
>>
>>> Do these suggestions work for you?
>> See above comments... ;) As a reality-check, what are actually using as
>> a test bed for comparison? Have you created your own version of the
>> "cryptlite" static lib project in your Crypto++ working copy tree?
Thanks to Wei Dai and Tim Lovell-Smith for the time and thought that has
gone into this issue/puzzle (and its explanation/solution). :)
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to [EMAIL PROTECTED]
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
-~----------~----~----~----~------~----~------~--~---
