11:55:32 <garth> Are there any ideas for the future of RandomX, where it might be improved? Say, via new CPU hardware standards?
11:56:30 <garth> Or is it the expectation that the algorithm is 99% finished?
14:05:58 <DataHoarder> new instructions and platforms would bring ways to optimize current implementation
15:46:15 <hyc> "new" is relative. no point in adding a new feature that less than 99% of deployed systems support.
15:48:23 <hyc> mostly the instructions the RandomX VM uses are basic CPU instructions. everything supports them and nobody can further optimize them, CPUs have been doing them for decades.
15:49:25 <hyc> modern CPU development has given up on optimizing them individually, and now just goes for wider parallelism. E.g. vectorizing with AVX.
15:49:47 <sech1> scratchpad and dataset sizes can be tweaked in the future to reflect newer CPUs better
15:50:40 <sech1> maybe program size will be increased too if CPU speed increases much faster than memory latency
15:50:42 <hyc> AVX itself is not a suitable target for randomX, not just because not all CPUs have it, but because not all CPUs even have the same version of it when they do have it. and the data types require particular alignment in memory, which constrains how randomly you can generate them
15:56:07 <hyc> number and ratio of main memory reads/writes can be tweaked if newer CPUs have drastically different memory interface characteristics
15:57:24 <sech1> they already do
15:57:42 <sech1> RandomX was initially tweaked for Zen1, and Zen4 is 50% faster per thread (CPU-only tasks)
15:57:54 <sech1> but memory latency is the same compared to Zen1