Bitcoin full node and query server

Oct 10, 2025

View in context in the libbitcoin Slack #general mirror.

evoskuil14:56
I think so. You can verify the build by calling bn -d (hardware).
41 replies · parsevalbtc, eynhaender, pmienk, evoskuil · last Oct 11, 2025
P
parsevalbtc14:57
....compiling! let you know
P
parsevalbtc15:49
image.png
P
parsevalbtc15:51
it seemed it didn't compiled it
eynhaender15:55
CFLAGS="-msse4.1 -msha -mavx512f -mavx512dq -mavx512bw -O3" CXXFLAGS="-msse4.1 -msha -mavx512f -mavx512dq -mavx512bw -O3" ./install-cmake.sh --prefix=/home/eynhaender/development/libbitcoin/build/mmap_patch/ --build-dir=/home/eynhaender/development/libbitcoin/build --build-secp256k1 --build-boost --disable-shared
eynhaender15:56
this is how I pass compiler flags reliably
(edited)
P
parsevalbtc15:59
Thanks @eynhaender! Checking the log it seems that it does those flags everywhere exept to libbitcoin-system"
(edited)
P
parsevalbtc16:00
will try with this more manual options
P
parsevalbtc16:01
-msha is shani right?
P
parsevalbtc16:01
unfortunately I don't have avx512
eynhaender16:13
yes. and of course you need to adapt the options for your specific hardware. -mavx2 will add axv2
👍 1
pmienk16:26
With the cmake installer and cmake in general, arguments at the configuration level are written -Denable-shani
P
parsevalbtc16:29
@pmienk it's strange the usual script does not work... if you want I can provide the log in DM
pmienk16:29
this matches the convention of that platform. configure.ac is an autotools artifact. passing the cflags directly without signaling to our build system will not fully inform the compilation as far as I'm aware as it fails to define WITH_SHANI which was relied upon to enable the codepaths
pmienk16:30
@parsevalbtc Happy to look at your parameterization.
👍 1
P
parsevalbtc13:09
Eventually built with cmake recipe. Is fast like a rocket with the optimizations compiled and ssd disk 🚀🚀🚀
P
parsevalbtc13:10
.... unfortunately it will hit disk space
P
parsevalbtc13:11
in less than 40 I'm about at 500k bloks
P
parsevalbtc13:14
CPU at 50% with network download ~120 MiB/s
P
parsevalbtc13:49
image.png
P
parsevalbtc13:49
hit disk limit
evoskuil14:37
Was that 100% of network capacity?
(edited)
P
parsevalbtc14:38
yes
evoskuil14:39
Well, that's as good as we can do 🙂
P
parsevalbtc14:39
just below 1 Gbps
evoskuil14:39
Nice, ubuntu?
P
parsevalbtc14:39
debian 13
🍻 1
P
parsevalbtc14:40
Now I am moving the bitcoin folder to an external disk
P
parsevalbtc14:40
I expect degradation of performances.... but let's see
evoskuil14:41
yes
P
parsevalbtc14:44
This pc in 16GB RAM, but the (internal) disk is super fast
(edited)
evoskuil14:49
It will start getting slower as the chain grows, because of the limited RAM. You only got to about 25% chain.
(edited)
P
parsevalbtc14:50
25% in space right?
evoskuil14:50
space and txs (and inputs/outputs).
(edited)
P
parsevalbtc14:52
in a past dev meeting you mentioned that at least you have to store the table's head in the RAM. Actually I don't remember how big those are...
P
parsevalbtc14:54
the question is, if the RAM size is below heads' size, the node put's them between RAM and disk or only to the disk?
evoskuil14:55
~16GB (without address index)
P
parsevalbtc14:55
or is the OS which chose how to split them?
evoskuil14:55
It's all in RAM, but these are frequently and randomly accessed during writes. The tables are not, mostly append.
P
parsevalbtc15:10
you mean table's heads are always loaded in RAM (and eventually swap for the exceeding part)?
(edited)
evoskuil15:10
All of the files are always loaded into RAM and swapped as necessary.
👍 1
P
parsevalbtc20:56
With external disk,as expected, is running significantly slower, but it is not stalling. So keep you posted!