Reproducibility across different platforms #3
Comments
|
|
@wowario Your first result was different. Any idea why? |
|
Yes, it was. The first test ran on an older version of |
|
Tested with Intel(R) Core(TM) i5-6600K CPU @ 3.50GHz Cumulative output hash: 3cc26d6be7f5f542e8037247deec69c2e3a3d70db67dac5371f86e06fbe3c8cc |
|
We should test an x86 (32bit) platform (not that I'm expecting anyone to mine on such machine). Also more AMD CPUs (they can give different results for transcendental math functions). |
|
I have a couple oldish AMD boxes around, don't think I have any x86s though. Will try to test on AMDs in next couple days. |
|
Tested on - got: |
|
Tested on: Results: |
|
Note that as of commit d32fd77, the cumulative hash is different because the generator has been slightly modified. The new hash is: If you do |
|
I decided to remove all transcendental functions (exp, log, sin, cos, cbrt, atan) from the generator due to poor cross-platform compatibility (rounding is not enough). With these functions enabled, the results don't match between Windows and Linux with the XS engine. The reason why the results match for the V8 is because V8 has its own software implementation of all these functions using only IEEE-754 safe operations. We could copy this implementation to the XS, but I don't see the point in that because an ASIC could easily include a faster on-chip implementation. The only function that stays is For testing of floating point math compatibility, please use the following command: It generates programs with only math expressions and doesn't depend on Output with commit e136756 should be: It is now possible to also test with the XS engine. You have to clone and compile it from here: https://github.com/tevador/moddable To use this engine, append the following command line option: For the NodeJS sandbox, you can use (it's the default option): |
|
|
@fuwa0529 I have also tested the latest commit from the dev branch on Intel Kaby Lake (Windows), AMD Ryzen and Raspberry Pi 3 (Ubuntu) and all give the same results. I think at this point we can conclude that reproducibility is not an issue. |
I'm curious about performance numbers for all these processors. Can even Raspberry Pi 3 be used for mining? |
|
Tested on: Results: |
Commit 4fc608c, 1 core, XS engine:
So the Raspberry is about 6-7 times slower per core. It consumes ~5 W when mining with all 4 cores, but you need some kind of cooling solution because it will start thermal throttling quickly. The performance per watt seems to be comparable to the most efficient laptop processors, so it's definitely usable for mining. |
|
OK, tested again with: Got the same result as others using the options suggested: |
Huh, and considering 40$ price it will be the most profitable option: 8x Raspberry Pi 3 will cost 320$ and will be faster than Kaby Lake. Future mining rigs will look like this: https://www.youtube.com/watch?v=i_r3z1jYHAc |
|
|
|
Also tested with Node-Chakracore v10.1.0 official release binaries. Same system as previous post. Results are different. |
|
@antanst We are no longer aiming for binary compatilibity with all JS engines. The XS engine will be used as reference and some results will not match with other engines. The most important thing is that results match across platforms with the same engine. Nevertheless, you can try to find what causes the different outputs like this:
|
|
Ok. Apologies for spamming the thread. Since you asked, I've followed your steps and traced the difference to this code output: Code: Function.prototype.toString = function() {
return '[Function]' + this.name;
};
g = 1
g += function() {}
console.log(g)Outputs of vanilla Node 8 and 10: Output of Chackra Node v10: Looks like a vanilla Node bug. |
|
Interesting find. To me it looks like Chackra Node v10 bug, because the anonymous function doesn't have name |
|
Ryzen 1700x |
|
The fact that Rasberry PI is an efficient option should be a huge warning flag that this is not an ASIC resistant PoW. These numbers indicate that the additional complexity of Intel’s branch prediction, cache lookahead, etc is not worth the gates. An ASIC designer will be writing a very simple, small-gate CPU-type thing which runs direct execution from the generator algo with no parsing, interpretation, bytecode, object code, or anything else needed in general purpose CPU’s. An ASIC will put lots of slow but small cores into a chip, and the design will not take long because they can exclude all the fancy stuff Intel and AMD do. ARM cores are easily licensable and customizable for particular applications. |
|
Specialized ARM core with proper core-to-cache ratio will be ~2 times more power efficient. I don't see a big problem with it. Many manufacturers can produce ARM cores because you said yourself they're easily licensable. This ARM-based hardware will be just like tuned Raspberry Pi, it can/will be used for other stuff apart mining. |
|
2x is huge in mining. As we have seen, hashrate will increase to the point where it’s barely profitable vs electricity. A 2x ASIC means home mining on CPU is not profitable. Everyone will need the ASIC. |
|
CPU mining is a different world. First, having just single CPU + motherboard + RAM + power supply is already very inefficient. Buying specialized ARM boards and connecting them to the same power bus will be the way to go: https://www.youtube.com/watch?v=i_r3z1jYHAc&t=284s |
|
There will also be PCI-e boards with many small ARM cores like Xeon Phi. And we'll be back to making rigs on PCI-e risers 💯 |
|
It’s true. That world would be ok. But I’m not convinced I can’t make an ASIC that’s faster than the ARM for running RandomJS programs only. |
I added a new test project which can be used for testing results on different platforms.
If you want to test it on your platform:
node sandbox.js./Tevador.RandomJS.Test.exe --threads 2 --seed 123 --count 1000The number of threads can be adjusted according to the number of cores of your processor. The command generates 1000 random programs and calculates a cumulative hash of all the outputs.
So far I have tested:
In all cases the result is
3cc26d6be7f5f542e8037247deec69c2e3a3d70db67dac5371f86e06fbe3c8cc.(Valid as of commit 79d3c4c)
The text was updated successfully, but these errors were encountered: