OpenCL is the best.

[Dade]

[Ariemeth]

[jar]

[Dade]

[Gedece]

I'm already looking into Python with OpenCL, so far PyOpenCL seems the way to go.

[jar]

OpenCL is great and all, but it's really meant for GPUs. It has language within the standard that doesn't even apply to the Epiphany architecture or other multi-core CPUs.

For example, Epiphany doesn't have OpenCL Local Memory, Constant Memory, Caches, or multiple Compute Units. Instead there is a single Compute Unit built from many Processing Elements which each have a very large amount of Private Memory compared to GPUs. OpenCL also lacks a mechanism for moving data between Processing Elements' Private Memory. The term "Private Memory" is obviously a bit of a misnomer here when it is being shared between Processing Elements. See the overly simplified, cheesy diagram attachment below.

The Epiphany architecture has this Private Memory sharing capability in hardware and is used to extend the OpenCL specification with the memaddr/memcopy/memsync/memsend/memrecv routines found in . Data moved between neighboring Processing Elements in the 2D grid or off-chip to the shared host memory (OpenCL Global Memory).

So the OpenCL model is used where it applies to using Epiphany as a coprocessor/accelerator. And OpenCL is extended where it is lacking obvious capabilities.

See the that uses Private Memory sharing routines.

[calufrax]

The Hetereogeneous Parallel Programming course currently running on Coursera will apparently cover OpenCL... It's geared toward CUDA, but OpenCL is on the syllabus, and the general principles would still apply.

I'd love to see a MOOC course geared toward Epiphany, of course... That would be a way to promote the hardware, and get the impetus for software development...

[dar]

[dar]

Macros, C++ bindings, PyOpenCL, and "solving a problem that doesn't exist" ... where to begin.

First, regarding macro discussion, they are used in stdio.h. All serious code uses macros. Nots sure what the issue is there.

OpenCL is a really useful API. Its also not the best API for all programmers to use directly. (Its also a GPU API, not a multicore API, but that's another discussion.) If you are an OpenGL programmer you may very well not see the problem STDCL "solves". If you are a CUDA programmer its obvious. We (BDT) have received enough praise for developing libstdcl to know that we did some things right. Perhaps you want to use C++ bindings. Perhaps you want to use Python. Every programmer will have their own preferences. What makes the Parallella project exciting is that its completely open and the community will be able provide solutions to problems without vendor approval, or worst, waiting for a vendor to get around to providing a solution. We are looking forward to providing support for Parallella in our COPRTHR SDK. We have some very exciting features planned that we hope will contribute to the Parallella community.

[Ariemeth]

rethought