Matrix multiplication on PARALLELLA IV

[roberto]

[ysapir]

Wow, this is an old one... This test was performed on a system which is obsolete for a very long time now. Anyway, the host machines we used for the EMEK eval kits was a Compaq 100B SFF desktop:

http://h10010.www1.hp.com/wwpc/us/en/sm ... html?dnr=1

It was configured with Ubuntu 10.04.

[roberto]

what make epiphany interesting is:

- cost per chip,
- consume of energy
- "number cruncing" capability.

the new Atom at 22nm are reducing size, consume, and run normal x86 code. It will be interesting a "comparison challenge" to compare all parameters.
I have no the hardware to test, but it will be interesting if someone that own the new 22nm atom (that are low watt consuming) try to compare with parallella.

At the moment, i will be perplex to choose where to run code because "hardware" solution (epiphany) versus "software" solution (x86) seems not to be clear who is the winner. x86 can run code without to recompile, epiphany need to revrite the code but it promise a fast parallel computation... so, different parameter to me take in consideration by programmers ad boad developers.

the idea of a cheap , no-energy-hungry, coprocessor is smart, but for the moment, the fast technology progress of x86 seems to outstrip the actual prototypes at 64 cores you have under power calculation viewpoint. I think it will became clear (read: epiphany coprocessor is the winner under all viewpoints) only with future versions, when there will be at least 1K cores, withe lesser transistor nm size and hopefully at higher clock rate.

On the market there are alternatives: fast x86 multicore cpu, coprocessor, FPGA... it will be nice to see the evoluton (maybe converge) of these different technologies.

[roberto]

Hello,
i thought again about this topic.
Relate to performances on ALLWINNER, (19sec for squared matrix of 512 elements) i was able to go under 3 sec (2.8), simply unrolling partially the inner loop. Of course a dedicated hardware cannot be defeated, but a more smart way-to-code can offer good speed up (6.6x) without any need of further hardware. So, before to think to get more powerfull hardware, better to sharp my own mind

[ysapir]

Indeed we were able to see massive speedups by just rewriting the code, keeping in mind the underlying architecture strengths and limitations, and using proper compiler command line options to generate code that is not under the influence of the source code.

[mhonman]

roberto, the sample code you posted in the first thread has arrays of int.

The Epiphany matmul example has arrays of 32-bit floating-point numbers (which is what one wants to solve "interesting" problems). Would you mind re-running your test with floats? Older Intel CPUs were quite weak on floating point, I'm not sure how much better the core i's are.*

[correction: on the Core2 architecture, F.P. operations typically take 2 cycles but the processor can complete two of them per cycle whereas an e-core can retire 1 add-multiply per cycle. In that specific case (add-multiply) a single 600MHz e-core can theoretically attain half the performance of a 2.4GHz Core 2 Duo core. Intel documentation seems to indicate that the Core i architectures are similar to Core2 in this regard].

Note that double precision (64-bit) is not implemented in the e-core hardware and will be very much slower than single-precision.

* also to make a really fair comparison, one would want to compare SIMD instructions on the Intel CPU against hardware loops on the Epiphany

[mhonman]

[toralf]

[mhonman]

It's not a parallel solver, just multiple instances running at the same time. The objective was to establish a baseline performance in the absence of communication and coordination. What it does show is that compared to a shared-memory multi-core system, there is no penalty for running 16 copies of the same job simultaneously.

[roberto]