📅 Original date posted:2012-06-19
📝 Original message:+list
On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell <gmaxwell at 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.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 10:17:34
in reply to nevent1q…nyym
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 10:17:34Event JSON
{
"id": "a428da9c1edad9614a9a3b49e1d298051a8ec6b3247051481de60267494736f9",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686133054,
"kind": 1,
"tags": [
[
"e",
"04f378001a224b61fbc2cdf06fef1e31477c4fe54d08e030aa71e61ff8312ae3",
"",
"root"
],
[
"e",
"7621a78a4e413784c33d60e208be7839d218b1e1d373cd9b5ce66ada37b7f63c",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-06-19\n📝 Original message:+list\n\nOn Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\u003e In addition to the ECDSA caching, ECDSA can can easily be run on\n\u003e multiple cores for basically a linear speedup.. so even with the\n\u003e checking in place once ECDSA was using multiple threads we'd be back\n\u003e to the DB being the bottleneck for this kind of case.\n\nMaybe ... looking again I think I may be wrong about being IO bound in\nthe last benchmark. The core running the main Bitcoin thread is still\npegged and the LevelDB background thread is only spending around 20%\nof its time in iowait. An oprofile shows most of the time being spent\ninside a std::map.\n\nOK, to make progress on this work I need a few decisions (Gavin?)\n\n1) Shall we do it?\n\n2) LevelDB is obscure, new and has a very minimalist build system. It\nsupports \"make\" but not \"make install\", for example, and is unlikely\nto be packaged. It's also not very large. I suggest we just check the\nsource into the main Bitcoin tree and link it statically rather than\ncomplicate the build.\n\n3) As the DB format would change and a slow migration period\nnecessary, any other tweaks to db format we could make at the same\ntime? Right now the key/values are the same as before, though using\nsatoshi serialization for everything is a bit odd.\n\nWe'd need UI for migration as well.",
"sig": "0aa97c2142bfbe51025b89baca1402742abd66e3abd88857c3586d28302c766daf501e34cd999c92b6a1892a3d4ec6e6eb49e9bc0b874a0824d72e4629dd99bc"
}