[ELDK] e500mc target architecture

Valentin Longchamp valentin.longchamp at keymile.com
Tue Dec 18 11:21:31 CET 2012


Dear Wolfgang,

On 12/17/2012 05:26 PM, Wolfgang Denk wrote:
> 
> In message <50CF3BD2.2060003 at keymile.com> you wrote:
>>
>>> Could you please be a bit more specific which "advantage of the
>>> e500mc cores" you have in mind that would not be supportedby the
>>> generic-powerpc target of configuration of the ELDK?
>>
>> I was mostly thinking about all the mechanisms introduced by the PowerISA 2.06
>> Instruction set. I was thinking that even if the e500mc core is compatible with
>> the PowerISA 2.03, it would be better to produce code with PowerISA 2.06.
> 
> Which of these extensions seem relevant to your applications?  I mean,
> even if Power ISA v.2.06 contains new vector-scalar FP instructions, I
> don't think that GCC will automatically generate these, nor can I
> assess that your code would actually benefit from it.
> 
> Most of the extensions are actually about virtualisation and
> hypervisor zupport.
> 
> Do you have any specific test cases and/or benchmarks that demonstrate
> this, and that are relevant to your application code?

We do not plan to use virtualisation. Hypervisor may be needed for some very
specific tasks, but we do not plan to use it in the current design. I was more
interested in the sync and messaging instructions, but I think it is the same as
with the new vector-scalar FP instructions, it's not very probable that GCC will
generate them.

> 
>> I have mostly ARM experience and there every new core brings a new ISA that
>> requires a new target architecture to really take advantage of it. Maybe this
>> influenced a lot my expectations with this e500mc core and how to take advantage
>> of it.
> 
> From what I've seen, a large amount of such talk is marketing babble.
> Yes, you can come up with synthetic benchmarks that will show improved
> performance - but how much does it mean in real life?  Many of the
> performance related GCC patches deal with micro-optimizations, where
> it is difficult for me to balance the performance benefit for a few
> exotic corner-cases of code against the risk of introducing new bugs
> by little tested code.  And how much can benchmarks be trusted?  Even
> reputable organizations are known to come up with numbers that are
> primarily driven by marketing aspects, see for example [1].
> 
> Unless proven otherwise I doubt that a specific e500mc configuration
> of the ELDK would have measurable performance advantages in most
> application environments.
> 

I don't know how GCC is really able to take advantage of new core designs and
functionality but I agree with you about the difference between synthetic
benchmarks and real-life performance. Therefore I also think that a e500mc
configuration would not give us a substantial performance advantage and we will
stay with the generic powerpc compiler.

There is still one point I would like to discuss: what is your experience with
the -mtune and -mcpu compiler options ? Do you think it makes sense to add them
to our compiler flags ?

It is so easy to do that even if the gain is not really substantial it is worth
it. Our software (the final application, not the whole environment and rootfs
that are generic) gets only built for a very well defined target hardware with a
definite CPU.

The main problem I could see with this approach is if there are some
incompatibilities between some libraries that were built without the flags and
the application that was built with. Have you already experienced such problems
? The -mtune option at least should here be no problem since it does not change
the architecture type nor register usage according to the GCC documentation [1].

[1] http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html

Best Regards

Valentin


More information about the eldk mailing list