> No, it's faster, try it -- at least the version that produces incorrect > results. > I wonder, if a correctly working version will still be faster.
I think it will be. It is probably just a shiftRows issue, which leads to invalid results. It is working with "galois.html". > Let me repeat the question: why don't you want to run AES algo on > JS arrays, and use external arrays for input data only? You will only > have inefficiency on reads and writes to external arrays, not in processing. So your suggestion is: Open the file with File API, convert this into Uint8Array, convert this into regular Array, do the AES magic, convert back to Uint8Array, convert to Blob, hand data to the video tag. And you are sure this is faster? > I would expect recent V8 builds (starting from version 3.2.5) to be pretty > fast at this. Actually, I am using Chrome 12 with V8 3.2.5.1. It does not seem any faster to me, than in other builds. Kind regards, Simon Heckmann On 31 Mrz., 14:05, Mikhail Naganov <[email protected]> wrote: > On Thu, Mar 31, 2011 at 15:43, Simon <[email protected]> wrote: > > Great! Don't worry about the different results, that might be an issue > > with my implementation logic. > > I will fix this later, but I though there is no need to fix it as long > > as it isn't any faster. > > No, it's faster, try it -- at least the version that produces incorrect > results. > I wonder, if a correctly working version will still be faster. > > > So, let my summarize this: It would work faster with "normal" arrays, > > but in my case this is not applicable because they are a) not capable > > of containing that much data and b) I would have to convert my data > > every time back and forth, right? > > > So bottom line: There currently is no way to efficiently process a > > file read using the File API with javascript?!?! > > Let me repeat the question: why don't you want to run AES algo on > JS arrays, and use external arrays for input data only? You will only > have inefficiency on reads and writes to external arrays, not in processing. > > > Just one thing I don't understand: Why is the golois.html test so fast > > even with Uint8Array and it only gets slow once I add the rest of the > > slowAES code? > > I want to verify profiles using hardware profiling. I wanted to do > this in V8 shell, > but as Uint8Arrays are only available in browser, it seems I will need to > profile Chromium. I'll try that later. > > > > > > > > > Any further comments are highly appreciated, especially on plans on > > how to increase performance on Uint8Arrays! > > > Kind regards, > > Simon Heckmann > > > On 31 Mrz., 13:22, Mikhail Naganov <[email protected]> wrote: > >> 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 > > ... > > Erfahren Sie mehr » -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
