Merge remote-tracking branch 'tevador/master'

CMakeLists.txt

@@ -116,6 +116,12 @@ endif()
 
 # ARMv8
 if (ARM_ID STREQUAL "aarch64" OR ARM_ID STREQUAL "arm64" OR ARM_ID STREQUAL "armv8-a")
+  list(APPEND randomx_sources
+    src/jit_compiler_a64_static.S
+    src/jit_compiler_a64.cpp)
+  # cheat because cmake and ccache hate each other
+  set_property(SOURCE src/jit_compiler_a64_static.S PROPERTY LANGUAGE C)
+
   if(ARCH STREQUAL "native")
     add_flag("-march=native")
   else()

README.md

@@ -37,7 +37,7 @@ make
 
 ### Windows
 
-On Windows, it is possible to build using MinGW (same procedure as on Linux) or using Visual Studio 2017 (solution file is provided).
+On Windows, it is possible to build using MinGW (same procedure as on Linux) or using Visual Studio (solution file is provided).
 
 ### Precompiled binaries
 
@@ -53,23 +53,26 @@ RandomX was primarily designed as a PoW algorithm for [Monero](https://www.getmo
 If you wish to use RandomX as a PoW algorithm for your cryptocurrency, please follow the [configuration guidelines](doc/configuration.md).
 
 ### CPU performance
-The table below lists the performance of selected CPUs using the optimal number of threads (T) and large pages (if possible), in hashes per second (H/s). "CNv4" refers to the CryptoNight variant 4 (CN/R) hashrate measured using [xmrig](https://github.com/xmrig/xmrig) v2.14.1. "Fast mode" and "Light mode" are the two modes of RandomX.
+The table below lists the performance of selected CPUs using the optimal number of threads (T) and large pages (if possible), in hashes per second (H/s). "CNv4" refers to the CryptoNight variant 4 (CN/R) hashrate measured using [XMRig](https://github.com/xmrig/xmrig) v2.14.1. "Fast mode" and "Light mode" are the two modes of RandomX.
 
 |CPU|RAM|OS|AES|CNv4|Fast mode|Light mode|
 |---|---|--|---|-----|------|--------------|
-AMD Ryzen 7 1700|16 GB DDR4|Ubuntu 16.04|hardware|520 (8T)|4100 (8T)|620 (16T)|
-Intel Core i7-8550U|16 GB DDR4|Windows 10|hardware|200 (4T)|1700  (4T)|350 (8T)|
-Intel Core i3-3220|4 GB DDR3|Ubuntu 16.04|software|42 (4T)|510 (4T)|150 (4T)|
-Raspberry Pi 3|1 GB DDR2|Ubuntu 16.04|software|3.5 (4T)|-|2.0 (4T) †|
+Intel Core i9-9900K|32G DDR4-3200|Windows 10|hw|660 (8T)|5770 (8T)|1160 (16T)|
+AMD Ryzen 7 1700|16G DDR4-2666|Ubuntu 16.04|hw|520 (8T)|4100 (8T)|620 (16T)|
+Intel Core i7-8550U|16G DDR4-2400|Windows 10|hw|200 (4T)|1700  (4T)|350 (8T)|
+Intel Core i3-3220|4G DDR3-1333|Ubuntu 16.04|soft|42 (4T)|510 (4T)|150 (4T)|
+Raspberry Pi 3|1G LPDDR2|Ubuntu 16.04|soft|3.5 (4T)|-|20 (4T)|
 
-† Using the interpreter mode. Compiled mode is expected to increase performance by a factor of 10.
+Note that RandomX currently includes a JIT compiler for x86-64 and ARM64. Other architectures have to use the portable interpreter, which is much slower.
 
 ### GPU performance
 
 SChernykh is developing GPU mining code for RandomX. Benchmarks are included in the following repositories:
 
 * [CUDA miner](https://github.com/SChernykh/RandomX_CUDA) - NVIDIA GPUs.
-* [OpenCL miner](https://github.com/SChernykh/RandomX_OpenCL) - currently only for AMD Vega (uses GCN5 machine code).
+* [OpenCL miner](https://github.com/SChernykh/RandomX_OpenCL) - only for AMD Vega and AMD Polaris GPUs (uses GCN machine code).
+
+The code from the above repositories is included in the open source miner [XMRig](https://github.com/xmrig/xmrig).
 
 Note that GPUs are at a disadvantage when running RandomX since the algorithm was designed to be efficient on CPUs.
 
@@ -86,10 +89,8 @@ Most Intel and AMD CPUs made since 2011 should be fairly efficient at RandomX. M
 * Support for large memory pages
 * At least 2.5 GiB of free RAM per NUMA node
 * Multiple memory channels may be required:
-    * DDR3 memory is limited to about 1500 H/s per channel
-    * DDR4 memory is limited to about 4000 H/s per channel
-
-
+    * DDR3 memory is limited to about 1500-2000 H/s per channel (depending on frequency and timings)
+    * DDR4 memory is limited to about 4000-6000 H/s per channel  (depending on frequency and timings)
 
 ### Does RandomX facilitate botnets/malware mining or web mining?
 Efficient mining requires more than 2 GiB of memory, which is difficult to hide in an infected computer and disqualifies many low-end machines such as IoT devices. Web mining is infeasible due to the large memory requirement and the lack of directed rounding support for floating point operations in both Javascript and WebAssembly.
@@ -105,15 +106,22 @@ The reference implementation has been validated on the following platforms:
 * ARMv8 (64-bit, little-endian)
 * PPC64 (64-bit, big-endian)
 
+### Can FPGAs mine RandomX?
+
+RandomX generates multiple unique programs for every hash, so FPGAs cannot dynamically reconfigure their circuitry because typical FPGA takes tens of seconds to load a bitstream. It is also not possible to generate bitstreams for RandomX programs in advance due to the sheer number of combinations (there are 2<sup>512</sup> unique programs).
+
+Sufficiently large FPGAs can mine RandomX in a [soft microprocessor](https://en.wikipedia.org/wiki/Soft_microprocessor) configuration by emulating a CPU. Under these circumstances, an FPGA will be much less efficient than a CPU or a specialized chip (ASIC).
+
 ## Acknowledgements
+* [tevador](https://github.com/tevador) - author
 * [SChernykh](https://github.com/SChernykh) - contributed significantly to the design of RandomX
 * [hyc](https://github.com/hyc) - original idea of using random code execution for PoW
-* [nioroso-x3](https://github.com/nioroso-x3) - provided access to PowerPC for testing purposes
+* [Other contributors](https://github.com/tevador/RandomX/graphs/contributors)
 
 RandomX uses some source code from the following 3rd party repositories:
 * Argon2d, Blake2b hashing functions: https://github.com/P-H-C/phc-winner-argon2
 
-The author of RandomX declares no competing financial interest in RandomX adoption, other than being a holder of Monero. The development of RandomX was funded from the author's own pocket with only the help listed above.
+The author of RandomX declares no competing financial interest.
 
 ## Donations
 
@@ -123,3 +131,4 @@ Author's XMR address:
 ```
 845xHUh5GvfHwc2R8DVJCE7BT2sd4YEcmjG8GNSdmeNsP5DTEjXd1CNgxTcjHjiFuthRHAoVEJjM7GyKzQKLJtbd56xbh7V
 ```
+Total donations received: ~3.86 XMR (as of 30th August 2019). Thanks to all contributors.

doc/configuration.md

@@ -24,14 +24,16 @@ These parameters can be modified in source file [configuration.h](../src/configu
 |`RANDOMX_SCRATCHPAD_L1`|Scratchpad L1 size in bytes|`16384`|
 |`RANDOMX_FREQ_*` (29x)|Instruction frequencies|multiple values|
 
-Not all of the parameters can be changed safely and most parameters have some contraints on what values can be selected. Follow the guidelines below.
+Not all of the parameters can be changed safely and most parameters have some contraints on what values can be selected (checked at compile-time).
+
+**Disclaimer: The compile-time checks only prevent obviously broken configurations. Passing the checks does not imply that the configuration is safe and will not cause crashes or other issues. We recommend that each non-standard configuration is thoroughly tested before being deployed.**
 
 ### RANDOMX_ARGON_MEMORY
 
 This parameter determines the amount of memory needed in the light mode. Memory is specified in KiB (1 KiB = 1024 bytes).
 
 #### Permitted values
-Any integer power of 2.
+Integer powers of 2 in the range 8 - 2097152.
 
 #### Notes
 Lower sizes will reduce the memory-hardness of the algorithm.
@@ -41,7 +43,7 @@ Lower sizes will reduce the memory-hardness of the algorithm.
 Determines the number of passes of Argon2 that are used to generate the Cache.
 
 #### Permitted values
-Any positive integer.
+Any positive 32-bit integer.
 
 #### Notes
 The time needed to initialize the Cache is proportional to the value of this constant.
@@ -51,7 +53,7 @@ The time needed to initialize the Cache is proportional to the value of this con
 The number of parallel lanes for Cache initialization.
 
 #### Permitted values
-Any positive integer.
+Integers in the range 1 - 16777215.
 
 #### Notes
 This parameter determines how many threads can be used for Cache initialization. 
@@ -61,7 +63,7 @@ This parameter determines how many threads can be used for Cache initialization.
 Salt value for Cache initialization.
 
 #### Permitted values
-Any string of byte values.
+A string of at least 8 characters.
 
 #### Note
 Every implementation should choose a unique salt value.
@@ -80,7 +82,7 @@ This value directly determines the performance ratio between the 'fast' and 'lig
 Target latency for SuperscalarHash, in cycles of the reference CPU.
 
 #### Permitted values
-Any positive integer.
+Integers in the range 1 - 10000.
 
 #### Notes
 The default value was tuned so that a high-performance superscalar CPU running at 2-4 GHz will execute SuperscalarHash in similar time it takes to load data from RAM (40-80 ns). Using a lower value will make Dataset generation (and light mode) more memory bound, while increasing this value will make Dataset generation (and light mode) more compute bound.
@@ -110,7 +112,7 @@ This constant affects the memory requirements in fast mode. Some values are unsa
 The number of instructions in a RandomX program.
 
 #### Permitted values
-Any positive integer divisible by 8.
+Positive integers divisible by 8 in the range 8 - 32768 (inclusive).
 
 #### Notes
 Smaller values will make RandomX more DRAM-latency bound, while higher values will make RandomX more compute-bound. Some values are unsafe. See [Unsafe configurations](#unsafe-configurations).