search for: omnetpp

...jeng|633.69|641.21|641.81|655.94 | +--------------+---------+---------+---------+-------+ |462.libquantum|362.82|367.00|367.38|382.14 | +--------------+---------+---------+---------+-------+ |464.h264ref|701.37|682.13|683.41|699.93 | +--------------+---------+---------+---------+-------+ |471.omnetpp|397.04|407.38|407.33|411.36 | +--------------+---------+---------+---------+-------+ |473.astar|611.51|610.46|610.19|624.78 | +--------------+---------+---------+---------+-------+ |483.xalancbmk |291.66|295.61|296.42|298.29 | +--------------+---------+---------+---------+-------+ |SUM |6058....

...6.hmmer 0.17% 1.72% 28.38% 1.72% SPEC/CINT2006/458.sjeng/458.sjeng 0.19% 1.35% 8.97% 6.05% SPEC/CINT2006/462.libquantum/462.libquantum 1.08% -20.22% 146.24% -7.26% SPEC/CINT2006/464.h264ref/464.h264ref 0.00% -0.30% 9.22% 0.72% SPEC/CINT2006/471.omnetpp/471.omnetpp 2.78% 1.92% 67.24% 3.92% SPEC/CINT2006/473.astar/473.astar 4.59% 6.61% 12.90% -0.87% SPEC/CINT2006/483.xalancbmk/483.xalancbmk 4.29% 0.00% 34.72% 0.00% SPEC/CINT95/099.go/099.go 0.00% -3.13% 46.93% 0.00% SPEC/CINT95/124.m...

...but will surely fail when you try to use for something more real. Currently it at least lacks information about frame moves. So, every invoke, which needs to restore call-clobbered registers during unwinding will be broken. Does Shootout-C++/except work for you? And stuff from llvm testsuite like omnetpp and xalan ? Also, Darwin is different than Linux, because Darwin's unwinding runtime is native one, not built by llvm-gcc. -- WBR, Anton Korobeynikov

...ec/2006/fp/C++/450.soplex 42.92 -0.44% spec/2006/fp/C++/453.povray 38.57 -2.25% spec/2006/fp/C/433.milc 24.54 -0.76% spec/2006/fp/C/470.lbm 41.08 +0.26% spec/2006/fp/C/482.sphinx3 47.58 -0.99% spec/2006/int/C++/471.omnetpp 22.06 +1.87% spec/2006/int/C++/473.astar 22.65 -0.12% spec/2006/int/C++/483.xalancbmk 33.69 +4.97% spec/2006/int/C/400.perlbench 33.43 +1.70% spec/2006/int/C/401.bzip2 23.02 -0.19% spec/2006/int/C/403.gcc 32.57...

...| 0 146301 | 462.libquantum | 5 428082 | 458.sjeng | 9773 808471 | 433.milc | 2163 1787190 | 450.soplex | 72 2472234 | 401.bzip2 | 229 2574217 | 456.hmmer | 1833 3492577 | 445.gobmk | 8480 3685838 | 444.namd | 616 12943554 | 471.omnetpp | 422 20068605 | 464.h264ref | 8593 23849576 | 400.perlbench | 99316 37779455 | 447.dealII | 11204 186008992 | 403.gcc | 404828 I am finding these results weird because I was expecting a larger number of no-alias responses. For instance, I got only 404,828 r...

The large percentages are from those tiny benchmarks. If you look at omnetpp (0.52%), and xalanc (1.46%), the increase is small. To get a better average increase, you can sum up total debug_line size before and after and compute percentage accordingly. David On Thu, Oct 27, 2016 at 1:11 PM, Dehao Chen <dehao at google.com> wrote: > The impact to debug_line is ac...

