hyc: I wasn't accusing you of anything, but it wasn't in design.md so...

Has anyone tried to run a randomX program through Clang/GCC, see what they find/

?*

So TSMC 5nm is capable of 32Mb/mm^2 SRAM (with control logic), a chip could be made with hundreds of randomx instances. It would be expensive of course but Bitmain already uses 5nm and is probably taping out 3nm as we speak.

A zen 2 core is about the same size as 4MB of cache. You could slim it down drastically by getting rid of branch prediction, and unnecessary instruction extensions

* So TSMC 5nm is capable of 32Mb/mm^2 SRAM (with control logic), a chip could be made with hundreds of randomx instances. It would be expensive of course but Bitmain already uses 5nm and is probably taping out 3nm as we speak (for Bitcoin of course).

I wonder if a sea of processors approach with many small simple cores + SRAM (SRAM is much smaller than associative cache), I guess like a modern Xeon Phi would be a viable ASIC.

Even though each instance of RandomX is single threaded, the nature of mining/pow itself is embarrassingly parallel.

Seymour Cray famously said "If you were plowing a field, which would you rather use: two strong oxen or 1024 chickens?". Looking at the history of parallel computing it's pretty clear the chickens have won.

Even so it would be hard to see several orders of magnitude efficiency increase with ASICs, so I guess RandomX is still the best PoW in that regard.

im thinking something like this parallella.org/docs/e5_1024core_soc.pdf

but scaled to 5nm, with a higher SRAM-to-core ratio

I'm not criticising RandomX to be clear... Just vomiting my thoughts from a hardware perspective

You're talking about chip size savings, but efficiency per watt will be approximately the same, at most 2-3x better. Many small cores will also suffer from DRAM access penalties - it's very hard to create efficient memory controller that can handle thousands of parallel accesses

yea, i agree, the efficiency will not be orders of magnitude more than consumer CPUs. Especially when accessing off-chip memory (e.g. DDR4).

Although it should be noted that, HBM is several times more efficient than DDR4. There is also research in bringing compute to memory chips themselves.

Intel Saphire Rapids will bring HBM to server CPUs tho

Also, if you have many slow cores, that leaves more room for re-ordering memory transactions as each program iteration will take more time

* Also, if you have many slow cores, that leaves more room for re-ordering memory transactions (within the memory controller) as each program iteration will take more time

The thing is, chips with HBM are prohibitively expensive, even AMD/NVIDIA do this only for their datacenter GPUs

By the time ASIC manufacturers are able to use all this magic tech, AMD/Intel/NVIDIA will already have it in consumer chips

it will be more common very soon, fundamentally it's not any more cost to produce than DDR, it's just a question of scale.

Also, in RandomX something like 90% of energy is spent by CPU

processor-in-memory is pretty well studied twitter.com/hyc_symas/status/1171800102471532544

you're talking about flocks of tiny cores, but none of these can do 64bit arithmetic

it also doesn't make sense to make a core much smaller than 2 MB SRAM it needs to use

and that is not a small core already

Well the Epiphany-V does do 64-bit floating point, just not enough cache to run RandomX for every core

I'm surprised APple didn't use HBM for the M1's on-chip memory

of all companies, they could afford to make such a decision, at this point in history

something like Cortex A-55 modification + 2 MB SRAM instead of data caches, all that on 5nm would be optimal

<sech1 "it also doesn't make sense to ma"> true, logic transistors are cheaper than memory transistors. however you could still strip out alot of cruft from the typical x86 core and just put in more ALUs

more ALUs doesn't help without more bandwidth

more ALUs is not even needed, just put more cores instead

Intel x86 has always been bandwidth-starved

that moves the problem to a super-efficient memory controller, and those IPs are very expensive and/or well guarded

and get rid of the cache tagging, snooping and victim cache logic. still pretty significant savings

Unless they do something like distributed on-chip memory + fast interconnect

getting rid of the cache logic would just make software harder to write. it's been done before.

remember the Cell engine

2-3x overall efficiency improvement over Ryzen or Apple M1 is possible

it'll all be limited by how efficient ALUs they can make

<hyc "getting rid of the cache logic w"> yea but if you're just interested in running randomX, it would be worth it

not by scratchpad/dataset access

Apple M1 is already 5nm though

so maybe only 2x over that

no way will any ASIC get to more advanced processes before the big CPU houses do

<sech1 "Apple M1 is already 5nm though"> yea but also 80% of the die size are not cores

<hyc "no way will any ASIC get to more"> but Bitmain is constantly ahead on nodes, their current S9/Pro is 5nm right?

is it?

7nm

cost structure is simplified a lot when you can just produce and use it yourself. no need to market, ship, pay tarifs..

they are lower priority customers than Apple

"On 27 February, Bitmain officially announced the Antminer S19 and S19 Pro. Equipped with a custom-built 7nm chip from Bitmain"

And even when Bitmain gets hands on 5nm, it'll be used for Bitcoin ASICs

