[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Oct 2013 07:51:38 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev <john-dev@...ts.openwall.com>
Subject: Re: bcrypt-parallella on 64-core (was: Katja's weekly
report #13)
The problem is not with certain registers, but with certain cores. Cores on
the 2nd row should not *load *or *fetch *from external memory. DMA reads
are OK.
On Wed, Oct 30, 2013 at 4:47 AM, Solar Designer <solar@...nwall.com> wrote:
> 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
>
--
===========================================================
Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
Email: yaniv@...pteva.com
Web: www.adapteva.com
============================================================
CONFIDENTIALITY NOTICE: This e-mail may contain information
that is confidential and proprietary to Adapteva, and Adapteva hereby
designates the information in this e-mail as confidential. The information
is
intended only for the use of the individual or entity named above. If you
are
not the intended recipient, you are hereby notified that any disclosure,
copying,
distribution or use of any of the information contained in this
transmission is
strictly prohibited and that you should immediately destroy this e-mail and
its
contents and notify Adapteva.
==============================================================
Content of type "text/html" skipped
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.
