Date: Mon, 03 Aug 2015 12:56:45 +0200 From: magnum <john.magnum@...hmail.com> To: john-dev@...ts.openwall.com Subject: Re: JtR on ARM (NEON) On 2015-08-03 11:34, Lei Zhang wrote: >> On Aug 3, 2015, at 10:58 AM, Solar Designer <solar@...nwall.com> >> wrote: >> On Mon, Aug 03, 2015 at 04:39:38AM +0200, magnum wrote: >>> How slow is NEON with unaligned scalar 32-bit? The raw formats' >>> set_key() read the key (which may be unaligned) using 32-bit >>> loads and places directly in the SIMD buffer. It might be a >>> coincidence that MD4/MD5 happens to get aligned test vector keys >>> and the others doesn't. Other than that I can't see what would be >>> unaligned. >> >> I think we must not have any unaligned accesses on ARM at all. If >> we currently do have any, let's fix that as a bug. >> >> While not completely unsupported, they are tricky: >> >> "How does the ARM Compiler support unaligned accesses?" >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html >> >>http://www.heyrick.co.uk/armwiki/Unaligned_data_access > > I'm not very clear. Are you talking about unaligned vector > load/stores or unaligned scalar load/stores? I think virtually all vector stuff is aligned. But a SIMD build "enables" the "32-bit set_key" I described, which uses unaligned scalar load from 'key' (and aligned 32-bit scalar store in the SIMD buffer). So it's unaligned scalar, but happens only in SIMD builds. > The links you posted discussed scalar load/stores. As we are not > writing ARM assemblies in JtR, the compiler should be able to take > care of scalar variables' alignment for us. That may be why it doesn't crash but gets slow. The compiler may produce inefficient code for this and this function's speed has a huge impact on the fastest formats. The functions were written/tweaked with close monitoring of Valgrind. magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.