run m/n children, then do the next iteration for c children while at the same time running previous iteration for another m/n, dropping some of the c children if their performance from previous iteration wasn't enough. with each iteration you'll have to handle more and more generations in parallell till you max out the number of cores, at which point all children will have been tested for the previous iteration.
but if you insist on usung parallella for genetic AI, you could use a similar strategy, this time with compression of data in mind when choosing which children to run in parallell...
Statistics: Posted by piotr5 — Mon May 11, 2015 12:00 pm
]]>
A GPU is designed to do the same, simple operation on a large data set. So I'm guessing it could be faster if you generated a lot of children at each step. But after you generate children you also have to know which child is the best, which generally means some kind of validation and test on the data. So there is a need to switch between operations. That's why I tend to think that if you want to generate less children and more iterations, instead of more children and less iterations, the Parallella might be a better processor for it.
But honestly I really don't know. It would make for an interesting benchmark. But until the Epiphany has access to faster shared memory the Parallella will probably end up being slower - unless the data set the algorithm is being applied to can fit in the 32kB.
Statistics: Posted by louloizides — Mon May 11, 2015 11:18 am
]]>
]]>
)Andreas
Statistics: Posted by aolofsson — Thu May 07, 2015 7:37 pm
]]>
So will the newer more optimal implementation just be a software update? If so that'd be awesome.
This last project I did was just a simple term project since I wanted to try the board out. But I have an AI application in mind for a thesis that it could be useful for. I need an embedded device that could search through a decent sized data set & search space in a short period of time (particularly genetic searches). I was hoping I might be able to use the Parallella, but right now the off-memory access is probably too slow. If a software update improves that at some point it'd be awesome. Otherwise for future revs it'd be great if there was some decent bank of memory (even a couple of MB or so) close to the chip and accessible using DMA. It'd make a *huge* difference. The Epiphany really flies without that one bottleneck
Thanks,
Lou
Statistics: Posted by louloizides — Tue May 05, 2015 8:56 pm
]]>
]]>
]]>
]]>
]]>
]]>
1) Why does it get so hot? I can't seem to use passive cooling on the Parallella... Is it the SRAM? And will that hurt the chip's ability to scale up?
2) Why does an MIMD processor use less power than an SIMD one?
3) From most of the benchmarks I've seen here, reading and writing to shared memory is about 150 MB/s. But the off-chip bandwidth is supposed to be 8 GB/s. Is the slow speed because of the FPGA? Could the board be redesigned to have some dedicated shared memory closer to the chip? (something like an L2 cache). My SUMMA implementation is scalable, so that memory transfer to/from shared DRAM is really what's killing the speed.
FYI, these are basically the results I'm getting for the paper... I'd imagine this could be improved quite a bit but it's good enough for a term paper for a single class
(not a thesis or anything). All Epiphany results were validated against the naive version.Statistics: Posted by louloizides — Sun May 03, 2015 4:14 pm
]]>