Refactor Memory Allocation to Dynamically Determine Page Size Instead of Hardcoding 4KB Assumption

[calcitem]

Describe the issue

The Stockfish engine's memory management code, specifically in src/memory.cpp and src/memory.h, contains hardcoded assumptions of a 4KB (4096 bytes) system page size. This primarily affects the aligned_large_pages_alloc function for non-Windows/non-Linux (or generic Linux fallback) code paths and related helper functions like make_unique_large_page.

Specific Locations:

1. aligned_large_pages_alloc (non-Windows/non-Linux path) in src/memory.cpp:

   C++

   #else // Not _WIN32
   void* aligned_large_pages_alloc(size_t allocSize) {
   #if defined(__linux__) && !defined(__ANDROID__)
       constexpr size_t alignment = 2 * 1024 * 1024;  // 2MB page size assumed
   #else
       constexpr size_t alignment = 4096;  // <--- HERE: small page size assumed
   #endif
   // ...
   }
   #endif
   

   This hardcoded 4096 is problematic when the actual system page size is different (e.g., 16KB).

2. static_assert in make_unique_large_page in src/memory.h:

   C++

   template<typename T, typename... Args>
   std::enable_if_t<!std::is_array_v<T>, LargePagePtr<T>> make_unique_large_page(Args&&... args) {
       static_assert(alignof(T) <= 4096, // <--- HERE
                     "aligned_large_pages_alloc() may fail for such a big alignment requirement of T");
   // ...
   }
   // Similar assert for array version
   

   This reinforces the 4KB assumption.

Impact:

This hardcoding can lead to issues on systems with page sizes other than 4KB, particularly:

• Suboptimal Alignment: Memory may not be aligned to the true system page boundary (e.g., 16KB), potentially negating performance benefits of such alignment.
• Inefficiency: May lead to memory fragmentation or waste if the OS rounds allocations to the actual larger page size.
• Compatibility: This is particularly relevant for newer Android devices and NDKs (e.g., NDK r27+) which promote 16KB page alignment. NDK guidelines also state that the PAGE_SIZE macro might become undefined in 16KB mode, emphasizing the need to dynamically query page sizes.
• The function name aligned_large_pages_alloc implies alignment to a system-relevant page size, which may not be met with a hardcoded value.

Expected behavior

The memory allocation functions, especially aligned_large_pages_alloc, should dynamically determine the actual system page size at runtime and use this value for memory alignment when intending to align to "page size".

Specifically:

1. The hardcoded 4096 value used as a presumed page size should be replaced with a value obtained by calling sysconf(_SC_PAGESIZE) (on POSIX-compliant systems like Linux, Android, macOS) or a similar platform-specific API.
2. Memory allocations intended to be page-aligned should be aligned to this dynamically fetched, actual system page size (e.g., 4KB, 16KB, or other).
3. The static_assert in make_unique_large_page should be re-evaluated. If it's meant to check against the page size, it needs to accommodate dynamic page sizes (perhaps by becoming a runtime check for unusually large alignof(T) or by using a more flexible compile-time constant if page size is constrained within a known set for targeted platforms).
4. Comments should reflect the dynamic nature of page size determination.

Steps to reproduce

This is a code architecture issue identified through code review, rather than a runtime bug reproducible with specific UCI commands. The issue becomes relevant on systems where the actual page size differs from the hardcoded 4KB assumption.

To observe the relevant code:

1. Review the

   aligned_large_pages_alloc
   

   function in

   src/memory.cpp
   

   , specifically the

   #else
   

   block for non-Windows, non-specific-Linux code paths.

   C++

   // memory.cpp, within aligned_large_pages_alloc
   #else // Not _WIN32
   // ...
   #if defined(__linux__) && !defined(__ANDROID__)
       // ...
   #else
       constexpr size_t alignment = 4096; // Problematic line
   #endif
   

2. Review the

   static_assert
   

   conditions in

   make_unique_large_page
   

   in

   src/memory.h
   

   .

   C++

   // memory.h, within make_unique_large_page
   static_assert(alignof(T) <= 4096, ...);
   

3. Consider the execution path and memory alignment results if this code runs on a system with a 16KB page size (e.g., an Android device compiled with NDK r27+ targeting 16KB-aligned executables). The memory will be aligned to 4KB, not the system's actual 16KB page size.

Anything else?

Proposed Solution Details:

1. Use sysconf(_SC_PAGESIZE):

   In src/memory.cpp, for POSIX-like systems (including Linux, Android, macOS), replace the hardcoded 4096 with a call to sysconf(_SC_PAGESIZE).

   C++

   #include <unistd.h> // For sysconf
   
   // Helper (can be placed appropriately)
   static size_t get_system_page_size() {
       long page_size_val = sysconf(_SC_PAGESIZE);
       if (page_size_val == -1) {
           // Fallback or error handling
           // For robustness, might log an error and return a default like 4096,
           // or throw, depending on desired error handling strategy.
           return 4096; 
       }
       return static_cast<size_t>(page_size_val);
   }
   
   // In aligned_large_pages_alloc for the generic path:
   // ...
   #else // for the generic POSIX path
       alignment = get_system_page_size();
   #endif
   // ...
   

