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.
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?
>
> Robert Roessler
> [EMAIL PROTECTED]://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.
-~----------~----~----~----~------~----~------~--~---
