Hello Renato, thanks for your reply, sorry about the confusion with compilers - since there is a "clang" in the mac, I thought gcc was gcc.. After your suggestion, I modified the code, and installed a bona fide gcc compiler in the Mac.... I got more data that is kind of interesting, wanted to share with the gcc community. Someone might have an idea why this happens.

No matter what compiler I use, gcc or llvm on Linux I seem to have this problem of 64-bit code being 3x slower than 32-bit when very large procedures are called. In my Macbook the 64-bit code is consistently faster regardless of the compiler. I got my hands on an i7 Mac and the 64-bit code is consistently 10% to 15% faster than the 32-bit code and - I am afraid to say something "political" here, have no intention of offending anyone, just the facts - with all the optimizations turned on, modified code to force inlinining here and there, both gcc and llvm yield pretty much the same performance, in fact both are outstanding, reduced the time I reported previously from the 16.2s to 1.1s!!! AVX gave me an extra 10% over SSE (tricky to get AVX to compile in the mac with gcc, but not impossible).

Of course is hard to compare apples to apples here with Xeon Westmere at 2Ghz 
and i7 IvyBridge at 3.5GHz, but almost 15x is quite a difference, given the 
clock ratios are less than 2.

Now I am trying to investigate if the problem is with Linux itself - which is 
not so good because I need to release code on Linux, or there some strange 
cache issue, or the way libraries are setup, or with the Westmere vs IvyBridge. 
I will keep you posted if I find out more.

Best,
Ricardo


On 1/23/15 8:16 AM, Renato Golin wrote:
On 23 January 2015 at 16:07, Ricardo Telichevesky <rica...@teli.org> wrote:
gcc: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) - don't
know what that means expected  a number like 4.2.1 or something like that,
2.53 GHz Intel Core 2 Duo
Hi Ricardo,

This is not gcc at all, it's Clang+LLVM. :/

I'm not sure why Apple decided to call the binary "gcc", which
obviously causes more confusion than solves problems, but that's
beyond the point. You should try Richard's suggestions again on the
Linux/GCC that you originally started.

cheers,
--renato


Reply via email to