Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Oct 2013 12:47:52 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bcrypt-parallella on 64-core (was: Katja's weekly report #13)

Hi Katja,

On Tue, Oct 29, 2013 at 09:13:10PM +0100, Katja Malvoni wrote:
> I run self test for bcrypt-parallella format 10 times and counted for each
> core how many times it didn't start computation. Than I tried using only
> cores that didn't start less than 3 times out of ten. Number of such cores
> is 24.
> Computation isn't started always but when it is, performance for those 24
> cores is 1807 c/s (I'm transferring data buffer with data for all 64
> cores).
> After this I tried to use cores that failed 3 times (10 more so 34 in
> total) but I tried 10 times and it didn't work - some cores always fail to
> start computation.

Thank you for trying this.  From Yaniv's replies, I was under impression
that you could fully avoid the CPU bugs by not triggering the known
problematic situations.  IIRC, some cores must not do reads from
external memory to certain registers.  You could structure your code
such that this never happens, although this might be tricky to do while
staying with C (for most of your Epiphany side code).  gcc's ability to
explicitly put certain local variables into specific registers might
help.  The syntax is:

	register suitabletype mylocalvar __asm__("registername");

e.g.:

	register void *p __asm__("r40");
	register int i __asm__("r41");

I am unsure whether this does or does not prevent gcc from possibly
allocating these same registers to something else, though.

Overall, making use of the buggy 64-core chip does start to feel too
problematic, given that you need to spend time on the FPGA project at
the same time.  So giving up on 64-core Epiphany until more reliable
chips are available makes sense. ;-(

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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