Object Detection

[notzed]

Just posted another update after some hacking on the weekend. Although I still seem to have bugs the bugs are the same in both versions so I finally have some comparative performance numbers. A single epu core is coming in around 1/2 the speed of an ARM one, although i think i can both improve both and close the gap between them.

[aolofsson]

notzed,

Great blog post! Really enjoyed reading it.

*It's possible to run gdb on code running on a core by first launching the 'e-server' and the launching e-gdb with your ecore (epu if you like) elf. It gets harder when you have a cooperative host/slave program.

*Not sure if you are using byte/short data formats at all, but there is a pretty big performance hit for loading anything non- 32 bit from local memory.

*The A9 ARM core is significantly more advanced than the Epiphany cores, so I suppose we shouldn't be too surprised. Still disappointed though. On straight up floating point "filter type code", the results should be closer.

*Is the Parallella time including data transfer time to and from the Epiphany?

Thanks,
Andreas

[notzed]

Thanks on the gdb info - i only need to test smallish routines which can be made standalone. Now i'm more familair with the ISA I can at least get stuff running.

Last night I also updated the post with some new numbers from using a dword aligned data structure - including from an optimised assembly implementation. I kept poking after writing the post and knocked another nearly 10% off the time shown.

The assembly implementation only uses ldrd for every access and where needed 16-bit values are extracted by shift/mask (apart from a couple of ldr's where data is padded for alignment). The c version compiles to code that does some ldrh's and calls some routine which doesn't seem necessary, i think for implementing "foo += float < float ? float : float" (looking it up: ___gtesf2), and anyway the format isn't really optimised for C address calculations since it includes the *4 for a float array offset. I will try a more c-friendly format at some point.

The timing is done host side in a way might not be terribly accurate, but it shouldn't be out more than a few (10's?) ms - it brackets a polled mailbox start/complete cycle.

The timing doesn't include copying the (precalculated) data to the shared memory space from the ARM side, but it does include all the dma/loading from system memory to LDS (local data storage). All dma is dwords. The image data dma is not double-buffered yet, but from my timing code it spends only about 33M cycles waiting for it - which is what, 50ms? That is for 1600 32x32xfloat transfers.

One reason i'm looking at viola-jones detection is the algorithm is kinda shitty as far as hardware is concerned (bandwidth intensive, naively cache unfriendly, simd unfriendly), and by thinking about how to fit it onto epiphany i think i ended up with a much better arm version than i started with - so the comparison to the arm version isn't that bad.

Once i've tried a few more things i'll put together a standalone GPL3 demo and upload it somewhere.

[notzed]

Ahh yeah, so because i kinda forgot about it at first, and then didn't think it would matter as it's such a small amount of memory compared to the rest of the calculation ... i wasn't dmaing in the variance-adjustment data. This is a float value which is read once per window location, or approx (512-20)*(512-20)~=242K times ... so ok, maybe it is a fair amount after-all.

After adding a 12x12 dma chained with the image window load: assembly version is under 1s, and the c version is just over 2s.

Yep, 1 epiphany cpu is now beating 1 arm core, even if it took hand-written assembly to do it ...

I also tried a bunch of other stuff like double-buffering and shaved a bit more off it, but it's getting a bit academic and none of the numbers are really verified.

FWIW I tried aborting the read-ahead dma, despite your warning on the other thread. I write 0 to the dma config register immediately followed by the new descriptor. They're writing to the same buffer. It appears to work and shaves another 0.06s off the running time (but as it's very tricky to validate i haven't verified the total calculation; it may just be luck it appears to work with my test case).

[LamsonNguyen]

This is really nice. Looking forward to the demo!

[notzed]

Made some improvements to memory usage and generality and posted another update about it:



PS the dma-abort hack did end up causing problems, but i found a way to not need it.

[notzed]

Well this is a problem that just keeps on giving. Another (provisional!) jump in performance - this time simply through better instruction scheduling of just one loop. Although i must say they werre the hardest 33 "lines" of code i've written in a while (just not as sharp as i once was).



I have some multi-core numbers now too, although they don't mean much other than in relative terms.

[Gravis]

[notzed]

[aolofsson]