Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 7 Jul 2013 23:38:53 -0400
From: Yaniv Sapir <>
Subject: Re: Parallella: bcrypt


It is a little bit hard to follow your question - I hope I get it right:

I changed one thing in the code I sent in previous emails and now it works.
> I did something you recommended not to do - I used e_write and after it I
> used e_load_group(). Now both minimal and full code work.

That's great.

> But I put it after e_writes to local memory.

What is the "it" you refer to? What did you put after the e_write()?

> If I put e_load after writing to shared dram than it doesn't work.

Probably b/c you overrun the whatever is in the DRAM with the
initialization values of the external objects that are written by the

> On the other hand, if it's before e_wirtes to core's local memory than
> data in local memory isn't correct for some of the cores.

If you launch the program (E_TRUE input to e_load()) before writing the
data, there surely is a situation where you are actually processing garbage

> I got it working in one more way. If I start cores using e_start() after
> e_write() (attached code) than it also works.

.... which is why this method works. You load, then write data, then start

> Can this happen because e_write() to core's local memory stalls, cores are
> started before data is ready and write to shared memory happened before
> write to local memory

Looks like you got it right (except that the writes don't need to "stall"
for this to happen - see previous note).

> (although this doesn't explain how I get wrong data which is similar to
> correct data - something is written but not what I send from host, and it
> shouldn't be old data since e_reset_system is performed before writing
> anything)?

When you have races, they can explain more than you think... :-)  However,
having similar but bit correct may be a problem with host and device
structure alignment mismatch, as we discussed earlier. It can be that a
structure member is moved in memory so offsetof() operator won't return
same offset in host and device. Anyway, e_reset_system() only ensures the
resetting of system and core registers, not memory (and definitely not
External Memory), so it is possible that you process leftovers from
previous runs.

And how are e_write() calls executed? Always in same order as invoked in
> code or there is difference between e_write() to shared memory and
> e_write() to core's local memory?

The e_writes() are executed in order, BUT travel to different cores, and
even more, to External Memory, is done in different, independent paths.
Thus you should (generally) not assume that transactions are fulfilled in
the order they were executed.

> Output.txt has output for minimal code, first one is what I get when
> executing code from, second one is what I get when putting
> e_load_group() after e_write() used to write hash to core's local memory.
> At the moment I'm not even thinking about performance, I just want to make
> it work when executed in a loop and the only approach that works with only
> one call to Epiphany doesn't work when there are multiple calls.
> Katja

Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
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
 intended only for the use of the individual or entity named above. If you
not the intended recipient, you are hereby notified that any disclosure,
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
contents and notify Adapteva.


Powered by blists - more mailing lists

Your e-mail address:

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