-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Competing implementation of RandomX in JavaScript. #306
Comments
web mining was a cool idea but it'll never be as lucrative as ad placement, so webmasters have no reason to adopt it. |
No AES, and no directed rounding means it will never be as fast as a native code. But only 5x difference is impressive. Also, web-mining can't use full mode (2 GB dataset), and that's another 10x slowdown. Also,
That's "I don't understand it therefore it's bad" attitude. C++ is a tool and it can be used in any way, including coding in C-style only. So it purely depends on the programmer, not the language itself to be "good or bad". |
Fwiw, the use of exceptions in the C++ library has been a persistent source of hassles. IMO writing the library in C++ was always a bad idea and I rewrote it in C myself as well to remove these issues. |
I have created an issue on the repository to track possible performance improvements in tiers of how meaningful they may be compared to development cost: |
RandomX.js has been implemented and tested extensively against the ground truth. It reaches a hashrate of 20 H/s per thread, quite higher than the original proposed speed of 1-2 H/s, but still 5x slower than light verification on the same machine (100 H/s). Among 8-16 threads it reaches 150-200 H/s.
I suggest you take a look. This may pave way for feasible webminers, though I doubt it unless I can micro optimise it further or AES-NI instructions are added to WebAssembly SIMD.
The text was updated successfully, but these errors were encountered: