Okay, that sounds great! The problem is: I actually do not fill the array in my real application with random data. I get it from a local file read with the File API. This comes as a ArrayBuffer. So how to I efficiently turn this is into a regular array? Conversion to a Uint8Array is rather simple. How do I slice my file in small enough pieces, so it works with regular arrays? Will Uint8Arrays ever get faster resp. as fast as regular arrays? Why is it so much faster in the other test cases and slows done only in the full scenario?
Thanks for your input so far! Kind regards, Simon Heckmann On 31 Mrz., 10:32, Mikhail Naganov <[email protected]> wrote: > Hi Simon, > > I've already started modifying your code to switch back to Arrays. > There are two things to consider: > 1) Arrays are allocated inside V8 JS heap, so their size is limited to > ~512M on a 32-bit version and ~1G on a 64-bit version. While > Utf8Arrays are allocated in C++ heap, so they can be bigger. And they > can actually give different speed because access to JS arrays can be > better optimized by V8. > 2) You need to replace 'subarray' with 'slice', and 'set' with regular > writing to an array. > > I already have a version of cryptotest that works with Arrays, and the > look-up version is 10x faster than computed. But they produce > different results, so I'm not sure I've fixed all the stuff the right > way. Currently I'm comparing your version of aes.js to the original > one. > > > > > > > > On Thu, Mar 31, 2011 at 12:12, Simon <[email protected]> wrote: > > I have now modified the code to use regular Arrays only, but this does > > not work at all. It doesn't even finish the test. Chrome 10, 12, and > > Nightly all crash showing me the "Oh snap!" page. I downloaded the > > modified code here if you want to test it yourself: > >http://www.simonheckmann.de/js/array/cryptotest.html > > > Kind regards, > > Simon Heckmann > > > On 30 Mrz., 22:29, Simon <[email protected]> wrote: > >> Hello, > > >> thank you for testing this. I will try it with a regular array, but I > >> don't think this will change anything! > > >> I looking forward to hearing from your results. I tested it with > >> Chromium nightly builds, both Mac and Windows 7. > > >> Kind regards, > >> Simon Heckmann > > >> On 30 Mrz., 22:11, Mikhail Naganov <[email protected]> wrote: > > >> > Hi Simon, > > >> > I was able to reproduce your results on a recent build of Chromium. > >> > This looks quite interesting indeed. I have no idea right now, why > >> > this happens. Tomorrow, I'll try running your code in a V8 shell and > >> > profiling using hardware counters on Linux. Maybe this will give more > >> > insight. > > >> > BTW, why do you use Uint8Array instead of an ordinary Array? Have you > >> > tried the latter, does it change anything? > > >> > On Wed, Mar 30, 2011 at 18:49, Simon <[email protected]> wrote: > >> > > Hallo Florian, > > >> > > thanks for you reply and sorry for taking that long to write back, I > >> > > used the last week to perform some detailed tests and analysis and > >> > > write some test code. Here are my findings: > > >> > > 1.) I have written a reference implementation of the two different > >> > > "mixColumns" function in c to verify that array look-up is indeed much > >> > > faster then re-calculating the values every time. You can view the c > >> > > implementation here (www.simonheckmann.de/js/galois.c). > > >> > > 2.) I ported this implementation back to javascript > >> > > (www.simonheckmann.de/js/galois.html). It compares the actual > >> > > calculation (116,435ms) vs. the look-up (25,548ms) in an array. As > >> > > tests show the look-up is still much faster (4x) then the calculation. > > >> > > 3.) Now comes the wired part: When I use the original slowAES > >> > > implementation (computing the Galois multiplication) and compare it to > >> > > my modification (look-up of Galois multiplication), they actually take > >> > > the same time (www.simonheckmann.de/js/cryptotest.html) Even more > >> > > interesting is that functions that took nearly no time in the CPU > >> > > profile now take more time then before. The following screenshot > >> > > illustrates this:www.simonheckmann.de/js/profiles.png(compare > >> > > functions "shiftRow" or "addRoundKey" for example). > > >> > > I also tested this in Firefox 4. It takes much longer then in Chrome, > >> > > but at least, the array look-up is faster there. > > >> > > I hope this helps and you have an idea what this is all about! > > >> > > Kind regards, > >> > > Simon Heckmann > > >> > > On 24 Mrz., 12:04, Florian Schneider <[email protected]> wrote: > >> > >> Hi Simon, > > >> > >> Thanks for the observation. It not easy to say from a distance what > >> > >> the > >> > >> performance problem could be. Do you have a little test program using > >> > >> this > >> > >> library that shows the performance difference? It would be very > >> > >> helpful for > >> > >> us to diagnose the issue further. > > >> > >> Thanks, > >> > >> Florian > > >> > >> Den 22. mar. 2011 15.13 skrev Simon <[email protected]>: > > >> > >> > Hello everyone, > > >> > >> > I have been playing around with JavaScript AES CBC encryption of a > >> > >> > 25MB video file. I encrypt the file on the server with PHP which > >> > >> > takes > >> > >> > only a few seconds. I then use the library slowAES [http:// > >> > >> > code.google.com/p/slowaes/] to decrypt the file in the browser. The > >> > >> > decryption took 5 minutes. I profiled the code with the chrome > >> > >> > developer tools and found out that the function "mixcolums" was be > >> > >> > far > >> > >> > the slowest. I had a look at this function and found out, that the > >> > >> > Galois Field multiplications could also be done by table lookup > >> > >> > which > >> > >> > should be much faster. So I changed the code to do the look-up > >> > >> > instead > >> > >> > of calculation everything new everytime. But the code was actually > >> > >> > slower then before. Now I would like to know: Why is this? Should > >> > >> > array look-up not be the fastest method of doing things? > > >> > >> > Kind regards, > >> > >> > Simon Heckmann > > >> > >> > -- > >> > >> > v8-users mailing list > >> > >> > [email protected] > >> > >> >http://groups.google.com/group/v8-users > > >> > > -- > >> > > v8-users mailing list > >> > > [email protected] > >> > >http://groups.google.com/group/v8-users > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
