Re: Why vectorization didn't turn on by -O2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,
here are updated scores.  
https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14&older_in_days=0&all_elf_detail_stats=on&min_percentage_change=0.001&revisions=9388fc7bf0da61a8104e8501e5965120e9159e12%2Cea21f32198432a490dd490696322838d94b3d3b2%2C4f5431c5768bbba81a422f6fed6a6e2454c700ee%2C&include_user_branches=on
compares
  base:  mainline
  1st column: mainline with very cheap vectorization at -O2 and -O3
  2nd column: mainline with cheap vectorization at -O2 and -O3.

The short story is:

1) -O2 generic performance
    kabylake (Intel):
    				very    cheap
        SPEC/SPEC2006/FP/total 	~ 	8.32% 	
	SPEC/SPEC2006/total 	-0.38% 	4.74% 	
	SPEC/SPEC2006/INT/total	-0.91% 	-0.14% 	

   	SPEC/SPEC2017/INT/total	4.71% 	7.11% 	
	SPEC/SPEC2017/total 	2.22% 	6.52% 	
	SPEC/SPEC2017/FP/total 	0.34% 	6.06% 	
    zen
        SPEC/SPEC2006/FP/total 	0.61% 	10.23% 	
	SPEC/SPEC2006/total 	0.26% 	6.27% 	
	SPEC/SPEC2006/INT/total	34.006 	-0.24% 	0.90% 	

        SPEC/SPEC2017/INT/total	3.937 	5.34% 	7.80% 	
	SPEC/SPEC2017/total 	3.02% 	6.55% 	
	SPEC/SPEC2017/FP/total 	1.26% 	5.60% 	

 2) -O2 size:
     -0.78% (very cheap) 6.51% (cheap) for spec2k2006 
     -0.32% (very cheap) 6.75% (cheap) for spec2k2017 
 3) build times:
     0%, 0.16%, 0.71%, 0.93% (very cheap) 6.05% 4.80% 6.75% 7.15% (cheap) for spec2k2006
     0.39% 0.57% 0.71%       (very cheap) 5.40% 6.23% 8.44%       (cheap) for spec2k2017
    here I simply copied data from different configuratoins

So for SPEC i would say that most of compile time costs are derrived
from code size growth which is a problem with cheap model but not with
very cheap.  Very cheap indeed results in code size improvements and
compile time impact is probably somewhere around 0.5%

So from these scores alone this would seem that vectorization makes
sense at -O2 with very cheap model to me (I am sure we have other
optimizations with worse benefits to compile time tradeoffs).

However there are usual arguments against:

  1) Vectorizer being tuned for SPEC.  I think the only way to overcome
     that argument is to enable it by default :)
  2) Workloads improved are more of -Ofast type workloads

Here are non-spec benchmarks we track:
https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14&older_in_days=0&min_percentage_change=0.02&revisions=9388fc7bf0da61a8104e8501e5965120e9159e12%2Cea21f32198432a490dd490696322838d94b3d3b2%2C4f5431c5768bbba81a422f6fed6a6e2454c700ee%2C&include_user_branches=on

I also tried to run Firefox some time ago. Results are not surprising -
vectorizaiton helps rendering benchmarks which are those compiler with
aggressive flags anyway.

Honza



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux