Would this sha256 function be safe for us to use inside Webcoin? Or is it "mining-specific" in some fashion? I can't see how it would be, just making sure.
Also, do you want to have a go at optimizing Webcoin's JavaScript ECDSA stuff as well? It's the bottleneck in Webcoin at the moment. Any speedup to the elliptic curve point multiplication or big integer math would be a godsend.
Topic: [PATCH] jsMiner: perf improvement (Read 2040 times)
jsMiner actually performs even faster in Chrome than in node.js!
I am not suprised either by the performance gain I got. Some people in #bitcoin-dev wrongly claimed it was already optimized, when I knew it was not.
Don't have time to set up a pull req., sorry.
I am not suprised either by the performance gain I got. Some people in #bitcoin-dev wrongly claimed it was already optimized, when I knew it was not.
Don't have time to set up a pull req., sorry.
I've been looking over the patch. It looks like you found some performance tweaks in the SHA implementation. That is, one area of our code where we just took a literal approach to the algorithm. So, I cannot say I'm surprised it can be cleaned up a bit.
mrb, did you want to setup a pull request on github? I'd like to see about incorporating your changes.
AngelusWebDesign, I was under the impression that browsers like Chrome and Safari did JIT compilation of Javascript... I wonder if inlining constants has as much an effect in those browsers? Either way, I have not looked too much into such techniques, though I should.
On a related note, we have been doing a lot of the backend stuff with node.js, and I must say... the V8 runtime & node.js are purely amazing! The turn around time on HTTP requests is super low, even with high volume. Having used ASP.NET and Rails on numerous other projects I think it'd be safe to say the CPU time and memory footprint of node.js is half of what they normally get.
mrb, did you want to setup a pull request on github? I'd like to see about incorporating your changes.
AngelusWebDesign, I was under the impression that browsers like Chrome and Safari did JIT compilation of Javascript... I wonder if inlining constants has as much an effect in those browsers? Either way, I have not looked too much into such techniques, though I should.
On a related note, we have been doing a lot of the backend stuff with node.js, and I must say... the V8 runtime & node.js are purely amazing! The turn around time on HTTP requests is super low, even with high volume. Having used ASP.NET and Rails on numerous other projects I think it'd be safe to say the CPU time and memory footprint of node.js is half of what they normally get.
1bitcoinplz:
Have you looked into various techniques for Javascript optimization? I did a lot of that a few years ago when I wrote a Warcraft II clone that plays in the browser. I wanted to squeeze every CPU cycle I could out of the Javascript engines/CPUs of the time.
I read up on various things you can do -- I think it helped. You can even "compile" your code using a PHP/C/VB.net program to replace constants with actual numbers. That way, your code is readable/understandable, yet you're not using "variables" when you don't have to.
I wrote my own "obfuscator" as well, which reduced the file size and made it hard to follow.
Have you looked into various techniques for Javascript optimization? I did a lot of that a few years ago when I wrote a Warcraft II clone that plays in the browser. I wanted to squeeze every CPU cycle I could out of the Javascript engines/CPUs of the time.
I read up on various things you can do -- I think it helped. You can even "compile" your code using a PHP/C/VB.net program to replace constants with actual numbers. That way, your code is readable/understandable, yet you're not using "variables" when you don't have to.
I wrote my own "obfuscator" as well, which reduced the file size and made it hard to follow.
Wow!
Thank you. I have not yet looked at your patch, but that is awesome that you were able to increase the performance like that.
I will look over this patch and post back up... But, I did want to post sooner rather than later to let you know that I saw your message.
Thanks again.
Thank you. I have not yet looked at your patch, but that is awesome that you were able to increase the performance like that.
I will look over this patch and post back up... But, I did want to post sooner rather than later to let you know that I saw your message.
Thanks again.
I spent 15min, for fun, looking at possible optimizations for jsMiner. My patch simply inlines some functions, pre-computes constants, and caches array values, and ends up increasing its performance by ~1.7x under V8 (benchmarked within nodejs 0.1.97) on my Core i3-i380UM (1.33GHz), from 8.3 kHash/s to 13.9 kHsh/s.
This means jsMiner is "only" between 1/38th and 1/59th the performance of cpuminer 1.0.1:
* 'cryptopp' algo: 525 kHash/s
* '4way' algo: 825 kHash/s
See http://pastie.org/1995279
This means jsMiner is "only" between 1/38th and 1/59th the performance of cpuminer 1.0.1:
* 'cryptopp' algo: 525 kHash/s
* '4way' algo: 825 kHash/s
See http://pastie.org/1995279
Jump to: