Re: compiling Intel TBB

[Sergei Steshenko]

----- Original Message -----
> From: Jordi Gutiérrez Hermoso <address@hidden>
> To: Sergei Steshenko <address@hidden>
> Cc: "address@hidden" <address@hidden>
> Sent: Sunday, May 13, 2012 5:53 AM
> Subject: Re: compiling Intel TBB
> 
> On 12 May 2012 19:28, Sergei Steshenko <address@hidden> wrote:
>>  Hello,
>> 
>>  as I understand it, SuiteSparse benefits from using TBB (Thread Building 
> Blocks), so I've decided to compile TBB.
>> 
>>  It was easy, but I've noticed that '-march=pentium4' is chosen. 
> It is funny since I have an AMD processor.
> 
> Intel has been known to intentionally pessimise for non-Intel
> hardware. See this, for example:
> 
>     
> http://yro.slashdot.org/story/05/07/12/1320202/amd-alleges-intel-compilers-create-slower-amd-code
> 
> Intel still pessimises, but the original article is no longer there,
> presumably due to the following disclaimer at the bottom:
> 
>     
> http://software.intel.com/sites/products/web2010/prod-images/icc12-1_spec_lin-800.png
> 
> So, they're still doing it, but because they're telling you that
> they're doing it, they can do it legally.
> 
> I would expect other software other than icc to also pessimise. I see
> that TBB is free, so perhaps they hide it better there or they don't
> do it at all. All in all, it seems certain that Intel has no interest
> in helping you work with non-Intel hardware, so you're probably on
> your own. You should consult with the TBB or Suitesparse people, for
> best luck on how to make it work on AMD hardware.
> 
> HTH,
> - Jordi G. H.
> 

I think in this case you attribute to malice what should be attributed to 
stupidity.

The TBB package has a number of .inc files:

./build/xbox360.inc
./build/xbox360.cl.inc
./build/windows.gcc.inc
./build/linux.inc
./build/macos.inc
./build/linux.xl.inc
./build/AIX.inc
./build/macos.gcc.inc
./build/big_iron.inc
./build/common.inc
./build/windows.cl.inc
./build/FreeBSD.inc
./build/AIX.gcc.inc
./build/SunOS.inc
./build/linux.icc.inc
./build/FreeBSD.gcc.inc
./build/windows.inc
./build/windows.icl.inc
./build/macos.clang.inc
./build/macos.icc.inc
./build/common_rules.inc
./build/SunOS.suncc.inc
./build/SunOS.gcc.inc
./build/linux.gcc.inc
.

As I wrote earlier, in ./build/linux.gcc.inc one can see:

     81 ifeq (ia32,$(arch))
     82     #CPLUS_FLAGS += -m32 -march=pentium4 # commented out by Sergei
     83     CPLUS_FLAGS += -m32 -march=native -mtune=native # added by Sergei
     84     LIB_LINK_FLAGS += -m32
     85 endif

, but, say, in./build/FreeBSD.gcc.inc one can see this:

ifeq (ia32,$(arch))
    CPLUS_FLAGS += -m32
    LIB_LINK_FLAGS += -m32
endif


and in ./build/windows.gcc.inc :

ifeq (ia32,$(arch))
    CPLUS_FLAGS += -m32 -march=i686
    LIB_LINK_FLAGS += -m32
endif
.

Again, look at what "grep -r pentium4 . | grep -v '\.bck'" produces:

./build/linux.xl.inc:# TODO: equivalent for -march=pentium4 in CPLUS_FLAGS
./build/linux.xl.inc:    CPLUS_FLAGS += -q32 -qarch=pentium4
./build/linux.gcc.inc:    #CPLUS_FLAGS += -m32 -march=pentium4
.

If you think about it, 'pentium4' is wrong for Intel HW too - because most of 
modern Intel HW is not Pentium 4.

In ./build/linux.inc I see:

ifndef arch
        uname_m:=$(shell uname -m)
        ifeq ($(uname_m),i686)
                export arch:=ia32
        endif
        ifeq ($(uname_m),ia64)
                export arch:=ia64
        endif
        ifeq ($(uname_m),x86_64)
                export arch:=intel64
        endif
        ifeq ($(uname_m),sparc64)
                export arch:=sparc
        endif
        ifndef arch
                export arch:=$(uname_m)
        endif
endif

, i.e. ia32 is set because i686 is seen, and later on because of ia32 pentium4 
is chosen.

And i686 is seen because this is what my distro reports:

address@hidden:~/junk/tbb40_20120408oss> uname -m
i686
.

And 'arch' can be forced on 'make' command line.

Regards,
  Sergei.





and in ./build/windows.gcc.inc