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.
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.
Do these suggestions work for you?
Tim
On Oct 4, 12:27 pm, Robert Roessler <[EMAIL PROTECTED]> wrote:
> 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]://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.
-~----------~----~----~----~------~----~------~--~---
