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
