When Intel specific target chip libraries & builds were used by design, and it runs at all (let alone better in some cases), I find that surprising, since a static Intel build should run badly if at all on the wrong chip, even within Intel silicon due to micro-architectural optimisation being on the heavy side.  With the instruction sets, I'm more referring that general SSE3 performs across the board pretty well on newer chips from both vendors, where neither with Core2, Athlon nor PhenomI/II was 'plain Intel SSE3' a good choice of code & libraries. 

With juggling, We *should* find, that a static build for each x86 & x64,  each with generically optimised SSE3, SSE2 with static IPP in both flavours &  FFTW, should have a workable combination for most chips except Core2 & AVX.  Obviously AVX availability being OS dependant, that would need to be tacked on with proper detection, so similar with SSSE3 seems viable.

Jason

  I tend to agree there would be some benefit, though would expect only around 10% by just changing bittage, solely because much of the hot code is 128 bit vectorised SIMD already anyway (and will be 256 bit with AVX support additions later). The periphery CPU non-vectorised code (which would become 64 bit) only has a marginal possible impact in this kind of application.

It's working out how to approach that correctly given 64 bit Intel libraries don't contain suitable generically optimised 64 bit libraries, that becomes the technical challenge.  For a 64 bit build, at the moment it looks as though a worthy option to try will be bypassing the issues by using newest FFTW, with automatic AVX support inclusive, ironically built with Intel compiler, & use generic arch:SSE3 optimisations for the core, with a arch:SSE2 path for some earlier chips.  Where I talk about convergence is that it's looking as though i3-i7 might also work well under that arrangement, so only poking around as Raistmer's V7 updates are merged in will really point to the best methods.

All I can say with absolute certainty at this point, is that separate per chip builds for every chip, or even class of chips , would not be a sustainable approach, though it worked well in the past.  Even 'simply' rebuilding the full AKv8b2 set for the bugfix, was far too much work for that amount of subtle difference. That knowledge could & should  be embedded in one app per platform instead, as stock does.

Jason

In micro-architectural optimisation terms it's a bucketload.  For more impact it's quite possible that newer FFTW may fly on that chip compared to Intels x86 SSE3 (Pentium 4!!!!) library that  appears to work best on it now.  We'll just have to make the comparisons easy with switches or similar, then hard wire defaults to suit the findings later.

Jason

Thanks! Interesting they recommend aggressive unrolling & prefetch, which suggests long pipelines. That's opposite to Core2 onward, which use loop stream detectors, often preferring to remain rolled up.   Probably when optimising for those it'll be worthwhile cross-checking what Agner Fog says for extra insight. 

I'm open in planning to try other compilers as well, so that's some good starting info.

Jason

Currently I preparing new build environment on netbook. It will be x64 one cause it came with x64 Win7 onboard.
Wanna take opportunity and do great upgrade of buiuld environment too.
Ultimately will use VS2010 (unfortunately, I have access only to x86 prof version so will sit with VS2008 little more cause have full x64 pro suite).
Looks like Intel's part should be upgraded too. Perhaps, new Intel's composer? Should it support AVX? Should VS2010 support AVX? VS 2008 apparently should not ?Or some patches/service packs available?
I put new MB7 OCL NV onlyne, still CUDA 3.2 but will try CUDA 4.1RC2 on netbook so some more speed comparisons will be needed.
Testers stay tuned

The FX benefits dramatic from clock speeds.

Evenso on my last test i still had 6 cores running on boinc.
It was just a speed comparision between AMD and Intel app not overall speed test.

FX @3.9 GHZ

AK_v8b2_win_SSE3_AMD.exe -verb -nog / PG0009.wu :
AppName: AK_v8b2_win_SSE3_AMD.exe
AppArgs: -verb -nog
TaskName: PG0009.wu
Started at  : 10:28:53.820
Ended at    : 10:34:18.863
    324.981 secs Elapsed
    322.875 secs CPU time
Speedup     : 8.87%
Ratio       : 1.10 x

AK_v8b2_win_SSE3_INTEL.exe -verb -nog / PG0009.wu :
AppName: AK_v8b2_win_SSE3_INTEL.exe
AppArgs: -verb -nog
TaskName: PG0009.wu
Started at  : 10:34:22.592
Ended at    : 10:39:43.889
    321.204 secs Elapsed
    319.131 secs CPU time
Speedup     : 9.93%
Ratio       : 1.11 x

AK_v8b2_win_SSE3_AMD.exe -verb -nog / PG0395.wu :
AppName: AK_v8b2_win_SSE3_AMD.exe
AppArgs: -verb -nog
TaskName: PG0395.wu
Started at  : 10:39:47.555
Ended at    : 10:44:51.209
    303.607 secs Elapsed
    301.550 secs CPU time
Speedup     : 14.89%
Ratio       : 1.17 x

AK_v8b2_win_SSE3_INTEL.exe -verb -nog / PG0395.wu :
AppName: AK_v8b2_win_SSE3_INTEL.exe
AppArgs: -verb -nog
TaskName: PG0395.wu
Started at  : 10:44:54.860
Ended at    : 10:49:49.590
    294.684 secs Elapsed
    292.673 secs CPU time
Speedup     : 17.40%
Ratio       : 1.21 x

Also @3.9 GHZ the FX is up to 20% faster as the Phenom on 3.6 GHZ instead of 28% slower. 

Bench attached.

Yes, definitely looking at that.  Any AVX enabled app should really have the AVX path and at least one viable alternative path/library, since AVX availability must be detected at runtime, and on Windows is only supported under Win7 w/sp1 (or presumably Win8beta)

So far I have managed to build an AVX enabled static fftw lib, both x86 & x64 (which will be useful at least in particular for AP), that uses its own internal detection, but that build is only MSVS2010sp1 so far & will definitely need to bench an ICC built variant soon (supplied bench in fftw project at least),.  So I'll probably try linking it in to AKv8 as well as slotting in your V7 updates & splitting core functions into different SSE base versions.  I'm hopeful when I get going to have that operational pretty quickly.

I haven't gotten around to test linking in several sse level static IPPs yet into the same build, but looked at how to do it & doesn't appear to be difficult.  What I'll probably do is a huge build with every kind of FFT available linked in at the same time, then switch variants with a command line parameter so the testers can tell us which library is faster for which chip  (   let the testers work out the tricky mappings )

Jason

Are these libraries already included in the amd app?
http://developer.amd.com/libraries/appmathlibs/Pages/default.aspx