Integrated RandomX, added RandomXL (Loki)

[SChernykh]

RandomX is now compiled together with xmrig code and can be re-configured on the fly to support multiple RandomX variants.

[Spudz76]

Actually compiles on Win7 with 4.16 compiler, but never shows a hashrate.
Also crashes if difficulty is at maximum (test job from MoneroOcean/meta-miner modified to support rx/wow and it works fine with Linux)

[soupli]

Ryzen 5 1600 | 4gb ddr4 | "Ubuntu 16.04.6 LTS

[necro-nemesis]

Compiles and works fine in Windows also.

[Spudz76]

I got it to hash on some Windows now, but not all of them. Something with how the rx/wow does memory allocation does not work as reliably as the normal methods for CN algos for some reason. That would be fine if it detected unusable allocations instead of going ahead with mining 0.00H/s

It does also do the 0.00 thing with Linux in fewer cases but it can happen (not sure the trigger, but same memory allocation stuff - probably lack of enough hugepages)

It also will never show a rate when testing hashrate by feeding it a max-diff blank job (not a current/real job). MoneroOcean/meta-miner does this to get its speeds for multi-mining, and rx/wow refuses to hash on block -1, so the workaround is to set the hashrate to 99999 so the meta-miner feeds real jobs into rx/wow, observe for a hashrate, then manually type that rate in for rx/wow.

Hashrate testing with -1 diff fake job is what was mostly causing 0.00 for me. Although that should work...

[Spudz76]

@soupli How do you get the thread breakout in status? I'd love to have that in my logs. I bet its via keystroke which doesn't work for me (systemd service runs my miner apps, no input).

I had previously assumed (having never used it with input enabled) that there was no per-thread reporting at all.

[necro-nemesis]

I got it to hash on some Windows now, but not all of them. Something with how the rx/wow does memory allocation does not work as reliably as the normal methods for CN algos for some reason. That would be fine if it detected unusable allocations instead of going ahead with mining 0.00H/s

I believe I encountered this anomaly when playing with the number of threads. I have 16 on the system I was testing with and with some thread variations 8<threads<16 in config.json it appeared to have produced this effect. It may be specific to my hardware consisting of 2 CPU's so I didn't previously comment.

[Spudz76]

There are definite issues with multi-cpu, if your motherboard has broken ACPI/NUMA mappings, and disabling NUMA seems to mitigate those for now. Again, this algo has totally new allocation technique (with no options), and has a few bugs compared to the old method. I suppose if the algo allowed NUMA-disable option then it wouldn't have to be globally disabled, just marked as distrustworthy and to use alternate methods as if it weren't there.