Announcement (2017-05-07): www.ruby-forum.com is now read-only since I
unfortunately do not have the time to support and maintain the forum any
more. Please see rubyonrails.org/community and ruby-lang.org/en/community
for other Rails- und Ruby-related community platforms.

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
http://forums.parallella.org/viewtopic.php?f=20&t=268

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 Munaut <246tnt@gmail.com> 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 Affinity>> Shouldn'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 Tracy 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 Back
http://carrierdetect.com

On Thu, Apr 18, 2013 at 4:16 AM, Andrew Back <andrew@carrierdetect.com>
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

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