Wei Dai wrote:
> Robert Roessler wrote:
>> Hmmm. So how did the changes to iterhash.{cpp,h} which I rather you
>> hadn't made (since they made my exe larger and are now less clear than
>> previously) address this? And *why* did code size get worse?
>
> Before the changes, a number of template classes in iterhash.h were
> being instantiated into dll.obj. So when you use a hash function, the
> linker brings dll.obj into your .exe. dll.obj references iostream, so
> the linker also brings in iostream (even though it really shouldn't,
> because it only needs the iterhash template functions).
>
> Now, those template classes are instantiated into iterhash.obj, which
> doesn't reference iostream.
>
> I don't understand why it would cause code size to get worse for you. I
> wish the linker had an option that would produce some output explaining
> which pieces of code it's linking in, how big they are, and why (i.e.
> some kind of dependency graph), but it doesn't, so it's not obvious how
> to debug these kinds of issues.
"What we have here is a failure to communicate..." (immortal words if
there ever were any). :)
Everyone but me keeps wanting to talk about linkers and "optimizing
away" code... but remember, this thread started with and is still about
the slimmed-down SUBSET of Crypto++ which ONLY includes the .cpp files
listed in the original posting:
algparam.cpp, cpu.cpp, cryptlib.cpp, filters.cpp, md5.cpp, misc.cpp,
mqueue.cpp, queue.cpp, sha.cpp, and whrlpool.cpp.
The file dll.cpp never enters the picture!
So the situation I describe should be easier to understand, given that
we are not talking about the whole library body of code... so with the
exact same compiler and linker options, I have the following 2 cases:
1) using the current HEAD from the SVN repo, and ADDING iterhash.cpp to
the "cryptlite" project, the library ultimately yields a 739K exe.
2) forcing iterhash.{cpp,h} back to rev 375, REMOVING iterhash.cpp from
the project gives me a library which produces a 737K exe.
Since both the library and my client code are using the link-time code
generation option, you would [like to] think that the opportunities for
"optimizing away" code (to use your model) would be equivalent... but it
almost acts like with your "old" code (iterhash.{cpp,h} @ rev 375), the
source being included when the CLIENT is compiled rather than in the
library is giving better exploitation of code-removal possibilities (or
other source-sensitive optimization).
Actually, I hope it is something else...
>> Something about CRYPTOPP_MANUALLY_INSTANTIATE_TEMPLATES would be cool
>> and a) what it does in general, and b) why does code get smaller if I
>> define it on the CLIENT side? It even reduces some of the extra size
>> introduced by the iterhash.{cpp,h} changes - but doesn't get rid of all
>> of it.
>
> CRYPTOPP_MANUALLY_INSTANTIATE_TEMPLATES changes the definitions of a
> number of macros in config.h. When it is not defined, certain templates
> are not instantiated. When it is defined, those same templates are
> explicitly instantiated. If you define it in a .cpp file in your own
> application, it causes those templates to be instantiated into the .obj
> file compile from that .cpp file, so the linker no longer has to look
> for it in cryptlib.lib. I guess that reduces code size because when the
> linker was linking in the templates from cryptlib.lib, it was also
> linking in other unneeded code.
This latter is what I opined might be happening at the end of my
September 24 response to the poster formerly known as "Parch". ;)
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.
-~----------~----~----~----~------~----~------~--~---
