* Re: eon performance regression
[not found] ` <3C334E4A.9ABEB359@unitus.it>
@ 2002-01-02 10:29 ` Jason Merrill
0 siblings, 0 replies; 7+ messages in thread
From: Jason Merrill @ 2002-01-02 10:29 UTC (permalink / raw)
To: Andreas Jaeger; +Cc: gcc, libstdc++
It seems possible that my patch is responsible, perhaps because of code
growth due to calling the destructors at each call site rather than at a
single place in the callee, but I still wouldn't expect it. It's really
impossible to do more than speculate wildly without access to the code
itself; can you see a significant difference in the generated code? Can
you run it with profiling? Can you try running the benchmark without my
patch? It seems to me that more speculation is not very useful at this
point.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: eon performance regression
[not found] ` <u81yh84pem.fsf@gromit.moeb>
@ 2002-01-11 4:30 ` Jason Merrill
2002-01-11 5:17 ` Jan Hubicka
2002-01-18 9:23 ` Jan Hubicka
0 siblings, 2 replies; 7+ messages in thread
From: Jason Merrill @ 2002-01-11 4:30 UTC (permalink / raw)
To: Andreas Jaeger; +Cc: Jan Hubicka, gcc
Any more word on this? Is the regression still present? Have you tested
to see whether or not it was due to my patch?
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: eon performance regression
2002-01-11 4:30 ` Jason Merrill
@ 2002-01-11 5:17 ` Jan Hubicka
2002-01-11 6:06 ` Jason Merrill
2002-01-18 9:23 ` Jan Hubicka
1 sibling, 1 reply; 7+ messages in thread
From: Jan Hubicka @ 2002-01-11 5:17 UTC (permalink / raw)
To: Jason Merrill; +Cc: Andreas Jaeger, Jan Hubicka, gcc
> Any more word on this? Is the regression still present? Have you tested
> to see whether or not it was due to my patch?
You may take a look at the results pages - the eon is still worse than it
has been previously.
I will ask Andreas to do the testing (I am currently trying to hunt down
regression that happen over cristmas that is much more important and our
testers has been down so it is dificult to hunt down the purpose)
Honza
>
> Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: eon performance regression
2002-01-11 5:17 ` Jan Hubicka
@ 2002-01-11 6:06 ` Jason Merrill
0 siblings, 0 replies; 7+ messages in thread
From: Jason Merrill @ 2002-01-11 6:06 UTC (permalink / raw)
To: Jan Hubicka; +Cc: Andreas Jaeger, gcc, Jason Merrill
>>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:
>> Any more word on this? Is the regression still present? Have you tested
>> to see whether or not it was due to my patch?
> You may take a look at the results pages - the eon is still worse than it
> has been previously.
Ah, OK, looking at http://www.suse.de/~aj/SPEC/CINT/sandbox-b/recent.html I see
that there was about a 50-point drop in the eon score between 2001-12-15
and 2001-12-19. That's much less dramatic; I had thought you were
referring to the 300-point drop on the 29th, which was transient.
I'm still interested in what happens if you revert my patch.
> I will ask Andreas to do the testing
Thanks.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: eon performance regression
2002-01-11 4:30 ` Jason Merrill
2002-01-11 5:17 ` Jan Hubicka
@ 2002-01-18 9:23 ` Jan Hubicka
2002-01-18 10:00 ` Jason Merrill
1 sibling, 1 reply; 7+ messages in thread
From: Jan Hubicka @ 2002-01-18 9:23 UTC (permalink / raw)
To: Jason Merrill; +Cc: Andreas Jaeger, Jan Hubicka, gcc
> Any more word on this? Is the regression still present? Have you tested
> to see whether or not it was due to my patch?
Andreas had benchmarked reverting your calls.c patch and it causes about 10
points regression on eon. Interestingly enought there is also some speedup
in crafty. Can that be caused by your patch?
Base Compiler: GCC CVS
Peak Compiler: GCC CVS with patch for calls.c
cflags base: -O3 -fomit-frame-pointer -march=athlon -funroll-all-loops -fstrict-aliasing -malign-double
cflags peak: -O3 -fomit-frame-pointer -march=athlon -funroll-all-loops -fstrict-aliasing -malign-double
Iterations: 3
Running on: knuth
PDO: No
This run is: SPECint
Please direct questions about this to aj@suse.de
--_----------=_1011320912315810
Content-Disposition: inline; filename="CINT2000.004.asc"
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; name="CINT2000.004.asc"
##############################################################################
# INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN #
# #
# 'reportable' flag not set during run #
# #
# INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN #
##############################################################################
SPEC CINT2000 Summary
Unknown Unknown
Tested by SuSE GmbH
Thu Jan 17 17:22:57 2002
SPEC License #1922 Test date: 2002-01-17 Hardware availability: June 2001
Tester: Andreas Jaeger, SuSE GmbH Software availability: Now
Estimated Estimated
Base Base Base Peak Peak Peak
Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
------------ -------- -------- -------- -------- -------- --------
164.gzip 1400 303 462 1400 299 468
164.gzip 1400 299 469* 1400 298 470*
164.gzip 1400 298 469 1400 298 470
175.vpr 1400 541 259 1400 542 258
175.vpr 1400 543 258 1400 541 259
175.vpr 1400 541 259* 1400 542 258*
176.gcc 1100 340 324* 1100 342 321
176.gcc 1100 340 324 1100 338 325*
176.gcc 1100 337 326 1100 337 326
181.mcf 1800 1000 180 1800 1001 180
181.mcf 1800 1002 180 1800 1004 179*
181.mcf 1800 1001 180* 1800 1023 176
186.crafty 1000 182 550 1000 185 540
186.crafty 1000 182 550* 1000 183 545
186.crafty 1000 182 550 1000 184 544*
197.parser 1800 556 324 1800 559 322
197.parser 1800 556 324* 1800 557 323*
197.parser 1800 556 324 1800 556 324
252.eon 1300 217 600 1300 213 611
252.eon 1300 216 601* 1300 212 612
252.eon 1300 216 601 1300 213 611*
253.perlbmk 1800 360 500 1800 361 499
253.perlbmk 1800 359 501 1800 359 501*
253.perlbmk 1800 360 501* 1800 359 501
254.gap 1100 301 366 1100 300 367
254.gap 1100 300 367* 1100 299 368
254.gap 1100 300 367 1100 299 368*
255.vortex 1900 448 424 1900 447 425
255.vortex 1900 448 424* 1900 447 425*
255.vortex 1900 447 425 1900 447 425
256.bzip2 1500 504 298 1500 505 297
256.bzip2 1500 503 298* 1500 505 297*
256.bzip2 1500 503 298 1500 505 297
300.twolf 3000 1050 286 3000 1049 286
300.twolf 3000 1053 285* 3000 1051 285
300.twolf 3000 1053 285 3000 1049 286*
========================================================================
164.gzip 1400 299 469* 1400 298 470*
175.vpr 1400 541 259* 1400 542 258*
176.gcc 1100 340 324* 1100 338 325*
181.mcf 1800 1001 180* 1800 1004 179*
186.crafty 1000 182 550* 1000 184 544*
197.parser 1800 556 324* 1800 557 323*
252.eon 1300 216 601* 1300 213 611*
253.perlbmk 1800 360 501* 1800 359 501*
254.gap 1100 300 367* 1100 299 368*
255.vortex 1900 448 424* 1900 447 425*
256.bzip2 1500 503 298* 1500 505 297*
300.twolf 3000 1053 285* 3000 1049 286*
Est. SPECint_base2000 362
Est. SPECint2000 362
HARDWARE
--------
Hardware Vendor: Unknown
Model Name: Unknown
CPU: AMD Athlon(tm) Processor
CPU MHz: 1102.543
FPU: Integrated
CPU(s) enabled: 1
CPU(s) orderable: 1
Parallel: No
Primary Cache:
Secondary Cache: 256 KB
L3 Cache: N/A
Other Cache: N/A
Memory: 496 MB
Disk Subsystem: Unknown
Other Hardware: Ethernet
SOFTWARE
--------
Operating System: SuSE Linux 7.3 (i386)
Compiler: GCC CVS
File System: Linux/ReiserFS
System State: Multi-User
NOTES
-----
Base flags: -O3 -fomit-frame-pointer -march=athlon -funroll-all-loops -fstrict-aliasing -malign-double
GCC CVS
Peak flags: -O3 -fomit-frame-pointer -march=athlon -funroll-all-loops -fstrict-aliasing -malign-double
GCC CVS with patch for calls.c
To compile and execute eon correctly the following extra flags
are used for compilation: -ffast-math -fwritable-strings.
##############################################################################
# INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN #
# #
# 'reportable' flag not set during run #
# #
# INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN INVALID RUN #
##############################################################################
-----------------------------------------------------------------------------
For questions about this result, please contact the tester.
For other inquiries, please contact webmaster@spec.org.
Copyright 1999-2000 Standard Performance Evaluation Corporation
Generated on Fri Jan 18 03:28:31 2002 by SPEC CPU2000 ASCII formatter v2.1
--_----------=_1011320912315810--
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: eon performance regression
2002-01-18 9:23 ` Jan Hubicka
@ 2002-01-18 10:00 ` Jason Merrill
2002-01-20 6:04 ` Jan Hubicka
0 siblings, 1 reply; 7+ messages in thread
From: Jason Merrill @ 2002-01-18 10:00 UTC (permalink / raw)
To: Andreas Jaeger; +Cc: gcc
>>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:
>> Any more word on this? Is the regression still present? Have you tested
>> to see whether or not it was due to my patch?
> Andreas had benchmarked reverting your calls.c patch and it causes about 10
> points regression on eon. Interestingly enought there is also some speedup
> in crafty. Can that be caused by your patch?
Not if it's written in C. C never uses TARGET_EXPR.
> Base Compiler: GCC CVS
> Peak Compiler: GCC CVS with patch for calls.c
I assume that "patch for calls.c" means the patch to revert my change.
> Estimated Estimated
> Base Base Base Peak Peak Peak
> Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
> ------------ -------- -------- -------- -------- -------- --------
> 252.eon 1300 217 600 1300 213 611
> 252.eon 1300 216 601* 1300 212 612
> 252.eon 1300 216 601 1300 213 611*
OK, that seems pretty conclusive, thanks. Unfortunately, my patch is
necessary for correctness, so we can't just revert it. I wonder if the
slowdown is simply due to code expansion, or what.
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: eon performance regression
2002-01-18 10:00 ` Jason Merrill
@ 2002-01-20 6:04 ` Jan Hubicka
0 siblings, 0 replies; 7+ messages in thread
From: Jan Hubicka @ 2002-01-20 6:04 UTC (permalink / raw)
To: Jason Merrill; +Cc: Andreas Jaeger, gcc
> >>>>> "Jan" == Jan Hubicka <jh@suse.cz> writes:
>
> >> Any more word on this? Is the regression still present? Have you tested
> >> to see whether or not it was due to my patch?
>
> > Andreas had benchmarked reverting your calls.c patch and it causes about 10
> > points regression on eon. Interestingly enought there is also some speedup
> > in crafty. Can that be caused by your patch?
>
> Not if it's written in C. C never uses TARGET_EXPR.
>
> > Base Compiler: GCC CVS
> > Peak Compiler: GCC CVS with patch for calls.c
>
> I assume that "patch for calls.c" means the patch to revert my change.
>
> > Estimated Estimated
> > Base Base Base Peak Peak Peak
> > Benchmarks Ref Time Run Time Ratio Ref Time Run Time Ratio
> > ------------ -------- -------- -------- -------- -------- --------
> > 252.eon 1300 217 600 1300 213 611
> > 252.eon 1300 216 601* 1300 212 612
> > 252.eon 1300 216 601 1300 213 611*
>
> OK, that seems pretty conclusive, thanks. Unfortunately, my patch is
> necessary for correctness, so we can't just revert it. I wonder if the
> slowdown is simply due to code expansion, or what.
Code expansion looks like good explanation. Eon is extremly big spageti and
almost any code size reducting patch helps the performance here.
OK, now it is time to dig out the slowdown before 21st december.
Honza
>
> Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-01-19 15:54 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20020102135446.C6281@atrey.karlin.mff.cuni.cz>
[not found] ` <3C3316C3.44324286@unitus.it>
[not found] ` <u8k7v04vzy.fsf@gromit.moeb>
[not found] ` <3C332E19.698F07EF@unitus.it>
[not found] ` <u8666k4pi5.fsf@gromit.moeb>
[not found] ` <3C334E4A.9ABEB359@unitus.it>
2002-01-02 10:29 ` eon performance regression Jason Merrill
[not found] ` <3C332CCE.55954CCB@unitus.it>
[not found] ` <u81yh84pem.fsf@gromit.moeb>
2002-01-11 4:30 ` Jason Merrill
2002-01-11 5:17 ` Jan Hubicka
2002-01-11 6:06 ` Jason Merrill
2002-01-18 9:23 ` Jan Hubicka
2002-01-18 10:00 ` Jason Merrill
2002-01-20 6:04 ` Jan Hubicka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).