Sigh, I was hoping you would change your mind, Robert, from what I
found. I will try to explain why. Firstly, I still think this change
is a positive one because
1) it increases the transparency of compilation behaviour (functions
get compiled in the .cpp file they are defined in)
2) the transparent compilation behaviour and /also/ the fact the
define doesn't have to be fudged any more by the client code makes it
easier to modify Crypto++, which would be useful for making 'lite'
crypto++ projects, or just hacking at and improving the crypto++ code
in general.
There are a few other places where
CRYPTOPP_MANUALLY_INSTANTIATE_TEMPLATES is used, e.g. ecccrypto.cpp.
If all these were made the same as the iterhash.{h,cpp} both these
benefits would apply even more widely. This would e.g. make it easier
for me to compile an elliptic curve cryptography specific crypto++
(something I am considering doing for my own project, as it happens).
On the other hand, you claim there is a deleterious effect, which
could cancel out the positives. I have been trying to figure out what
this effect is, and my conclusion is that there isn't really any. If
you want the smallest compile possible, you can modify the per-file
compilation settings for iterhash.cpp (right click, properties in
Visual Studio) and adjust them to whatever does the best job of
minimizing the final code size. You can even take this to the extreme
and tweak with the settings for every file in crypto++ until you have
the exe at its minimum size.
Finally, I think its important to consider that whether other users
would benefit from the changes you are asking for to crypto++ is
overall unproven. You have a special interest in small file sizes. But
other people might have a special interest in e.g. long-run throughput
performance. Not to mention, the size effect with different compilers
might be entirely different. For crypto++ to place special weight on a
2kb file size change in the face of unknown effects in the other
dimensions of performance doesn't seem sensible to me.
In summary, yup, Crypto++ aims at optimizing performance a lot of the
time. But I think it is most important for Wei to provide a generally
useful library. The degree of tweaking which you are doing is best
left up to the end-user.
On Oct 13, 1:29 pm, Robert Roessler <[EMAIL PROTECTED]> wrote:
> 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]://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.
-~----------~----~----~----~------~----~------~--~---
