Dear Wolfgang, On 12/17/2012 05:26 PM, Wolfgang Denk wrote: > > In message <[email protected]> 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 _______________________________________________ eldk mailing list [email protected] http://lists.denx.de/mailman/listinfo/eldk
