"i dont know if this is a break through, a big deal or a mining cherry pop but I got xmrig to push 560 H/s on my Note9"

hyc ^ thought you might be amused

128 core 16 TFLOPS CPU?

That's more TFLOPS than RTX 2080 Ti

"For starters, the chip features two 400 Gbps PHYs integrated, along with a PCI-Express gen 5.0"

fun stuff

lulz @ i.imgur.com/tLTV1Wi.mp4

PCIe gen5 standard is final already?

Inge-: nice

hm, tachyum - VLIW in-order processor, relies on compiler for OoOE

sounds like Itanium

not good for a multithreaded OS, but probably good for HPC

with those PHYs, possibly good for a poll-driven network controller

not good for an interrupt-driven one

total miners 38310

friend of mine had to clean out a linux print server running xmrig malware

asked him for which xmrig version. will report back..

moneromooo Is incoming block PoW verification done on the main thread? Because it changes the rounding mode and can mess up other code which uses floating point

Loki had a big network fuckup today supposedly because they use FP in their diff adjustment code

Monero doesn't use FP there btw which is good

IIRC, main thread if just one, in sync mode it'll be pushed to N threads.

then keep in mind that rounding mode is... random then

maybe we should fix it in librandomx

tevador ^

or just never use FP anywhere else. which we don't

IIRC someone posted a diff adjustment patch for monero which used floating point. Maybe someone saw the patch and applied without seeing it.

I assume the rounding mode is per-core? so saving it on entry to library and restoring it on return from library is sufficient?

Is it saved/restored on context switch ?

part of FPU state, it would have to be

Must be. It'd be dangerous otherise.

in the slow mode, it would be possible to reset the rounding mode after each hash without any performance impact