This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: AVX generic mode tuning discussion.


> >> We would like to propose changing AVX generic mode tuning to
> generate 128-bit
> >> AVX instead of 256-bit AVX.
> >
> > You indicate a 3% reduction on bulldozer with avx256.
> > How does avx128 compare to -mno-avx -msse4.2?
> > Will the next AMD generation have a useable avx256?
> >
> > I'm not keen on the idea of generic mode being tune
> > for a single processor revision that maybe shouldn't
> > actually be using avx at all.
> 
> Btw, it looks like the data is massively skewed by
> 436.cactusADM.  What are the overall numbers if you
> disregard cactus?  

Disregarding cactus, these are the cumulative SpecFP scores we see.

On Bulldozer:
			AVX256/AVX128
SPECFP		-1.8%

On SandyBridge:
			AVX256/AVX128
SPECFP		-0.15%

> It's also for sure the case that the vectorizer
> cost model has not been touched for avx256 vs. avx128 vs. sse,
> so a more sensible approach would be to look at differentiating
> things there to improve the cactus numbers.  

I am not sure how much the vectorizer cost model can help here.
The cost model can decide whether to vectorize and/or what vectorization factor to use.
But in generic mode, that decision has to be processor family neutral anyway.

> Harsha, did you
> investigate why avx256 is such a loss for cactus or why it is
> so much of a win for SB?

We are planning to investigate cactus and other cases to understand the reasons behind these observations better on Bulldozer, but disregarding cactus, there appear to be no significant gains on Sandybridge with AVX256 over AVX128 as well.

Thanks,
Harsha



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]