2. Re-evaluate static_assert:

   The static_assert(alignof(T) <= 4096, ...) logic needs to be updated. Since page size is dynamic, a compile-time check against a fixed value is problematic.

   • If alignof(T) is generally expected to be small (e.g., <= 64 bytes), it will likely always be less than any system page size (4KB, 16KB, 64KB). The assert might be unnecessary or could check against a very generous maximum alignment if alignof(T) could be extremely large for some types used with this allocator.
   • Alternatively, if PAGE_SIZE becomes available as a reliable compile-time constant in target build environments (especially NDK r27+ for 16KB mode), it could be used. Otherwise, this check might need to be a runtime check or be removed if std_aligned_alloc is trusted to handle the alignof(T) passed to it.

3. Windows Code Path: The Windows-specific code using GetLargePageMinimum() and VirtualAlloc seems generally fine as it queries system properties.

This change is crucial for future-proofing Stockfish, ensuring optimal performance on modern hardware (especially Android devices with 16KB pages), and adhering to evolving platform guidelines.

Operating system

Android

Stockfish version

94e6c04

[vondele]

I'll reopen this, as there might be some value in implementing this, we do have access to systems where:

$ getconf PAGESIZE
65536

so there is a way of testing this. However, doesn't this need to know the size of the large pages on the system? Maybe that needs to go via grep Hugepagesize /proc/meminfo ?

[calcitem]

Thank you for reopening the discussion!

doesn't this need to know the size of the large pages on the system? Maybe that needs to go via grep Hugepagesize /proc/meminfo ?

Yes, that’s a fair point. Ideally, we’d detect whether large pages are actually available and use their size, rather than just assuming a 4KB fallback. A possible approach:

1. Parse /proc/meminfo for the Hugepagesize (e.g. 2MB, 64KB, etc.).
2. Check HugePages_Total and HugePages_Free to ensure there's a nonzero large page pool.
3. If large pages are available, use that size. Otherwise, fallback to sysconf(_SC_PAGESIZE).
4. If sysconf(_SC_PAGESIZE) fails, fallback to 4096 as the minimum alignment.

I have access to a 16KB-page Android environment, where I've done some informal testing on a different board game engine. The performance difference from using page-sized alignment seemed quite small (under ~2%), but I’m planning to do a more thorough benchmark with Stockfish to see if there’s any measurable speedup or Elo improvement. If it proves beneficial or if it helps certain systems, I'd be happy to contribute a PR with these changes and some test results.

The current fallback hardcodes 4096, which might not match many modern systems’ page sizes (16KB, 64KB, etc.). I’ll try to prepare a proof-of-concept patch based on the approach above, then do some testing. If I find meaningful improvements, I’ll post the results.

[Disservin]

The 4kib is only used as a fallback on android anyway, so the performance impact is very limited to that platform and it isn’t really the platform we optimize for either.. and I wasn’t particular happy about a seemingly chatgpt generated issue, since chatgpt will always find something and this would cause a lot of spammy issues if everyone did this

Android 15 market share is also only 10%

[Disservin]

in theory some machines also have 1GB pages but we default to 2MB, cat /proc/cpuinfo | grep "pdpe1gb" i'd be more interest in that case than the fallback android case

[vondele]

$ cat /proc/cpuinfo | grep "pdpe1gb" | head -n1
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd amd_ppin arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sme sev sev_es

and

$ grep Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB

on the same system

[Disservin]

the Hugepagesize in /proc/meminfo is only the default currently set, cpuinfo tells us about the cpus capabilities, for a list also see https://en.wikipedia.org/wiki/Page_%28computer_memory%29#Multiple_page_sizes

[RogerThiede]

Years ago I had collected many tests on Linux with variable page sizes, Is Large Page support on Linux only Transparent Huge Pages?. I was disappointed to find my results had huge margins of error and seemed to rely on too many other variables (TT size, hashfull percentage, number of threads, and socket affinity). I recall finding some sweet spots for only some specific combinations of those variables, but a slight variation of just one variable would change where the sweet spot was or the margin of error in reproductions.

Essentially the problem I ran into was finding how to reliably show a performance correlation to a given page size, as simply stopping some search depths at 25 versus letting some search depths go to 65 showed radically different performance improvements or regressions.

[Disservin]

I'm not sure where the benefit here really comes from.. without large pages, changing this only has an effect on the alignment of the memory address of the pointer, we don't magically change the actual page size of the system or anything.. and going from 4KB to 16KB for the pointer alignment is pretty useless?

And android doesn't have huge pages anyways?

On my mac which has 16KB pagesize as well, changing the constant has no effect on the performance either.

speedup = 0.02741% +/- 0.088% (95%)

So I don't see anything actionable here really

[Disservin]

or am i missing something here @Sopel97 since you initially mentioned it has some merit?

[Sopel97]

Yea I don't think this particular value matters much as long as there are no page sizes smaller than 4096. Worst that could happen is aligned_alloc not giving us memory that's page aligned, resulting is potentially one more page being allocated and needed in TLB but I don't see that happening nor mattering in reality.

[Disservin]

Yea so unless we have actual proposal of what to change to improve performance I'd just close this again.