Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 08 Apr 2015 21:22:39 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New SIMD generations, code layout

On 2015-04-08 14:27, Lei Zhang wrote:
> I tried those formats listed in your mail. They all passed the tests
> on MIC. Currently there're some ugly workarounds for MIC in
> pseudo-intrinsics.h, as MIC lacks some features in AVX-512, like
> shuffle_epi8 and unaligned loading. I'll try to fix them first.

I now have all formats running fine under AVX2 except md5crypt (I have
asked Bartavelle for help - I can't tell what is hard-coded widths in
disguise and what isn't), Oracle11 (probably some easy fix) and Dynamic
(including thin dynamic formats) which is totally busted - I'll leave it
for Jim to finish.

BTW to avoid dynamic's segfaults you can test all formats except dynamic
like this:

../run/john --test --form:cpu-dynamic

I guess md5crypt will segfault for you too, so you also need to add that
one as "disabled" in john.conf

[Disabled:Formats]
DEScrypt-opencl = N
md5crypt = Y

Then hopefully, the rest of the formats will pass the test or at least
not segfault. If they do you might need some MIC tweaks but they should
all be vector-width-agnostic now. Once it works at all, you can probably
optimize quite a few things (that's also a pending task for AVX2).

> BTW, the filename sse-intrinsics.h/c and those functions prefixed
> with "SSE" in it seem a bit odd now, since they're no longer targeted
> to SSE only. Maybe some refactoring is needed.

Yes I guess we could rename it to just intrinsics.c and functions like
SSEmd5body() could be SIMDmd5body() or v_md5body().

But let's postpone that. SIMD_COEF_32 was called MMX_COEF until just two
weeks ago for legacy reasons :-)  Or perhaps I should refactor them just
before merging the avx2 topic branch into the main branch.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