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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.