Bitcoin full node and query server
Oct 25, 2024
View in context in the libbitcoin Slack #general mirror.
evoskuil21:29
Still seeing a high level of starvation in the Linux build, similar to previously with
(edited)maximum_concurrency = 0. But the stall and lack of events are resolved. I don't have any tools set up for concurrency and performance analysis on Linux, so I've probably gotta work that out. Setting up my monster mac now also.
In the mean time I pulled down Bitcoin Core latest Linux binary to get a benchmark. It's doing significantly better than it did on the same box for a Windows build (15 hours). After 30 minutes it's completed about 10% of the chain (by txs), and projecting 6 hours (and falling). So will probably hit 5 hrs. Interesting how it can be 3x longer on the same box for Windows vs. Linux.25 replies · Antoine Poinsot, evoskuil, cguida, parsevalbtc · last Oct 29, 2024
evoskuil22:18
Today is the first time I've attempted a Linux sync with the v4 architecture. I work almost exclusively on Windows, because of the tooling, and because my habit patterns were set well before Linux existed. 😅
I think that Core still builds for Windows using mingw, which is sort of an afterthought approach, and only supports CMake now. We support native Windows (msvc/win32), macOS (clang/xcode), Linux (gcc/clang) with generated build artifacts, CI/coverage and build scripts for Automake and CMake, native VC++ solutions for Visual Studio Community, and presets for VSCode. If we had CI platforms for Big Endian and for ARM we'd have those supported too (working on it).
👀 1
A
Antoine Poinsot22:20
I think Core has a msvc build system, but i'm not the right person to ask about it. 🙂
evoskuil22:20
So I'm not at all surprised that my Linux box is not < 1hr yet. I was happy just to see it complete a sync the first time it was ever attempted!
evoskuil22:21
Actually, yes, I think that was a product of switching to CMake, since it can generate a msvc build. Not sure if the latest binaries are built with that, but seems to be a pretty significant difference.
A
Antoine Poinsot22:23
We switched to cmake after the branch-off for v29 (the latest release). But i'm pretty sure there was already a msvc build supported. But maybe not for releases, i'd have to check.
👍🏻 1
A
Antoine Poinsot14:37
Sharing your bench on Core's IRC i got more info about that FWIW.
10:31 <laanwj> and it makes sense, bitcoind is optimized for various POSIX platforms, not windows, which is different in many aspects; for example leveldb, doesn't even really support windows by itself; the win32 API backend it uses is something i worked on. also the P2P networking doesn't use any i/o polling primitives optimized for windows. Disk i/o is also slower on a lot of windows machines due to windows defender etc getting in the way. To get any level of 10:31 <laanwj> performance there would need a lot of work. Still, it shouldn't be that slow... 10:34 <laanwj> compiling with MSVC instead of mingw also used to be an improvement in speed, but this was 2013, no idea about now, and we can't use that in deterministic builds anyhow 10:36 <hebasto> MSVC builds lack HW-acceleration for SHA256 -- https://github.com/bitcoin/bitcoin/pull/24773 10:36 <darosior> He did mention MSVC vs mingw and i quickly got out of my depth. :) 10:36 <darosior> What do we use for release builds? 10:36 <hebasto> mingw 10:36 <laanwj> mingw, because that's the only thing we can use in side guix 10:36 <laanwj> well we could use clang that would be something to investigate, many seem to prefer that for windows nowadays 10:37 <hebasto> right
👍🏻 1
evoskuil14:44
Thanks, good read. Mostly what I assumed. This is mostly for us, I don’t really have the bandwidth to work on Core as well. But if our observations can help that’s great.
Note that the Linux build slowed considerably, so it finished 840k blocks in about 9.5 hours, and the windows build was 15.3 hours. So not as different as it looked initially.
Also note that BN does not have native SHA256 implemented yet, and both the Windows and Linux builds of BC reported in the log that it was active for them.
A
Antoine Poinsot14:47
Yes, noted that. Plus libsecp256k1 had significant perf improvements in the past couple years.
evoskuil14:49
Right, and my Windows build uses my NuGet prebuilt version of libsecp256k1, which I think is three years old now.
evoskuil14:53
All of my validation performance testing so far has been based on this old version of libsecp, and without native sha256 acceleration, on Windows.
(edited)👍 1
evoskuil15:38
Ah, I misread. The MSVC builds don’t have SHANI (but the mingw builds do, which explains the log).
Yeah, SHANI, SHA vectorization, and algorithm optimization is a fun basket of optimizations. I ended up implementing all SHA, MD, HMAC, and PBKD from spec as C++ templates, to eliminate all of the redundancy and generalize the optimizations. Still have to drop ARM vectorization and ARM/Intel SHA into the SHA template.
For this reason the libbitcoin build is highly sensitive to compiler optimization. With maximal speed optimization it slightly outperforms the BC C implementations and optimizations (where SHANI is excluded), but without -O3 it underperforms. (edited)
… and Scrypt from spec, and the hash accumulator. https://github.com/libbitcoin/libbitcoin-system/tree/master/include/bitcoin/system/impl/hash
evoskuil16:43
This was also part of an academic exercise for me, to show that proper C++ can outperform C. In this case there are performance advantages in autovectorization when using std::array as opposed to raw pointers.
C
cguida00:26
Do I understand from this message that the mini pc you bought for $350 did a full validation sync in 5 hours?
https://libbitcoin.slack.com/archives/C6LH74ACQ/p1729891755834889
Eric Voskuil
Still seeing a high level of starvation in the Linux build, similar to previously with
maximum_concurrency = 0. But the stall and lack of events are resolved. I don't have any tools set up for concurrency and performance analysis on Linux, so I've probably gotta work that out. Setting up my monster mac now also.
In the mean time I pulled down Bitcoin Core latest Linux binary to get a benchmark. It's doing significantly better than it did on the same box for a Windows build (15 hours). After 30 minutes it's completed about 10% of the chain (by txs), and projecting 6 hours (and falling). So w…C
cguida00:28
Ah ok it slowed down to 9.5 hours
https://libbitcoin.slack.com/archives/C6LH74ACQ/p1729953853698889?thread_ts=1729891755.834889&cid=C6LH74ACQ
Eric Voskuil
Thanks, good read. Mostly what I assumed. This is mostly for us, I don’t really have the bandwidth to work on Core as well. But if our observations can help that’s great.
Note that the Linux build slowed considerably, so it finished 840k blocks in about 9.5 hours, and the windows build was 15.3 hours. So not as different as it looked initially.
Also note that BN does not have native SHA256 implemented yet, and both the Windows and Linux builds of BC reported in the log that it was active for them.
C
cguida00:29
Was that with full validation on the $350 machine? Because that's still very impressive
(edited)evoskuil00:56
No, all of the above benchmarks are with a milestone (what BC calls "assume valid") set at the benchmark height. This the default configuration of BC.
(edited)C
cguida02:41
Ah, gotcha. So the corresponding benchmark for BN is 1 hour? Or has the Linux test not completed yet?
evoskuil02:45
The only benchmark for BN is Windows, while I've benchmarked Windows, Linux, and macOS for BC. I had never run BN v4 on Linux or macOS until this week. It runs fine on both, but we need to performance tune it. We've been putting the tools together to do that over the last few days. In the mean time I've rerun the BC benchmarks to verify consistency, and will put out a graph soon.
🔥 1
evoskuil02:53
If you scroll back a ways you'll see s simpler version. Also, I did discuss my most recent BN validation runs on my big box, which came in about 4.5 hours (without confirming queries, which on that machine are prob another 30 mins at least). I haven't attempted any BC full validation runs yet. I also haven't attempted BC with txindex, which is at least a little closer to our level of indexing.
P
parsevalbtc08:38
Yeah, I was facing starvation when I tried on my linux 8GB RAM machine some months ago. Will be following the improvements on this!
👍🏻 1