<sech1 ""On 27 February, Bitmain officia"> fair enough

5nm is already fully booked for more than a year ahead

currently Apple, soon AMD with NVIDIA

<sech1 "And even when Bitmain gets hands"> agreed, unless monero flips Bitcoin haha

by the time Monero flips Bitcoins, it'll be mined by hundreds of millions of CPUs, many of them with "free" electricity

a few dozen thousands of ASICs would be a drop in the ocean

at worst it'll be like Ethereum where ASICs exist but mining stays very profitable for everyone

I have a feeling GPU eth miners will be pushed out soon when gas fees settle down

latest RTX GPUs have very high ETH efficiency, almost the same as ASICs

Bitmain likes to embellish, but it this is ballpark correct, it's still several times more efficient than RTX 3000

* Bitmain likes to embellish, but if this is ballpark correct, it's still several times more efficient than RTX 3000

3GH/s @ 2556W

I haven't seen official numbers yet

Why would Nvidia bother to create a mining-only product line

they know years in advance what the tech landscape will be

<hyc "Why would Nvidia bother to creat"> to avoid used cards flooding the market, affecting sales of their next-gen

that's one of the reasons turing didn't do that well

1080 ti and pascal in general was cheap and available in part because they were good cards, but also due to mining boom in 2017 and crash in 2018

anyway, i don't want to come off as critical of RandomX, you guys really came up with something cool here, and it seems to be the best ASIC resistant solution so far.

it's important to keep watching the tech space to see where challenges could arise

but we already do that...

<hyc "it's important to keep watching "> agreed 🙂

if we get a RISC-V JIT compiler, I'd like to do some simulations in QEMU for fun :P

it's in the plans

can QEMU run some RISC-V?

yep

someone promised to send me RISC-V board: xmrig/xmrig #1924

let's see how it goes, I haven't heard anything yet

RISC-V support is in upstream QEMU now.

it's also possible to put a linux bootable riscv on FPGA

tho it's not optimized for it

Has anyone tried to run a randomX program through Clang or GCC, see what they find?

Or do conventional implementations already optimize it as best they can?

I see there's code to generate C code in tevador/RandomX

not relevant

???

For example, a C compiler might be able to do smart register scheduling, or elimination of dead code, or similar, better than a naïve jit compiler could

Fast enough to be of any use ?

moneromooo: well that's my question - anyone tried it?

and the answer is no.

this is already explained in the Design doc.

there isn't enough time for complex optimizations

have you ever timed the startup time of clang? just to do nothing at all but to page the executables into memory and start running?

hyc: Right, but if clang is able to find optimizations, then it seems easy-ish to make a tiny "compiler" with only the applicable optimizations too.

lol no

none of the optimizations you mention are easy. they all require multiple-pass analysis

not necessarily, of course, but if the optimizations turn out to be simple ones...?

then they're of low impact

dead code elimination, seriously?

that requires complete control-flow analysis of the code start-to-finish

by te time you did that, the entire code could have executed in a JIT already

peephole is most likely single pass.

Does the JIT currently do any optimisations at all or is it essentially a direct translation?

very little

peephole could do some instruction fusion, yeah

Most uArch front ends do fusion anyways

but that's not single-pass. once you've identified points to optimize, you must go thru and relocate all affected address references

right - so it's usually wasted effort

Oh, good point.

remember, I was a gcc maintainer for ~10 years. I've been there and done that, many times.

you will always lose more time in code translation than you will regain in code execution time

AOT optimization is cost-effective when the resulting code is reused a lot.

a RandomX program for a given nonce only gets used once, then it's discarded forever

yanmaani hyc speaking of micro-optimizations, there are some in xmrig JIT compiler

like removing redundant CFROUND instructions

but they are all single-pass O(1) complexity code, otherwise it's too slow for JIT

right

removing CFROUND gave only 0.05% speedup

because not many programs have more than 1 CFROUND without FP instructions between them

yeah, talk about edge cases

we don't have a NOP opcode do we

we do, but it has frequency 0

even removing CFROUND is done by overwriting it with NOPs because moving generated code and fixing offsets is too slow

JIT compiler time constraints are very tight

yeah as I'd expect

of course if there's some peephole optimization that gives +10% in the main loop, JIT can sped a lot of time to do it. But I'm not aware of any such optimization and I spent 17 months tinkering with RandomX :D

actually more than 17 months, 2 years already

So what speedup does a modern compiler get if you allow it to optimize the main loop for 2 years straight on a modern supercomputer?

I haven't seen a compiler that can beat asm optimization by hand, given the programmer is experienced enough

and I can't see much places in the optimized code that can be optimized

*in the generated code

what would hand-optimizing the asm get you then?

Maybe +1-2% if you can spot places where instructions cancel each other

RandomX programs have a lot of branch instructions which makes them a "train" of short pieces of code divided by branches

not much can be done in each piece

this is all valid for modern superscalar out-of-order CPUs

there are a lot of things that can be done for in-order CPUs like Cortex A53

