Re: [DISCUSSION] Hexagon code inside kernel

[Rob Landley <rob@landley.net>]

On 02/26/2013 12:54:21 PM, cotulla@yandex.ua wrote:
> 
> >  You're comparing arm performance with QDSP6 by writing pessimal  
> QDSP6
> >  code that does single-byte moves and keeps half the execution units
> >  idle. You're going to get some extremely useful numbers out of  
> that,
> >  aren't you? (Even their uClibc port had an assembly optimized
> >  memmove().)
> Well, is it simular to usual C/C++ code task and results of  
> compilation?

Not for strcpy(), strcat(), memcpy(), memmove(), structure assignment...

> Until you will do a manual assembler optimization.

No, until your libc does the manual assembler optimization of common  
operations _for_ you (which is half the reason there's target-specific  
code), and you use the right functions.

> >  Is your arm code also doing single byte moves, with the requisite
> >  bit-shifting and masking that doing that on arm entails (since  
> last I
> >  checked arm hasn't actually _got_ instructions that handle bytes,
> >  although maybe it went into thumb2 or v7 or v8 when I wasn't
> >  looking...)?
> ARM has LDRB and STRB instructions long time ago (ever in ARMv4)
> 
> Okay, seems this is really bad test.

That was my point, yes.

I honestly dunno how good the hexagon optimizer in gcc is. (The  
qualcomm guys did extensive hand-hacked assembly, platform hasn't been  
all that widely used outside of there.) We've gone a touch beyond  
"duff's device" these days...

> >  Specifically, the v2 hardware (in the snapdragon chipset in the  
> Nexus
> >  One) has 6 register profiles (for the 6 pipeline stages, acting as
> >  6-way SMP) but performance peaked at "make -j 3" which ran very
> >  slightly faster than "make -j 4", and then -j 5 and -j 6 were each
> >  noticeably slower (due to TLB thrashing).
> Intersting to know that.
> I want to get SSH access to got console and interaction with system.

I miss having that myself. I built Aboriginal Linux on target and built  
Linux From Scratch and chunks of Beyond Linux From Scratch under it and  
the result was a fairly decent machine. I would love to support it in  
my upstream vanilla projects, but Qualcomm never gave me (or anyone  
else) the tools to do that outside of employee context.

> >  I believe that v3 had already taped out by then (late 2010, but it  
> had
> >  fewer pipeline stages and thus register profiles anyway), and then  
> v4
> >  was going to increase the TLB entries. What actually shipped was  
> after
> >  my time, dunno the details.
> v3 should be rather close to v2, but v4 seems to have few new  
> features.
> At the current moment all v2 source code works on v3.

They're backwards but not forwards compatible. v2 works on v3 and v4,  
but v4 may not work on v2. (Most architectures work that way.)

Over in the arm world, moving from armv4l to armv5l gives you about a  
25% performance boost (which means 25% more battery life if it races it  
idle faster), and Arm EABI standard requires thumb instructions  
(armv4tl). But otherwise, you can run the old code just fine.

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-hexagon" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html