...f speccpu C/C++ benchmarks: 433.milc 23.59% 444.namd 6.25% 447.dealII 8.43% 450.soplex 2.41% 453.povray 5.40% 470.lbm 0.00% 482.sphinx3 7.10% 400.perlbench 2.77% 401.bzip2 9.62% 403.gcc 2.67% 429.mcf 9.54% 445.gobmk 7.40% 456.hmmer 9.79% 458.sjeng 9.98% 462.libquantum 10.90% 464.h264ref 30.21% 471.omnetpp 0.52% 473.astar 5.67% 483.xalancbmk 1.46% mean 7.86% Dehao On Thu, Oct 27, 2016 at 11:55 AM, Xinliang David Li <davidxl at google.com> wrote: > Do you have an estimate of the debug_line size increase? I guess it will > be small. > > David > > On Thu, Oct 27, 2016 at 11:39...

...The change does not hurt any benchmark with noticeable regression and sometimes results in small improvement (1%-3%). 473.astar -7 401.bzip2 -110 403.gcc -13,006 445.gobmk -1,716 464.h264ref -684 456.hmmer -391 462.libquantum -4 429.mcf -4 471.omnetpp -1,980 400.perlbench -4,176 458.sjeng -338 450.soplex -395 483.xalancbmk -4,183 447.dealII -186 433.milc -34 444.namd -104 453.povray -1,785 482.sphinx3 -112 I propose to factor out the relevant code from BranchFolding into a utility, and c...

...xed. I suspect this architecture is more sensitive to code layout issues than to register allocation: Targeting x86-64: -6.4% 464.h264ref -6.1% 256.bzip2 -5.2% 183.equake -4.8% 447.dealII -3.9% 400.perlbench -3.5% 401.bzip2 -3.3% 255.vortex +3.8% 186.crafty +5.0% 462.libquantum +8.0% 471.omnetpp Finally, armv7/thumb2 running on a Cortex-A9 CPU does quite well: Targeting armv7: -6.2% 447.dealII -4.4% 183.equake -4.1% 462.libquantum -3.5% 401.bzip2 Clang builds llvm+clang about 0.5% faster when it was built with the greedy register allocator. More data below. Compile Time Linear s...

...use for something more real. Currently > it at > least lacks information about frame moves. So, every invoke, which > needs > to restore call-clobbered registers during unwinding will be broken. > > Does Shootout-C++/except work for you? And stuff from llvm testsuite > like omnetpp and xalan ? Everything in the llvm testsuite works. > Also, Darwin is different than Linux, because Darwin's unwinding > runtime > is native one, not built by llvm-gcc. I didn't look too hard, but it looks like the x86-64 info is only slightly modified from the x86-32 info o...

Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated code is fine, just the exception handler i...

...he entire test-suite, when disabling the pass, > > I measured: > > without LTO, a -0.19% geomean improvement with LTO, a +0.11% geomean > > regression. > > > > As for just SPEC2006, there are two big regressions: 400.perlbench > > (10.6% w/ LTO, 2.7% w/o) and 471.omnetpp (2.3% w/, 3.9% w/o). > > > > Numbers are attached. > > > > > > -- A way forward > > One obvious way to improve it is: look at uses of globals, and try to > > form sets of globals commonly used together. The tricky part is to > > define heuristics for...

...SPEC Score SPEC Score % Score Difference 400.perlbench 21.2 20.2 4.95% 401.bzip2 13.9 13.6 2.21% 403.gcc 19.5 19.8 -1.52% 429.mcf 20.5 20.5 0.00% 445.gobmk 18.6 18.6 0.00% 456.hmmer 11.1 11.1 0.00% 458.sjeng 19.3 19.3 0.00% 462.libquantum 39.5 39.5 0.00% 464.h264ref 28.5 28.5 0.00% 471.omnetpp 15.6 15.6 0.00% 473.astar 13 13 0.00% 483.xalancbmk 21.9 21.9 0.00% GEOMEAN 19.0929865 19.00588287     0.46% 410.bwaves  15.2 15.2 0.00% 416.gamess CE CE #VALUE! 433.milc  19 18.6 2.15% 434.zeusmp    14.2 14.2 0.00% 435.gromacs       11.6 11.3 2.65% 436.cactusADM 8.31 7.89 5.32% 437.lesli...

