* 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
[parent not found: <3C332CCE.55954CCB@unitus.it>]
[parent not found: <u81yh84pem.fsf@gromit.moeb>]
* 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).