[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55304E4C.9030800@openwall.com>
Date: Fri, 17 Apr 2015 03:05:32 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Format interface changes
On 2015-04-16 22:08, magnum wrote:
> Solar,
>
> I think it may be about time we change key index/count variables to
> unsigned int in Jumbo. Rationale:
>
> 1. The previously discussed need for GPU mask mode
> http://www.openwall.com/lists/john-dev/2013/08/22/12 will soon show up
> again. We'll soon need it. I don't really see a need for 64-bit pcount
> though, just unsigned should be enough for a long time.
>
> 2. It makes things like "index/SIMD_COEF_32" that we have in wads of
> SIMD calculations end up as a mere bitshift. The difference is quite
> noticable, just changing NT2 and ignoring the compiler complaints render
> a 4% boost. Before the recent AVX2 changes, we had it as
> "(index>>(SIMD_COEF_32>>1))" but that only works for COEFs 2 and 4. For
> a while we defined a SIMD_SHIFT_32 macro but I dropped it while fixing
> all code for hardcoded widths (that was hard enough without it). Instead
> of re-implementing it now, Sayantan's need came to mind. I'd really
> prefer keeping the division in the source yet not in the compiled code!
I guess this can easily be made with some macros but why bother? I
generally agree that we should use unsigned more. I think it makes many
things easier. It's great that you even have hard data on speed gain.
Maybe change "char *ciphertext" to "unsigned char *ciphertext"?
> Obviously we'll have to make some core code adopt to unsigned too.
>
> What do you think? BTW when we're at it, we could start using "const"
> for pointer arguments where applicable - doing this at the same time
> comes almost for free compared to doing it separately. I'll obviously do
> most of it with grep/sed but there's always a substantial amount of
> manual editing.
Another couple of wild ideas:
- add restrict to help compiler optimize code where we are sure that
parameters cannot overlap. Many parameters are of type char * and I
guess compiler cannot reason about its aliasing because char can be used
to access any data;
- is there need for parameters to be aligned? If many formats will
benefit from this we can enforce it at the level of the interface.
--
Alexander Cherepanov
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.
