Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Apr 2015 19:51:00 +0200
From: ba <>
Subject: Re: [GSoC] John the Ripper support for PHC finalists

On 06.04.2015 18:37, Frank Dittrich wrote:
>   Agnieszka.
> On 04/06/2015 02:40 PM, Agnieszka Bielec wrote:
>> 2015-04-06 11:58 GMT+02:00 Frank Dittrich <
>> <>>:
>>> What problems did you have? Did you mention them in any of your previous
>>> mails in a way that others could understand these problems?
>> I mentioned that I need to know the m_cost value before the kernel
>> compilation. I didn't mention about details because when I was trying with
>> --cost  there was a lot of problems with that and all the
>> time I was discovering a new one
> Instead of adding two new command line options, you would be able to
> access options.loader.min_cost[i] and options.loader.max_cost[i], once
> you implement tunable cost reporting for pomelo, as I suggested earlier:
I have access when I make extern struct options_main options;
all the time I was thinking that all of you want to get this from
arguments passed to init or reset and I was trying to do this
> You should care about cost values that appear in the hashes that
> actually got loaded not just the cost values specified on command line.
I remember about this that the kernel is cached but after
the compilation is auto tuning and  I don't know If it's better to make
only once auto tuning for various parameters or auto tuning many
times for different parameters
> Furthermore, magnum suggested earlier that you could move kernel
> compilation from init() to reset():
I did this
>> 1.first of all --cost only chooses "good" hashes, if I want to read --cost
>> before the kernel compilation I need to use this
> You could access the --cost values specified on the command line, but
> there's no reason to do, see magnum's recommendation to tune for the
> hashes that actually got loaded:
at the first time when reset is called db=NULL so I don't know which
hashes are loaded, sometimes (with or without the --test I don't
remember) reset() is called before init().
>> 3. When I add tunable functions and when I initialize everything in
>> reset() but not in init (like in opencl_mysqlsha1_fmt_plug.c)
>>   - it crashes somewhere beyond my code.
> Then please publish your code on github, mention the
> repository/branch/specific commit, copy&paste the output/error
> message/whatever, and the commands to reproduce the problem you see, so
> that others can help you.
I don't have got this code now. I can recode it if this is important
This opencl implementation using private memory crashes for
even m_cost=2 on --dev=1 and m_cost=5 on --dev=5,6
and I can't do with this more. I know now about the memory
types at graphics cards and their limitations because I tested
almost everything and pomelo smartly exploit this.
I don't know if I should implement this version.

I hope my quotations this time are more normal but I'm afraid of it

If this  opencl implementation using private memory crashes
for even m_cost=2 on --dev=1 and m_cost=5 on --dev=5,6 I don't know if
should I code this
Also I started modifying my old implementation which uses global memory.
I changed around 40% code to keep as long as possible global values
in variables which are private and  the speed is around 30% better.
If I change more, the speed can increase to around 50-80%
I don't know which version of opencl-pomelo should I implement
a) global memory
b) private memory
c) global witch modyfications mentioned above
d) local and global - if m_cost is small (1-3) use local memory
                                 for greater values use c)
e) nothing if GPU can't be faster than CPU

Should I perform more tests for every a)-c)?


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.