search for: bwave

On Jul 22, 2010, at 4:18 PMPDT, Reza Yazdani wrote: > Hi, > > I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 > out 17 of floating point benchmarks passed. Is this normal or I > made a mistake in my build? Hi Reza. Somebody on Linux should answer, but I don't think it's normal. You may have checked out the source at a moment when it had a bug

Hi, I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 out 17 of floating point benchmarks passed. Is this normal or I made a mistake in my build? Reza -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100722/4c4a81a9/attachment.html>

...Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio -------------- ------ --------- --------- ------ --------- --------- 410.bwaves -- 0.0194 RE 416.gamess -- 0.00135 RE 433.milc -- 16.5 -- S 434.zeusmp -- 0.00146 RE 435.gromacs...

...2% 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.leslie3d 11 11 0.00% 444.namd   16 16 0.00% 447.dealII 25.4 25.4 0.00% 450.soplex 26.1 26.1 0.00% 453.povray 20.5 20.5 0.00%...

Hi Petr- 1. We compile SPEC benchmarks bwaves and xchange currently. We are close to compiling fotonik at this point. 2. We released the source as experimental for the community to take a look. Soon we will open source the entire history of development(we are working on the script to upload the history). thanks, -Prashanth On Mon, Feb 10, 2...

...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.leslie3d 11 11 0.00% > 444.namd 16 16 0.00% > 447.dealII 25.4 25.4 0.00% > 450.sople...

...ctation that LLVM's performance in the native x86-64 mode is better, because more spill code is generated when the -m32 option is used. However, these aggregate numbers hide the fact that LLVM generates much faster code for some benchmarks when the -m32 option is used. An extreme example is the bwaves benchmark, which has a score of 15.5 in the native mode and a score of 23 (a 48% speedup) when the -m32 option is used. If LLVM is capable of achieving the higher score in the -m32 mode, it should be able to achieve at least the same score in the native mode. So, the question is: are there any goo...

...9;s performance in the native x86-64 mode is better, because more > spill code is generated when the -m32 option is used. However, these > aggregate numbers hide the fact that LLVM generates much faster code for > some benchmarks when the -m32 option is used. An extreme example is the > bwaves benchmark, which has a score of 15.5 in the native mode and a score > of 23 (a 48% speedup) when the -m32 option is used. If LLVM is capable of > achieving the higher score in the -m32 mode, it should be able to achieve > at least the same score in the native mode. So, the question is: ar...

...mk 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.leslie3d 11 11 0.00% > 444.namd 16 16 0.00% > 447.dealII 25.4 25.4 0.00% > 450.soplex 26.1 26...

...> Estimated > Base Base Base Peak Peak > Peak > Benchmarks Ref. Run Time Ratio Ref. Run Time > Ratio > -------------- ------ --------- --------- ------ --------- > --------- > 410.bwaves -- > 0.0194 RE > 416.gamess -- > 0.00135 RE > 433.milc -- > 16.5 -- S > 434.zeusmp...

...; li_- Yep. > >getVNInfoAllocator()); > > Can you take a look at MergeInClobberRanges() to see what is going on? > Otherwise, please file a bug with a test case. Yes. I think I know what's going on. This happens in SPEC 2006 bwaves on the block_solver.f source file. This is of course using our frontend and optimizer, so it may not be reproducable for anyone else. I'll see if I can generate a .ll testcase. The llvm tools probably won't fail because they don't contain the assert that I have in my code. Here...

...Perf Size CFP2006 x32 32 64 x32/32 x32/64 x32 32 64 x32/32 x32/64 =============================================================================================== 410.bwaves 23.10 33.31 23.76 -30.66% -2.79% 36724 36677 40465 0.13% -9.25% 416.gamess 27.75 23.15 24.85 19.87% 11.67% 9234580 9311389 9498620 -0.82% -2.78% 433.milc 23.38 21.11 23.76 10.72% -1.63% 143476 148267 155756 -3.23% -7.88% 434.zeusmp 19.58...

...ode="strict" nodeset="6"/> > <memnode cellid="7" mode="strict" nodeset="7"/> > </numatune> > > hopefully, I got it right. Yes, looking good. > > Good news is, that spec benchmark looks promising. The first test bwaves > finished in 1003 seconds compared to 1700 seconds in the previous wrong case. > So far so good. Very well, this means that the config above is correct. > > Bad news is, that iozone is still the same. There might be some > misunderstanding. > > I have to cases: > &gt...

On Feb 20, 2008, at 7:36 PM, David A. Greene wrote: > On Wednesday 20 February 2008 07:00:28 pm Evan Cheng wrote: > >>> In other words, after coalescing, should it be the case that >>> subregister >>> intervals contain at least all of the range information that was >>> contained >>> in any eliminated intervals when those eliminated intervals were

On 09/14/2018 03:36 PM, Lukas Hejtmanek wrote: > Hello, > > ok, I found that cpu pinning was wrong, so I corrected it to be 1:1. The issue > with iozone remains the same. > > The spec is running, however, it runs slower than 1-NUMA case. > > The corrected XML looks like follows: [Reformated XML for better reading] <cpu mode="host-passthrough">

...Perf Size CFP2006 x32 32 64 x32/32 x32/64 x32 32 64 x32/32 x32/64 =============================================================================================== 410.bwaves 23.10 33.31 23.76 -30.66% -2.79% 36724 36677 40465 0.13% -9.25% 416.gamess 27.75 23.15 24.85 19.87% 11.67% 9234580 9311389 9498620 -0.82% -2.78% 433.milc 23.38 21.11 23.76 10.72% -1.63% 143476 148267 155756 -3.23% -7.88% 434.zeusmp 19.58...

Which options are you seeing that cause the largest difference, and on which targets? As Chandler mentioned there has been a large amount of variation in x86 targets, and there are certain optimizations that can be done, on say a Pentium (scheduling instructions which are pairable and non-dependent so the U and V pipelines are saturated without contention, for example) that don't make sense

...quot;5"/> <memnode cellid="6" mode="strict" nodeset="6"/> <memnode cellid="7" mode="strict" nodeset="7"/> </numatune> hopefully, I got it right. Good news is, that spec benchmark looks promising. The first test bwaves finished in 1003 seconds compared to 1700 seconds in the previous wrong case. So far so good. Bad news is, that iozone is still the same. There might be some misunderstanding. I have to cases: 1) cache=unsafe. In this case, I can see that hypervizor is prone to swap. Swap a lot. It usually eat...

I have been doing some benchmarking on x86 using llvm 2.9 with the llvm-gcc 4.2 front end. I noticed that the -march and -mtune options make a significant positive difference in x86-32 mode but hardly make any difference in x86-64 mode. The small difference that I am measuring when the target is x86-64 could easily be random variation, while for the x86-32 target I am measuring a huge difference

Neat, another fortran compiler option. Does anyone have a list/comparison of all the LLVM fortran compilers? I'm not really tracking this, since Fortran isn't really my area of expertise, but I've seen the following. Perhaps there are even more? "Flang". The original of the name, I think? Abandoned. https://github.com/llvm-flang/flang "Fort" -- fork of the above