search for: huffbench

Hi all, It seems that Polly could still speed up test-suite/SingleSource/Benchmarks/CoyoteBench/huffbench.c even without any optimization and code generation. Our evaluation show that when compiled with "clang -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none", the execution time of huffbench would reduced to 15 secs from the origi...

On 08/05/2013 08:08 PM, Star Tan wrote: > Hi all, > > > It seems that Polly could still speed up test-suite/SingleSource/Benchmarks/CoyoteBench/huffbench.c even without any optimization and code generation. Our evaluation show that when compiled with "clang -Xclang -load -Xclang LLVMPolly.so -mllvm -polly -mllvm -polly-optimizer=none -mllvm -polly-code-generator=none", the execution time of huffbench would reduced to 15 secs from the origi...

...>>> http://188.40.87.11:8000/db_default/v4/nts/21?compare_to=16&baseline=16&aggregation_fn=median, >>> we can see detecting scops bottom-up may further reduce Polly >>> compile-time by more than 10%. >> >>Interesting. For some reason it also regresses huffbench quite a bit. > > This is because the ScopBottomUp patch file invalids the scop detection for huffbench. The run-time of huffbench with different options are shown as follows: > > clang: 19.1680s (see runid=14) > > polly without ScopBottomUp patch file: 14.8340s (see runid=16) &gt...

...ts >> shown on >> http://188.40.87.11:8000/db_default/v4/nts/21?compare_to=16&baseline=16&aggregation_fn=median, >> we can see detecting scops bottom-up may further reduce Polly >> compile-time by more than 10%. > >Interesting. For some reason it also regresses huffbench quite a bit. This is because the ScopBottomUp patch file invalids the scop detection for huffbench. The run-time of huffbench with different options are shown as follows: clang: 19.1680s (see runid=14) polly without ScopBottomUp patch file: 14.8340s (see runid=16) polly with ScopBottomUp patch fi...

...tp://188.40.87.11:8000/db_default/v4/nts/21?compare_to=16&baseline=16&aggregation_fn=median, >>>> we can see detecting scops bottom-up may further reduce Polly >>>> compile-time by more than 10%. >>> >>>Interesting. For some reason it also regresses huffbench quite a bit. >> >> This is because the ScopBottomUp patch file invalids the scop detection for huffbench. The run-time of huffbench with different options are shown as follows: >> >> clang: 19.1680s (see runid=14) >> >> polly without ScopBottomUp patch file: 14....

...act. Based on the results > shown on > http://188.40.87.11:8000/db_default/v4/nts/21?compare_to=16&baseline=16&aggregation_fn=median, > we can see detecting scops bottom-up may further reduce Polly > compile-time by more than 10%. Interesting. For some reason it also regresses huffbench quite a bit. :-( I think here an up-to-date non-polly to polly comparision would come handy to see which benchmarks we still see larger performance regressions. And if the bottom-up scop detection actually helps here. As this is a larger patch, we should really have a need for it before switchi...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > +10.0% SingleSource/Benchmarks/CoyoteBench/huffbench > +12.0% SingleSource/Benchmarks/McGill/chomp > +18.0% SingleSource/Benchmarks/BenchmarkGame/n-body > +45.5% SingleSource/Benchmarks/BenchmarkGame/puzzle > +10.0% SingleSource/Benchmarks/Shootout/heapsort > +10.5% MultiSource/Benchmarks/Trimaran/enc-3des/enc-3des...

Hi Tobias and all Polly developers, I have re-evaluated the Polly compile-time performance using newest LLVM/Polly source code. You can view the results on http://188.40.87.11:8000. Especially, I also evaluated our r187102 patch file that avoids expensive failure string operations in normal execution. Specifically, I evaluated two cases for it: Polly-NoCodeGen: clang -O3 -load

...ch64 results on ARM Cortex-A72: Performance Regressions - execution_time Change SingleSource/Benchmarks/Shootout/Shootout-ary3 9.48% MultiSource/Benchmarks/TSVC/Packing-flt/Packing-flt 3.79% SingleSource/Benchmarks/CoyoteBench/huffbench 1.40% Performance Improvements - execution_time Change MultiSource/Benchmarks/TSVC/Searching-dbl/Searching-dbl -23.74% External/SPEC/CINT2000/256.bzip2/256.bzip2 -9.82% MultiSource/Benchmarks/TSVC/Searchin...

...and to > dispell some common misconceptions about optimization. > > The settings for -O1, -O2, and -O3 are valid. Every option implied by > -O3 may not be applicable to every program -- but enabling all those > options does not seem to be detrimental, except in the case of > huffbench. Several of the recently-added flags (-ftracer in particular) > may be candidates for inclusion in -O2 or -O3 for future versions of the > compiler. > > Processor-specific options do not appear to be a major factor in > performance on these benchmarks. I don't know if this is...

...spell some common misconceptions about optimization. >> >> The settings for -O1, -O2, and -O3 are valid. Every option implied by >> -O3 may not be applicable to every program -- but enabling all those >> options does not seem to be detrimental, except in the case of >> huffbench. Several of the recently-added flags (-ftracer in >> particular) >> may be candidates for inclusion in -O2 or -O3 for future versions of >> the >> compiler. >> >> Processor-specific options do not appear to be a major factor in >> performance on these ben...

...ource/Benchmarks/BenchmarkGame/nsieve-bits +4.8% MultiSource/Applications/hexxagon/hexxagon +5.0% External/SPEC/CINT2006/462.libquantum/462.libquantum +6.7% MultiSource/Benchmarks/Ptrdist/yacr2/yacr2 +8.0% External/SPEC/CINT2006/471.omnetpp/471.omnetpp +10.0% SingleSource/Benchmarks/CoyoteBench/huffbench +12.0% SingleSource/Benchmarks/McGill/chomp +18.0% SingleSource/Benchmarks/BenchmarkGame/n-body +45.5% SingleSource/Benchmarks/BenchmarkGame/puzzle Targeting armv7 -O2, Cortex-A9: -38.1% MultiSource/Benchmarks/MiBench/security-sha/security-sha -29.1% MultiSource/Benchmarks/MiBench/telecomm-CRC32/t...

...M Cortex-A72: > > Performance Regressions - execution_time           Change > SingleSource/Benchmarks/Shootout/Shootout-ary3                9.48% > MultiSource/Benchmarks/TSVC/Packing-flt/Packing-flt               >   3.79% > SingleSource/Benchmarks/CoyoteBench/huffbench                 1.40% > > Performance Improvements - execution_time          Change > MultiSource/Benchmarks/TSVC/Searching-dbl/Searching-dbl           >   -23.74% > External/SPEC/CINT2000/256.bzip2/256.bzip2               -9.82% > MultiSource/Benchmarks/TSVC/S...

On May 3, 2011, at 9:19 AM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> +10.0% SingleSource/Benchmarks/CoyoteBench/huffbench >> +12.0% SingleSource/Benchmarks/McGill/chomp >> +18.0% SingleSource/Benchmarks/BenchmarkGame/n-body >> +45.5% SingleSource/Benchmarks/BenchmarkGame/puzzle >> +10.0% SingleSource/Benchmarks/Shootout/heapsort >> +10.5% MultiSource/Benchmarks/Trimaran/enc...

...mance Regressions - execution_time Change >>> SingleSource/Benchmarks/Shootout/Shootout-ary3 9.48% >>> MultiSource/Benchmarks/TSVC/Packing-flt/Packing-flt 3.79% >>> SingleSource/Benchmarks/CoyoteBench/huffbench 1.40% >>> >>> Performance Improvements - execution_time Change >>> MultiSource/Benchmarks/TSVC/Searching-dbl/Searching-dbl -23.74% >>> External/SPEC/CINT2000/256.bzip2/256.bzip2...

...eptions about optimization. > >> > >> The settings for -O1, -O2, and -O3 are valid. Every option implied by > >> -O3 may not be applicable to every program -- but enabling all those > >> options does not seem to be detrimental, except in the case of > >> huffbench. Several of the recently-added flags (-ftracer in > >> particular) > >> may be candidates for inclusion in -O2 or -O3 for future versions of > >> the > >> compiler. > >> > >> Processor-specific options do not appear to be a major factor in &gt...

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

tl;dr in low data situations we don’t look at past information, and that increases the false positive regression rate. We should look at the possibly incorrect recent past runs to fix that. Motivation: LNT’s current regression detection system has false positive rate that is too high to make it useful. With test suites as large as the llvm “test-suite” a single report will show hundreds of

...e (1.94% - 111.80s this program) nts.MultiSource/Benchmarks/ASC_Sequoia/IRSmk/IRSmk.exec > 7. 30.11% cumulative (1.85% - 106.56s this program) nts.MultiSource/Benchmarks/ASC_Sequoia/AMGmk/AMGmk.exec > 8. 31.60% cumulative (1.49% - 86.00s this program) nts.SingleSource/Benchmarks/CoyoteBench/huffbench.exec > 9. 32.75% cumulative (1.15% - 66.37s this program) nts.MultiSource/Benchmarks/TSVC/NodeSplitting-dbl/NodeSplitting-dbl.exec > 10. 33.90% cumulative (1.15% - 66.13s this program) nts.MultiSource/Applications/hexxagon/hexxagon.exec > 11. 35.04% cumulative (1.14% - 65.98s this program...

.../Benchmarks/Adobe-C++/stepanov_vector | * | * | SingleSource/Benchmarks/Adobe-C++/simple_types_loop_invariant | * | * | SingleSource/Benchmarks/Adobe-C++/simple_types_constant_folding | * | * | SingleSource/Benchmarks/CoyoteBench/huffbench | * | * | SingleSource/Benchmarks/CoyoteBench/fftbench | * | * | SingleSource/Benchmarks/CoyoteBench/lpbench | * | * | SingleSource/Benchmarks/CoyoteBench/almabench...