29 ms·

Cool concept and a great usage of WebWorkers. I can see this being useful to verify the integrity of files uploaded via an HTML form - get the SHA1 client-side

by pygorex 15y ago

Cool concept and a great usage of WebWorkers. I can see this being useful to verify the integrity of files uploaded via an HTML form - get the SHA1 client-side and verify it against a SHA1 server-side. Unfortunately this implementation is way too slow for large files. In Chrome 15 OSX running a Core 2 Duo 2.4GHz an ~650MB file takes about 9.3 minutes to calculate the resultant SHA. Using openssl the hash generation takes ~8 seconds. (Bearing in mind that it's not fair to compare an interpreted script against a compiled program.)

est 15y ago
in IE they have a CAPI activex which allows javascript to call Win32 Crypto API. I think it would be cool if HTML5 could include something similar. You know, native speed md5, sha1, secure random number, HMAC , etc.
HardyLeung 15y ago
I think this is a fair comparison and the truth (that many cannot swallow) is that Javascript is simply too slow for non-trivial computations. All these talks about Javascript finally catching up in speed to native, and now a slightly non-trivial algorithm and Javascript falls flat in its face. I got similar result to pygorex in my run, and the Javascript implementation is indeed 60X slower than native. Now compare that to HashSum, a a Silverlight-based implementation of the SHA-1 (I verified that it generates the same result), I clocked it and it is 20X faster than the Javascript implementation, and ~3X slower than native. Try it at http://www.hashsum.com http://www.hashsum.com (I wrote it; Silverlight required; sorry about the ad/layout, it was an "exercise" a while back). So HTML5/Javascript is the future, and the future does not include Flash/Silverlight. Perhaps. But this experiment shows that Javascript is clearly way too slow compared to native or plugin. You could argue that the plugin-based scenario is going out of favor. Politics, competition, distribution, etc, are all valid reasons. But "Javascript is now just as fast" isn't one, because it is not. Those who are gung-ho about how fast Javascript is needs to write their own SHA-1 implementation that beats http://www.hashsum.com http://www.hashsum.com ... or at least not be blown away by it.
jorangreef 15y ago
Browsers have not yet fully optimized the performance of typed arrays (a month or two ago they could be slower than normal arrays): 1. http://blog.n01se.net/?p=248 http://blog.n01se.net/?p=248 2. http://code.google.com/p/chromium/issues/detail?id=70675 http://code.google.com/p/chromium/issues/detail?id=70675

by pygorex 15y ago

est 15y ago

in IE they have a CAPI activex which allows javascript to call Win32 Crypto API. I think it would be cool if HTML5 could include something similar. You know, native speed md5, sha1, secure random number, HMAC , etc.

HardyLeung 15y ago

I think this is a fair comparison and the truth (that many cannot swallow) is that Javascript is simply too slow for non-trivial computations. All these talks about Javascript finally catching up in speed to native, and now a slightly non-trivial algorithm and Javascript falls flat in its face. I got similar result to pygorex in my run, and the Javascript implementation is indeed 60X slower than native. Now compare that to HashSum, a a Silverlight-based implementation of the SHA-1 (I verified that it generates the same result), I clocked it and it is 20X faster than the Javascript implementation, and ~3X slower than native. Try it at http://www.hashsum.com http://www.hashsum.com (I wrote it; Silverlight required; sorry about the ad/layout, it was an "exercise" a while back). So HTML5/Javascript is the future, and the future does not include Flash/Silverlight. Perhaps. But this experiment shows that Javascript is clearly way too slow compared to native or plugin. You could argue that the plugin-based scenario is going out of favor. Politics, competition, distribution, etc, are all valid reasons. But "Javascript is now just as fast" isn't one, because it is not. Those who are gung-ho about how fast Javascript is needs to write their own SHA-1 implementation that beats http://www.hashsum.com http://www.hashsum.com ... or at least not be blown away by it.

jorangreef 15y ago

Browsers have not yet fully optimized the performance of typed arrays (a month or two ago they could be slower than normal arrays): 1. http://blog.n01se.net/?p=248 http://blog.n01se.net/?p=248 2. http://code.google.com/p/chromium/issues/detail?id=70675 http://code.google.com/p/chromium/issues/detail?id=70675