Re: [Monotone-devel] heads up on nvm.stripped
On Thu, Nov 13, 2008 at 05:26:48PM +0100, Markus Wanner wrote: > I fear the #ifdef's are not quite enough. We'd have to check for the > botan version dynamically. So I'd say we better wait a bit until that > API stabilizes. Many of the changes in the last few releases were made specifically with regards to what mtn needs re SHA-1, since mtn has been a sort of acid test application so far in terms of botan's performance abilities. So hopefully they will actually prove useful in Monotone. But waiting for 1.8 to be released and widely included in distros doesn't seem like a bad idea. > ..or even store the setting in _MTN/options because such a benchmark > might not pay-off every time mtn is invoked. Alternatively have it > stored in monotonerc and set as a system config during installation of > monotone. Storing in _MTN/options sounds easier to automate, so I'm > currently favoring that variant. Good point, I had not considered caching the result but that does make sense. I like _MTN/options for this. benchmark_sha1 could optionally update _MTN/options with the fastest provider. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] heads up on nvm.stripped
Hi, Jack Lloyd wrote: > I've attached a patch for sha1.cc demoing the new benchmark code. Very cool, thank you. FYI, my Core (1) Duo reports: mtn: Benchmarking botan's SHA-1 core mtn: SHA-1 provider 'core': 117.172 MiB/s mtn: SHA-1 provider 'ia32': 135.325 MiB/s > For > informative purposes only, since it currently only works on an > unreleased version (future 1.7.22, nrb head), and API-wise things are > still in flux in this area. That's fine. I fear the #ifdef's are not quite enough. We'd have to check for the botan version dynamically. So I'd say we better wait a bit until that API stabilizes. > In the future it may be useful to extend Monotone to run a quick test > and then choose the fastest SHA-1 provider to use for the rest of the > program run. 20 milliseconds of benchmark time at startup could pay > for itself quickly in many cases. ..or even store the setting in _MTN/options because such a benchmark might not pay-off every time mtn is invoked. Alternatively have it stored in monotonerc and set as a system config during installation of monotone. Storing in _MTN/options sounds easier to automate, so I'm currently favoring that variant. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
