From: Nomen Nescio on 7 Mar 2010 06:40 http://www.das-labor.org/wiki/AVR-Crypto-Lib/en I was stunned to see that the ASM (assembler) implementation of AES is more than ten times (!) as fast as the C implementation. I'd have thought that compiler technology had narrowed the difference to maybe 10-20%. The compiler is probably GCC-AVR, which isn't as advanced as say, the Microsoft compilers, but the difference is remarkable.
From: Tom St Denis on 7 Mar 2010 07:25 On Mar 7, 6:40 am, Nomen Nescio <nob...(a)dizum.com> wrote: > http://www.das-labor.org/wiki/AVR-Crypto-Lib/en > > I was stunned to see that the ASM (assembler) implementation of AES is > more than ten times (!) as fast as the C implementation. I'd have > thought that compiler technology had narrowed the difference to maybe > 10-20%. The compiler is probably GCC-AVR, which isn't as advanced as > say, the Microsoft compilers, but the difference is remarkable. Say what? GCC on x86 *is* more advanced than MSVC by a long shot. Most lilkely though GCC for AVR isn't 100%. Just like GCC for ARM is not as good as ARM's own compiler. It's not uncommon to see assembler based AES 2-3 times faster than C. It shouldn't be 10x though...
From: Tom St Denis on 7 Mar 2010 17:56 On Mar 7, 2:45 pm, henno <hennobrand...(a)gmail.com.invalid> wrote: > Tom St Denis wrote: > > On Mar 7, 6:40 am, Nomen Nescio <nob...(a)dizum.com> wrote: > >>http://www.das-labor.org/wiki/AVR-Crypto-Lib/en > > >> I was stunned to see that the ASM (assembler) implementation of AES is > >> more than ten times (!) as fast as the C implementation. I'd have > >> thought that compiler technology had narrowed the difference to maybe > >> 10-20%. The compiler is probably GCC-AVR, which isn't as advanced as > >> say, the Microsoft compilers, but the difference is remarkable. > > > Say what? GCC on x86 *is* more advanced than MSVC by a long shot. > > Most lilkely though GCC for AVR isn't 100%. Just like GCC for ARM is > > not as good as ARM's own compiler. > > > It's not uncommon to see assembler based AES 2-3 times faster than C. > > It shouldn't be 10x though... > > It could be if you used the new AES instructions in x64 chipset introduced in > the i5 and i7 proecessors. Strictly speaking I don't consider those comparable. Those instructions are really just hardware offload of AES. It'd be like having a mem mapped device sitting as a look-aside device. Besides, strictly speaking there is no reason a C compiler can't also use them. If it can determine that a function executes the AES ECB decrypt/encrypt for instance it could just map it onto the relevent functions :-) Tom
From: Tom St Denis on 8 Mar 2010 09:11 On Mar 8, 7:45 am, Paulo Marques <pmarq...(a)grupopie.com> wrote: > Nomen Nescio wrote: > >http://www.das-labor.org/wiki/AVR-Crypto-Lib/en > > > I was stunned to see that the ASM (assembler) implementation of AES is > > more than ten times (!) as fast as the C implementation. I'd have > > thought that compiler technology had narrowed the difference to maybe > > 10-20%. The compiler is probably GCC-AVR, which isn't as advanced as > > say, the Microsoft compilers, but the difference is remarkable. > > The AVR is an 8-bit microcontroller that struggles to handle the 32 bit > values that most AES implementations use. > > As an educated guess, the assembler implementation is probably able to > use the 32 8-bit registers available to hold the internal state of the > AES and even do some of the movement operations by simple register > "renaming". In an AVR, a memory load or store operation takes 2 cycles. > Avoiding them by using only registers is a major speed up. True, keep in mind ATMEL did design a 32-bit AVR core as well. It's very similar in IA to ARM [from what I recall], but it's also about 2x slower [or less efficient, take your pick] than an ARM7 so ... Tom
From: Noob on 8 Mar 2010 09:18 Tom St Denis wrote: > True, keep in mind ATMEL did design a 32-bit AVR core as well. It's > very similar in IA to ARM What's IA? Did you mean ISA?
|
Next
|
Last
Pages: 1 2 Prev: Active sboxes Next: When did Microsoft buy eBay? I seem to have missed that. |