<p>By default, yes and no.</p>
<p><strong>No</strong>, most of the code is compiled for generic target hardware. If you want something optimized for your actual hardware, you can add <code>-march=native</code> to your compilation flags (e.g. you'd run <code>./configure CFLAGS=&quot;-march=native&quot; CXXFLAGS=&quot;-march=native&quot;</code>). This will result in a binary that may not work on other hardware than your own. This likely gives you some performance gains, but is unlikely to have a huge impact, because...</p>
<p><strong>Yes</strong>, some code has several variants that are always compiled in, and the optimal one is decided at runtime based on available hardware features. This includes:</p>
<ul>
<li>SHA256 versions for SSE4, SSE4.1, AVX2, and SHA-NI exist.</li>
<li>CRC32 versions (inside LevelDB) for ARM64 and SSE4.2 exist.</li>
<li>The internal random number generator will use RDRAND/RDSEED if provided by the hardware (in addition to other randomness sources).</li>
</ul>
<p>Certainly more optimizations are possible for specific hardware or features, but generally this isn't as easy as just turning a compiler flag - it also needs different code to actually make use of it. For example, compiling generic SHA256 code with <code>-march=native</code> will give a modest speedup, but using code that is designed to make use of the 256-bit wide registers AVX2 can be <em>several times</em> faster in some cases than that, by computing multiple hashes in parallel.</p>

CC BY-SA 4.0
2020-11-25T22:07:32.207Z
Thanks for the detailed answer! Are there any benchmarks on what CPUs are the best to use? What are the most important instruction set extensions that will give the biggest performance gains?
Hellwerker
CC BY-SA 4.0
2020-11-25T22:12:54.210Z
Bitcoin Core will run fastest on x86_64 hardware with SHA-NI instructions enabled. But things like how much memory you have for your dbcache has a far bigger impact on performance than any compiler flag.
Pieter Wuille
CC BY-SA 4.0
2020-11-25T22:15:55.817Z
My question was more about criteria for purchasing a CPU that will be optimal for running a Bitcoin node. But if you say the supported instruction set extensions don't really matter, I guess the most important factor is just raw performance. I was just thinking that because signature verification is a huge part of what Bitcoin Core does, it might make sense to understand what instructions set extensions are most important.
Hellwerker
CC BY-SA 4.0
2020-11-25T22:17:29.517Z
The signature validation code itself doesn't have any hardware-specific optimizations (it uses handwritten x86_64 assembly, but doesn't use any optional features). A significant part of validation is hashing though, so SHA256 performance matters.
Pieter Wuille
CC BY-SA 4.0
2020-11-25T22:20:28.600Z
I see, maybe at some point we will see specific extensions just for SHA256 hasing, given it's importance in the Bitcoin space.
Hellwerker
CC BY-SA 4.0
2020-11-25T22:21:04.350Z
That's exactly what SHA-NI is, and Bitcoin Core uses it. Apparently the proper name is "Intel SHA extensions", see https://en.wikipedia.org/wiki/Intel_SHA_extensions (ironically, there is fairly little Intel hardware that supports it, while recent AMD desktop CPUs all do).
Pieter Wuille
CC BY-SA 4.0
2020-11-25T22:28:34.077Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/116674/discussion-between-patrick-lemke-and-pieter-wuille).
Hellwerker
CC BY-SA 4.0
2020-11-25T20:37:35.360Z
2020-11-25T20:37:35.360Z
Pieter Wuille
<p>If I compile Bitcoin Core using the instructions in the README, does the C++ compiler use compiler optimizations for my current CPU, or will it output a &quot;generic&quot; binary, that can run on almost any CPU? For example if my CPU supports the AVX-512 instructions, will the compiler automatically output a suitable binary or does it not take into account any CPU features at all? If so, how can I make sure I have the optimal binary running on my machine?</p>

<bitcoin-core><bitcoind><compiling>
Compiler optimizations for self-compiled Bitcoin Core
Hellwerker
# Compiler optimizations for self-compiled Bitcoin Core

(Asked by: username_0 on 2020-11-25)

If I compile Bitcoin Core using the instructions in the README, does the C++ compiler use compiler optimizations for my current CPU, or will it output a "generic" binary, that can run on almost any CPU? For example if my CPU supports the AVX-512 instructions, will the compiler automatically output a suitable binary or does it not take into account any CPU features at all? If so, how can I make sure I have the optimal binary running on my machine?

**Tags:** bitcoin-core, bitcoind, compiling


---

## 1 answers

### Answer by username_1 on 2020-11-25. Score: 3 | Accepted answer

By default, yes and no.

**No**, most of the code is compiled for generic target hardware. If you want something optimized for your actual hardware, you can add `-march=native` to your compilation flags (e.g. you'd run `./configure CFLAGS="-march=native" CXXFLAGS="-march=native"`). This will result in a binary that may not work on other hardware than your own. This likely gives you some performance gains, but is unlikely to have a huge impact, because...

**Yes**, some code has several variants that are always compiled in, and the optimal one is decided at runtime based on available hardware features. This includes:

* SHA256 versions for SSE4, SSE4.1, AVX2, and SHA-NI exist.
* CRC32 versions (inside LevelDB) for ARM64 and SSE4.2 exist.
* The internal random number generator will use RDRAND/RDSEED if provided by the hardware (in addition to other randomness sources).

Certainly more optimizations are possible for specific hardware or features, but generally this isn't as easy as just turning a compiler flag - it also needs different code to actually make use of it. For example, compiling generic SHA256 code with `-march=native` will give a modest speedup, but using code that is designed to make use of the 256-bit wide registers AVX2 can be *several times* faster in some cases than that, by computing multiple hashes in parallel.

> **Comments:**
> **username_0**: Thanks for the detailed answer! Are there any benchmarks on what CPUs are the best to use? What are the most important instruction set extensions that will give the biggest performance gains?  
> **username_1**: Bitcoin Core will run fastest on x86_64 hardware with SHA-NI instructions enabled. But things like how much memory you have for your dbcache has a far bigger impact on performance than any compiler flag.  
> **username_0**: My question was more about criteria for purchasing a CPU that will be optimal for running a Bitcoin node. But if you say the supported instruction set extensions don't really matter, I guess the most important factor is just raw performance. I was just thinking that because signature verification is a huge part of what Bitcoin Core does, it might make sense to understand what instructions set extensions are most important.  
> **username_1**: The signature validation code itself doesn't have any hardware-specific optimizations (it uses handwritten x86_64 assembly, but doesn't use any optional features). A significant part of validation is hashing though, so SHA256 performance matters.  
> **username_0**: I see, maybe at some point we will see specific extensions just for SHA256 hasing, given it's importance in the Bitcoin space.  
> **username_1**: That's exactly what SHA-NI is, and Bitcoin Core uses it. Apparently the proper name is "Intel SHA extensions", see https://en.wikipedia.org/wiki/Intel_SHA_extensions (ironically, there is fairly little Intel hardware that supports it, while recent AMD desktop CPUs all do).  
> **username_0**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/116674/discussion-between-patrick-lemke-and-username_1-username_1).  

---

