Yes, I've tried. I modified it even more to make working (see the patch below), but, as I've said, the decoded data differs for lookup and computed (this is for 20K elements, I reduced the data set to run the test faster):
Data generated! Look-up: a0 25 45 7b 5f 84 11 0f 16 01 4e 05 8d 68 c9 42 6e c8 10 97 a0 20 55 e6 15 cf 3d a6 81 b2 85 5f Elapsed time: 29 milliseconds Computed: a0 25 45 7b 5f 84 11 0f 16 01 4e 05 8d 68 c9 42 c6 a5 cc ef 00 df c1 a8 26 e9 da 91 c8 47 09 75 Elapsed time: 180 milliseconds I think, something is being done for speeding up external arrays access, I'll let someone else to comment on this. ======== Patch for array/crypto/aes.js: 589c589 < return bytesIn.subarray(start, end); --- > return bytesIn.slice(start, end); 613c613 < var cipherOut = new Array(finalSize); --- > var cipherOut = [];//new Array(finalSize); 703,704c703,704 < var byteArray = new Array(16); < var bytesOut = new Array(cipherIn.length); --- > var byteArray = [];//new Array(16); > var bytesOut = []; // new Array(cipherIn.length); 764c764 < bytesOut.set(byteArray, start); --- > // bytesOut.set(byteArray, start); On Thu, Mar 31, 2011 at 14:33, Simon <[email protected]> wrote: > Have you had a look at this code: > http://www.simonheckmann.de/js/array/cryptotest.html? > > Shouldn't "external" arrays be super fast, because they can be > accessed natively? Additionally, when working with the File API, as > you said, there is no way around "external" arrays. So it would be > nice if they could be sped up, because manipulation of the data is the > actual fun part with this API. > > Kind regards, > Simon Heckmann > > > On 31 Mrz., 11:29, Mikhail Naganov <[email protected]> wrote: >> In your case it might be really better to stick to external arrays for >> input data. >> >> Moving data from an external array to JS heap will anyway require >> data copying and conversion. And currently there is a limit on the >> amount of data that can be stored in JS heap (as I've mentioned >> earlier), so you'll need to swap chunks of your file back and forth >> between native and JS heap. >> >> But, all the internal arrays of AES algorithm can be made regular >> arrays. As I understand correctly, it works on small blocks of data, >> so you will not be hit by size limit. And they will work faster than >> using Uint8Array. >> >> I haven't yet fixed your lookup implementation to work with regular >> arrays and produce the same results as the computed one. If you'll >> manage to change it, please ping me, I'll continue my experiments. >> >> >> >> >> >> >> >> On Thu, Mar 31, 2011 at 13:05, Simon <[email protected]> wrote: >> > 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 > > -- > 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
