Hello, I’m starting this thread to discuss ideas about
support for many-core floating-points accelerators.
As it was said in wiki it could be for example:
-further development of Performance Counters
and Block Core Affinity
-implementing message passing using on-chip networks
Hi,
Hello, I’m starting this thread to discuss ideas about
support for many-core floating-points accelerators.
As it was said in wiki it could be for example:
-further development of Performance Counters
and Block Core Affinity
Shouldn’t we work on actually running any of the blocks on the
accelerator before trying to benchmark them ?
Cheers,
Sylvain
Hi Sylvain,
On 18 April 2013 08:56, Sylvain M. [email protected] wrote:
Hi,
Hello, I’m starting this thread to discuss ideas about
support for many-core floating-points accelerators.
As it was said in wiki it could be for example:
-further development of Performance Counters
and Block Core AffinityShouldn’t we work on actually running any of the blocks on the
accelerator before trying to benchmark them ?
Of course, but the suggestion was that a GSoC project involving
Parallella should do more than just port blocks this could be part
of the project but not all. I believe Tommy T. II has started
working on porting, but I am not sure how far he will get before a
student would need to start their project.
Cheers,
Andrew
–
Andrew B.
http://carrierdetect.com
Or possibly more interesting and significant for the future,
heterogeneous
processors in a system. We’re seeing lots of this with ARM’s on FPGA’s,
GPU on ARM based SoC, … In addition to homogeneous multicore
processors with interesting network fabrics…
Ideally, an architecture-aware scheduler could capitalize on all
available accelerators / heterogenous processors, and could maximize
performance for that system.
Unfortunately right now we’re limited to porting a subset of blocks to
these accelerators.
Tommy James Tracy II
Ph.D Student
High Performance Low Power Lab
University of Virginia
Phone: 913-775-2241
On Thu, Apr 18, 2013 at 4:16 AM, Andrew B. [email protected]
wrote:
Andrew
Yes. We certainly need to get blocks ported over to the chip to do
anything. From a GNU Radio standpoint as a GSoC project, that’s not
particularly interesting to us, just work that has to be done. What
we’re interested in as a project is improving our understanding of
both many-core processors as well as the use of coprocessors for
signal processing/SDR work.
Tom