Oh-kay … v4r, here we come.

Oh-kay – here we are. Two-three days ago I promised a version “probably tomorrow” …. but then – in my hubris – decided to do an apt-update on my KNL development machine … which let to a reboot … during which it realized that the harddisk has some broken sectors … which means it could no longer boot … or even mount the file system on another machine … which …. darn – which better time to lose a harddisk than two days before a release!? Seriously??? Anyway – most of the code was safe under git, it just took forever to reinstall that machine to a state where I could actually develop on it….

Aaaanyway. Release. v4r. I just tagged and built a first internal release with all the right code, including updated version numbers, mpss support, etc. A bit more testing, then I’ll post that public. To make up for lost time in that version I disabled KNC completely, and I think v4r will only run on knl/phi and mpss-knl right now, but at least on my machines it’s working great for both of those configs.

As to performance: What I’m seeing right now is close on 1800-2000 H/s on my 7250, which is pretty good. Exceeeeept…. there’s one caveat: The new thing in v4r is the “randomized code generation”, which means that every block height will run different code during hashing. To do that, there’s basically three options: a) run an interpreter, that just interprets that code sequence on the fly; or b) add a just-in-time compiler to the miner, or c) pre-build all (or at last, a lot) of the upcoming block height’s codes, and link them all together into the same binary. Since I’m not going to add a compiler (well – not yet, at least) I went for a mix of a) and c) : I do include some blocks (for those I get ca 1.8-2kH/s), but for then have a interpreter fall-back for those not built into the binary (and for those, we’ll only get 0.9-1kH/s).

Now the hope is that I’ll eventually ship a binary that has the next few months’ codes all built in – but at least right now I’m having “some minor issues” with the compiler spending literally hours to build a release when too many blocks are built in … and to make matters worse, the test net runs on a different block chain height than the real one will, so I’ll actually have to release different code than what I can test. As such, first version with v4r support might not actually have the right blocks compiled in, yet, and therefore may be running at half the speed. I do have a bigger build with more blocks running in the background …. but …. as I said, it might take a while.

Anyway, two key takeaways:
– v15.1 with v4r support currently building.
– expected performance (once the right binary is our): somewhere around 1800-2000H/s

With that – happy mining!

(PS: Now where did I put that compiler book ….. ?)