[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] botan 1.7.3

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] botan 1.7.3
Date: Sun, 17 Feb 2008 18:13:28 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)

Hello Zack,

I've just started to play around with both variants. Again, I've quickly given up trying to include the amd64 specific assembler code into our I just didn't feel like duplicating all that build script magic, especially as I'm not exactly an autoconf/automake guru.

Thus, I've also tried the other approach: adding a --with-system-botan. That was surprisingly straight forward. Please see revision

f508410fff79cdd69fb77d248791abc99f344dcb address@hidden 2008-02-17T16:13:10 net.venge.monotone.botan.system-switch

You can pull that from my server

Zack Weinberg wrote:
I've been thinking about this a bit myself, because the Debian
security people would really like us to stop using *all* of our
bundled libraries, so that when a security issue hits one of them they
can just upgrade the shared library and be done.

Another nice point for using shared libraries, yes.

Also, hardcoding the configuration parameters for all the bundled
libraries doesn't just preclude use of Botan engines, it was the
proximate cause of some 64-bitness headaches with sqlite a while back
and a weird Windows issue with pcre that I still don't really
understand.  It would be nice to incorporate the upstream build
systems (and testsuites!) for the bundled libraries.

Hm.. and then, i.e. calling botan's own during our own configure run? That could work, although it sounds like a lot of trouble as well.

The vague plan I've got is to give each bundled library a top-level
directory which contains as near as possible a verbatim import of the
most recent upstream tarball.  Our own source code moves to a
subdirectory, and there's a top-level configure script that
coordinates building all the bundles that are not overridden by
--with-system-foo, then our own code.  This lets us use -I switches to
reference the headers for only those bundled libraries we're actually
using.  [Right now, for instance, I think we're getting the bundled
pcre.h even if we don't use the bundled library.]

Yeah, I've run into the very same problem with botan. Solved it by moving botan/* to botan/botan/*, which was the quickest solution, but really isn't that nice.

There are still some problems I'm investigating on. Seems like botan 1.7.3 is having trouble on ia32.

Also note, that the m4 script is still lacking. However, I can run some benchmarks, to check if it's worth the effort. Here are some results, all compiled with -O2, the asm optimization is the one linked against the (debian) system provided botan (1.7.2, notably), while the other one is plain C++ code from the provided botan 1.7.3:

My work machine, a Core 2 Duo:
amd64 c++: 144.93 MiB/s
amd64 asm: 156.25 MiB/s   (7.8% increased throughput)

My laptop, a Core (1) Duo:
ia32 c++: 90.90 MiB/s
ia32 asm: 98.03 MiB/s   (7.8% increased throughput, too)

It would be interesting to test on an AMD machine as well.

Note, that there's no relevant difference in botan's SHA1 code between 1.7.2 and 1.7.3, so that really shouldn't matter. Quick testing also gave the same results.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]