Re: [DISCUSSION] Hexagon code inside kernel

[cotulla@yandex.ua]

> šWell.... you are using memb to copy one byte at a time, instead of
> šmemd which will copy 8 bytes at a time. ššSo that change alone should
> šmultiply performance by 8.
>
> šYou can almost surely be more clever, and move the if statement and
> šthe increment into a packet, so that they execute in parallel. šIts a
> švliw, its very parallel, that needs to be exploited. šFor example, (if
> šI remember correctly (?)) you can set and read r2 in the same packet,
> šthe read will get the old value, the set will write the new value.
> šYou can move the jumpr into the next packet, if you don't mind copying
> šone extra byte. ššSo there are many tricks like this.
>
> šI don't remember the details any longer, but there are cases where the
> šcompiler would inline some fairly efficient memcpy code. ššAlso .. the
> šcompiler is smart, in general -- šyou should try writing the loop in C
> š(and using 64-bit words) and seeing what it generates.
>
> šAnd finally, aren't there some optimized memcpy assembly routines in
> šthe kernel? I know we kept talking about these...
>
> š--linas

Yes, there is an optimized memcpy version.
But my goal was to "compare" ARM performance with QDSP6 to know what to wait from it.
So I made a simple C code and tested it on both processors.

And there is a difference between them. My question was in general: do you think it's normal or QDSP6 should work faster/slower? 
Did you test performance inside Linux on Hexagon?


-Cotulla