eon performance regression

[Andreas Jaeger]

Paolo Carlini <pcarlini@unitus.it> writes:

> Andreas Jaeger wrote:
>
>> > I have a couple of naive questions:
>> > 1- Which compile flags are used for peak and base?
>>
>> Base flags: -O2 -march=athlon -malign-double
>>   Peak flags: -O3 -fomit-frame-pointer -march=athlon
>>   (cont.)     -funroll-all-loops -fstrict-aliasing
>>   (cont.)     -malign-double
>>   To compile and execute eon correctly the following extra flags
>>   are used for compilation: -ffast-math -fwritable-strings.
>>
>> for more details, check e.g.:
>> http://www.suse.de/~aj/SPEC/CINT/sandbox-b/200112291813.int/CINT2000.354.html
>
> Thank you very much.
> Sorry for having asked those information when they are in fact readily available on
> that WEB page.

No problem - there's lot of information on the pages and it might be
difficult to locate the bits somebody needs.

>> > 2- Does eon use std::string? Is it I/O bound (on the concerned architecture)?
>>
>> I don't think so, a grep for "std::string" revealed no matches.  eon
>> is old and can even be compiled with gcc 2.95.x
>>
>> eon is not I/O bound.  All SPECcpu tests should be memory and CPU
>> bound only.
>
> As I expected...
>
>> > (I'm asking this because among the libstdc++ patches one affects only the former,
>> > the other only the latter functionality)
>>
>> Strange.
>
> ... really!
>
> Andreas, honestly, I think there is very feeble evidence that those libstdc++ patches
> are really responsible for the slow down Jan's noticed from that date. What do you
> think?
>
> More generally, do you think is likely that a *very* high level libstdc++ change
> manifest itself as a performance regression only on the peak and not in the base
> benchmark?

I'm not sure.  But if Honza or anybody else sends me a patch (against
current CVS) I can run tests with and without that patch and check
whether this is really the problem.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj