+list On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote: > In addition to the ECDSA caching, ECDSA can can easily be run on > multiple cores for basically a linear speedup.. so even with the > checking in place once ECDSA was using multiple threads we'd be back > to the DB being the bottleneck for this kind of case.
Maybe ... looking again I think I may be wrong about being IO bound in the last benchmark. The core running the main Bitcoin thread is still pegged and the LevelDB background thread is only spending around 20% of its time in iowait. An oprofile shows most of the time being spent inside a std::map. OK, to make progress on this work I need a few decisions (Gavin?) 1) Shall we do it? 2) LevelDB is obscure, new and has a very minimalist build system. It supports "make" but not "make install", for example, and is unlikely to be packaged. It's also not very large. I suggest we just check the source into the main Bitcoin tree and link it statically rather than complicate the build. 3) As the DB format would change and a slow migration period necessary, any other tweaks to db format we could make at the same time? Right now the key/values are the same as before, though using satoshi serialization for everything is a bit odd. We'd need UI for migration as well. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