RandomX JIT doesn't reorder instructions at all and relies on CPU to do that

sech1: Does the optimization for A53 improve things, or just bring it back to the level of an OOE CPU?

so I estimate it's possible to get +50% by hand-optimizing generated code for A53

it doesn't matter much because 5 h/s vs 7.5 h/s is laughable anyway

aren't a53s much cheaper though?

not enough cheaper to be worth that

en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-x1 looks much more interesting

up to 8 MB cache per cluster, so a cluster of 4 cores + 8 MB cache would be perfect

<sech1 "RandomX JIT doesn't reorder inst"> So in theory the Apple M1 should do an amazing job. If it wasn’t on macOS >.>

plus wide out of order design

Cortex-X1, Apple M1 are the most efficient per watt on RandomX right now

mostly thanks to 5nm node they use

does anyone sell boards with like a trillion ARM processors on them

Extremely deep reorder buffer plus very wide decode stage

kind of like xeon phi but chinese

<yanmaani "kind of like xeon phi but chines"> Mmm the Japanese industry always make interesting stuff

the closest would be Phytium FT-2000 64-core chip

A64FX comes to mind but very expensive. Low volume part only for their Fugaku super computer

128 cores in MT2000+ appsbuilders.org/news/tsmc-to-stop-…ter-tianhe-3-in-question-servernews

but production is canceled now due to US trade sanctions

didn't realize their quadcore chip had gone into production tomshardware.com/news/arm-phytium-ft-2000-cpu-chinese-gaming-pc

There’s also Xilinx Versal ACAP. With 400 VLIW cores + FPGA but it suffers from only 100Mb of cache for the VLIW cores

191Mb if you count fpga block rams but those are a few clock cycles away

FPGAs won't cut it

I know but these are hardened cores

we've discussed Xilinx Versal in here before

the cores aren't adequate, even if you interfaced to enough external RAM

as monero gets bigger, would it eventually spur cheap bulk CPUs specifically optimized for randomx?

maybe.

I suppose if you treat the majority of cores as co-processors instead of peer CPUs the control netowrk would be simpler

that's still the major limiting factor in putting more cores on a chip

these cores don't need to run any OS, just point them at a chunk of dataset RAM and a chunk of randomx code and let them run

so they don't need a lot of the multi-processor comms support that would usually be needed

i guess a many core cpu designed for randomx could also be binned extremely well, as really no individual core is critical

memory controllers also don't need to feed cores on the other side of the chip, just ones in its local area, as long as there is at least 2GB per memory controller

we will probably up the RAM requirement to 4GB within a year or two

ah ok

seems reasonable, is there any reason not to go 8GB?

I wouldn't do it yet. 4GB is still feasible for a lot of smartphones. 8GB is pushing it.

8gb is also infeasible for most computers running an OS

true

does anyone really still run 8GB with a CPU fast enough to be profitable with mining?

aside from base model macbook >.>

I ordered my M1 macbook with 16GB RAM, but the base model is only 8GB

and just booting up to desktop 11GB of RAM is in use

I suppose a lot of that is swapped out on an 8GB machine

would not be a pleasant experience

fair enough, if you where actively using the computer while mining it'd be pretty terrible

* fair enough, if you where actively using the computer while mining it'd be pretty terrible, even for 16GB machine

could you make a randomx coprocessor that the primary CPU could use effectively?

like, where else in contemporary computing do you have a series of random functions that need to be executed as fast as possible?

i guess if you used machine learning to optimize some signal to output relationship

but is that what you were talking about in different words?

probably a torus

gingeropolous: isn't a "randomx coprocessor" just a processor?

well like y'all were saying, you rip all the stuff out that ends up useless. like the branch prediction. i remember seeing images of CPUs and the branch predictors eat so much die

branch prediction is sorta needed though?

yes

the stuff I would rip out is everything that supports an OS - interrupt handlers, permission levels

does that even use a lot of die space?

if you look at all of the security bugs Intel has had to deal with in the past year or two

spectre etc... yes.

I'm sort of wondering why supercomputers don't do that. I mean, they don't have to bother with permissions right?

the reason those bugs existed is because Intel tried to cut corners where they shouldn't have

supercomputers still tend to run multiuser OSs so they still have to deal with that

Crays ran Unix. modern supercomputers run linux

hyc: sure, cause it's a lower cost

develop new OS + develop interrupt-less CPU < buy normal CPUs and use normal Linux

cause I think Linux can run on e.g. MMU-less systems, so it seems like cutting protection would be a no-brainer if it had significant savings

hm. it's been a long time since I tried to run linux on a machine with no MMU, dunno if that's still supported

it's supported by linux, but not by glibc

so you have to run uclibc, and you have certain limitations on mmap etc

ah

cool

glibc is such a pig

the other day I wrote a little toy that was 300 bytes long. 16K when linked with glibc

I rewrote it to use syscall() instead of the usual library calls, got it back down to 500 bytes

why not just use musl?