Implement physical CPU core detection for memory operations #97
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR addresses issue #35: "Do we need to access number of physical CPU cores here?" by implementing proper physical CPU core detection for memory operations in the MemoryBlock class.
Key Changes
Win32_Processor) to get actual physical core count/proc/cpuinfoto detect physical cores accuratelysysctl -n hw.physicalcpucommandEnvironment.ProcessorCount / 2Math.Min(physicalCores, 2)for optimal memory bandwidth utilizationWhy This Matters
The previous implementation used
Environment.ProcessorCount / 2and then hardcoded to 2 threads anyway. This improvement:Technical Details
The solution recognizes that memory operations are bandwidth-limited rather than compute-limited. Therefore, the optimal thread count is
min(physical_cores, memory_channels). Since most systems have dual-channel memory, we limit to 2 threads to avoid memory bandwidth contention.Test Plan
🤖 Generated with Claude Code
Resolves #35