( 18th September 2019 )
Source-Code Based Optimization
The CPU based crypto-currency mining can be optimized by modifying the optimization parameters of the CPU based mining source-code. There are certain optimization parameters that can be modified by the help of mining source-code with respect to the CPU selected for mining. Following are the information of optimization parameters with respect to the mining software:
XMR-Stak
For CPU based mining, following optimization parameters from the “XMR-Stak” source-code can be modified:
1. CPU Utilization
2. No. of Threads
XMRig
For CPU based mining, following optimization parameters from the “XMRig” source-code can be modified:
1. CPU Utilization
2. No. of Threads
Webchain Miner
For CPU based mining, following optimization parameters from the “Webchain Miner” source-code can be modified:
1. CPU Utilization
2. No. of Threads
Optimization through Enabling Memory HugePages
When a process uses some memory, the CPU is marking the RAM as used by that process. For efficiency, the CPU allocate RAM by chunks of 4K bytes (it's the default value on many platforms). Those chunks are named pages.
Since the process address space are virtual, the CPU and the operating system have to remember which page belong to which process, and where it is stored. The more pages you have, the more time it takes to find where the memory is mapped. When a process uses 1GB of memory, that's 262144 entries to look up (1GB / 4K). If one Page Table Entry consume 8bytes, that's 2MB (262144 * 8) to look-up. The memory allocated to huge pages is pinned to primary storage, and is never paged nor swapped to secondary storage. You reserve memory for huge pages during system startup, and this memory remains allocated until you change the configuration. In a virtual memory system, the tables store the mappings between virtual addresses and physical addresses. When the system needs to access a virtual memory location, it uses the page tables to translate the virtual address to a physical address. Using huge pages means that the system needs to load fewer such mappings into the Translation Lookaside Buffer (TLB), which is the cache of page tables on a CPU that speeds up the translation of virtual addresses to physical addresses. Enabling the HugePages feature allows the kernel to use hugetlb entries in the TLB that point to huge pages. The hugetbl entries mean that the TLB entries can cover a larger address space, requiring many fewer entries to map the System Global Area (SGA), and releasing entries that can map other portions of the address space. With HugePages enabled, the system uses fewer page tables, reducing the overhead for maintaining and accessing them. Huges pages remain pinned in memory and are not replaced, so the kernel swap daemon has no work to do in managing them, and the kernel does not need to perform page table lookups for them. The smaller number of pages reduces the overhead involved in performing memory operations, and also reduces the likelihood of a bottleneck when accessing page tables.
Most current CPU architectures support bigger pages (so the CPU/OS have less entries to look-up), those are named Huge pages (on Linux), Super Pages (on BSD) or Large Pages (on Windows), but it all the same thing. Through this optimization technique, the hash rates while mining using CPUs could be enhanced to 15% - 20% from the default mining hash rates.
댓글