[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKGDhHWoQzv31hZ3rOf3Bx9VEz7gqN+de_YiaYYvtfyoLRsXxw@mail.gmail.com>
Date: Mon, 13 Jul 2015 20:12:46 +0200
From: Agnieszka Bielec <bielecagnieszka8@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Agnieszka's weekly report #10
2015-07-13 19:47 GMT+02:00 Solar Designer <solar@...nwall.com>:
> On Mon, Jul 13, 2015 at 07:19:44PM +0200, Agnieszka Bielec wrote:
>> I switched pomelo to use *_region function but I modified this
>> function a little, I hope you don't mind?
>
> It's not that I mind (if you correctly document what you changed,
> avoiding misattribution), but rather I am surprised, and you need to
> explain what you changed and why. I expected that no changes would be
> needed, unless we want e.g. to rename things to be yescrypt-neutral.
I added only this and of course I renamed
void * alloc_region(region_t * region, size_t size)
{
if(size<=region->aligned_size)
return region->aligned;
>> but in Lyra2 I am using also many very small chunks dynamically
>> allocated like 10-60 bytes. it depends of number of threads and I'm
>> not sure if *_region here makes sense
>
> Maybe not, but this brings up other issues. You need to ensure you
> avoid having these small allocations compete for the same cache lines
> (which may "randomly" happen with separate allocations), yet you also
> need to ensure you avoid false sharing. This is tricky, especially as
> you're unlikely to see these effects on any one system, yet they may
> show up elsewhere. You might want to revisit this as a separate task.
ok, maybe these all values are the same, and if they are the same I
just remove them, sorry that I didn't checked this previously but I
was thinking that this isn't important
>
>> > I've just recalled that there was a BSTY coin miner CUDA implementation
>> > as well, and it's likely faster (but more specialized) than the Lyra2
>> > authors' one. It uses some inline PTX assembly, but it's specialized to
>> > BSTY's older revision of yescrypt and with some parameters hard-coded.
>> > Maybe you'd be able to update it to current yescrypt and generalize it
>> > for arbitrary parameters.
>>
>> I've implemented from yescrypt-opt.c, yescrypt from BSTY miner looked
>> like something else for me
>
> This is confusing, probably because you're confused. The paragraph
> about BSTY that you quoted here has nothing to do with yescrypt on CPU,
> nor with the memory allocation functions.
I meant here yescrypt on GPU - that is based on yescrypt-opt.c and not
on BSTY miner
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.
