Parallella Community

Gravis, could you go easy on the personal insults, which started with the snippet of your response to Bikeman that I quoted?

We are here to discuss technology and its application, not pass judgement on each other.

Now back to the technology: my personal view on benchmarks is that the only one that matters is your application. Sometimes one can identify a proxy for one's application - for example when I worked in CFD some of the SpecFP test cases gave results that correlated very well with the performance of our codes on the various architectures to which we had access - across the spectrum from CISC to RISC to VLIW.

Personally I've never seen the point of micro-benchmarks because they can only be used to predict system performance if one knows exactly what operations will be used in the application of interest when targeted to that particular architecture. In my experience it has usually been easier (and less error-prone) to port a representative test-case and measure the resulting performance.

Although I dislike the GPU programming model, the bottom line is that if it delivers the best price-performance ratio for the application I'm working on, I'll hold my nose and use it.

Mark

P.S. The other problem with micro-benchmarks is that it is easy to introduce architecture bias in the benchmark set (Intel used to do this to "prove" their x86 processors were better than AMD's). The obvious one to include is double-precision floating-point which is the bread-and-butter of HPC.

Regarding applications, judging from this post the architecture is a good fit for neural networks. IMO the clever mesh NoC would be really useful in simulations based on cellular automata, but to my surprise no-one has turned up here wanting to use Epiphany chips for CA.

As an architecture Epiphany really gets interesting as the core count goes up - say from 64 cores upwards - as the amount of on-chip RAM gets closer to what is needed for real-world data sets. In a way the non-arrival of the E64 is a good thing: hopefully Adapteva will be able to crack the code-space size problem* and when the E64 does arrive it will be suitable for a wider range of applications than the present E16.

Mark

* the limited code space and the fact that if the external memory penalty is to be avoided each core must have a full copy of the computational code in its precious SRAM is a double-whammy. {Edit: the papers linked to in describe the challenge much more eloquently than I could...]

Rather than start a new thread, this is a vaguely connected question - what are the best performance numbers we have for Epiphany matmul-16 and -64?

From the Adapteva website, there is a with a run-time of 108ms for matmul-64 (equivalent to 2.49 Gflops).

And in we have a time of 157ms for matmul-16.

I'm slowly benchmarking other multicore architectures on this problem (using whatever approach is best suited to each architecture) so would like to use the best available Epiphany results in the comparison. At a peak 1.2Gflops/core the Epiphanies ought to be doing better than the above times... but on the other hand there's an early paper on the Adapteva website () that indicates that on the EMEK platform matmul-64 was spending 95% of its time waiting for the DRAM.

Since as noted above I'm mostly interested in problems that fit into on-chip RAM (& chips or systems big enough for such problems!) I'm tempted to use the published cycle counts for computation and data movement on matmul-64 as an estimate for Epiphany performance in the absence of the DRAM bottle-neck, i.e. 34.8 Gflops.

Mark