...the execution time? Did you observe any regressions where MSSA resulted in fewer removed stores? I did not gather numbers for execution time yet, but I’ll try to share some tomorrow. At the current state, for MultiSource/SPEC2000/SPEC2006, there are the following regressions test-suite...6/471.omnetpp/471.omnetpp.test 321.00 316.00 -1.6% test-suite...arks/mafft/pairlocalalign.test 64.00 61.00 -4.7% test-suite...ks/Prolangs-C++/city/city.test 23.00 21.00 -8.7% test-suite...oxyApps-C/miniGMG/miniGMG.test 69.00 60.00 -13.0% I suspect those a...

...2 20.2 4.95% > 401.bzip2 13.9 13.6 2.21% > 403.gcc 19.5 19.8 -1.52% > 429.mcf 20.5 20.5 0.00% > 445.gobmk 18.6 18.6 0.00% > 456.hmmer 11.1 11.1 0.00% > 458.sjeng 19.3 19.3 0.00% > 462.libquantum 39.5 39.5 0.00% > 464.h264ref 28.5 28.5 0.00% > 471.omnetpp 15.6 15.6 0.00% > 473.astar 13 13 0.00% > 483.xalancbmk 21.9 21.9 0.00% > GEOMEAN 19.0929865 19.00588287 0.46% > 410.bwaves 15.2 15.2 0.00% > 416.gamess CE CE #VALUE! > 433.milc 19 18.6 2.15% > 434.zeusmp 14.2 14.2 0.00% > 435.gromacs 11.6 11.3 2.6...

...abling the pass, > > > I measured: > > > without LTO, a -0.19% geomean improvement with LTO, a +0.11% geomean > > > regression. > > > > > > As for just SPEC2006, there are two big regressions: 400.perlbench > > > (10.6% w/ LTO, 2.7% w/o) and 471.omnetpp (2.3% w/, 3.9% w/o). > > > > > > Numbers are attached. > > > > > > > > > -- A way forward > > > One obvious way to improve it is: look at uses of globals, and try to > > > form sets of globals commonly used together. The tricky part is...

On Tue, Jan 29, 2013 at 3:59 PM, Murali, Sriram <sriram.murali at intel.com> wrote: > Our benchmark results show that the compilation time performance improved by > ~0.5%. That's fairly small; what was the standard deviation, confidence interval, etc? -- Sean Silva

...ize 401.bzip2 100.00 101.14 403.gcc 100.00 100.33 429.mcf 100.00 100.37 433.milc 100.00 99.85 444.namd 100.00 100.28 445.gobmk 100.00 100.11 450.soplex 100.00 100.46 456.hmmer 100.00 100.29 458.sjeng 100.00 100.70 464.h264ref 100.00 102.10 470.lbm 100.00 100.07 471.omnetpp 100.00 100.36 bitmnp01 100.00 100.44 cjpegv2data6 100.00 100.76 idctrn01 100.00 99.83 libquake2 100.00 100.08 libquake_portable 100.00 100.02 libxcsoar 100.00 100.08 linpack 100.00 101.07 matrix01 100.00 100.28 nbench 100.00 100.76 tblook01 100.00 101.52 ttsprk01 1...

Hello, I'm trying to get the LD_LIBRARY_PATH set from .bash_profile (Centos 5.3 fully updated). This is a part of my .bash_profile: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/szyman/omnet/omnetpp-2.3p1/lib export R_HISTSIZE=2000000000 Everything works fine under standard ssh login, but under NX client the LD_LIBRARY_PATH variable is missing (the R_HISTSIZE is exported properly). Any hints? Thanks, Andrzej

On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >> After comparing the generated assembler code with native gcc code I >> think the generated code is fine, just the exception handler info in >> the non-code sections is broken/missing. > It seems, that EH dwarf information emission is disabled in > X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >