[alberto]

PathScale EKOPath 4 Compiler Suite has been released as an open source project for Linux, FreeBSD and Solaris. Here the official announcement:

http://www.pathscale.com/ekopath4-op...e-announcement

The download link is a bit hidden here: http://www.pathscale.com/ekopath-compiler-suite and it is

http://c591116.r16.cf2.rackcdn.com/e...-installer.run

Best,

[olivierG]

hello,
Does someone have already setup environement (i.e bashrc and settings.sh) in order to use this pathscale compiler with OpenFOAM ?

NB: actual files seems GCC centric.

PS: trying to keep "Gcc" but changing
export WM_CC='/opt/ekopath-4.0.10/bin/pathcc'
export WM_CXX='/opt/ekopath-4.0.10/bin/pathCC'
does not work. thirdParty (from scotch) gives error thus either the rest.
edit: in fact, error are from mpicc

Regards,
olivier

[alberto]

Originally Posted by olivierG

hello,
Does someone have already setup environement (i.e bashrc and settings.sh) in order to use this pathscale compiler with OpenFOAM ?

I doubt: the compiler was open-sourced yesterday ;-)

[wyldckat]

Greetings to all!

@Olivier:

Originally Posted by olivierG

PS: trying to keep "Gcc" but changing
export WM_CC='/opt/ekopath-4.0.10/bin/pathcc'
export WM_CXX='/opt/ekopath-4.0.10/bin/pathCC'
does not work. thirdParty (from scotch) gives error thus either the rest.
edit: in fact, error are from mpicc

You can't change from olive oil to cooking oil and expect things to taste the same or even better, without doing dome additional tweaks to the recipe!!

I haven't tested this myself, but here's a short list of the files you will need to take a look at:

• OpenFOAM-1.x.x/etc/bashrc <- change WM_CC and WM_CCX, as well as the WM_COMPILER option, from gcc to pathcc.
• OpenFOAM-1.x.x/etc/settings.sh <- choose "openfoam" compiler, instead of system, and add the specs for pathcc (folders and versions). Follow the structure from the Gcc branch
• OpenFOAM-1.x.x/wmake/rules <- you will have to add a new folder for pathcc. For example linuxPathCC and/or linux64PathCC.
  Copy it from one of the Gcc ones. Keep a lookout for hard-coded gcc and g++ references; for example, files "rules/linuxGcc/c" and "rules/linuxGcc/c++" have them hard coded! Likewise in "rules/linuxGcc/general".
• ThirdParty-1.x.x/scotch_5.1/src/Makefile.inc <- Also has various hard coded references!

There might be one or two more, but I can't remember which and where.

Keep in mind that probably you will have to change the rules in the folder "rules/linuxPathCC", in order to comply with pathcc's options And I quote:

Originally Posted by http://www.pathscale.com/docs/pathCC.html

In addition to the options described here, the pathcc/CC compiler supports the following GNU CC options (as described on the GCC man page or at http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/):

Some things have changed since gcc 3.3.1 to 4.4.x and 4.5.x...


@Alberto: Shouldn't the OpenFOAM code need some massive restructuring for taking full advantage of PathCC? Or at the very least, adding OpenMP to the Pstream library?

Best regards,
Bruno

[alberto]

Originally Posted by wyldckat

@Alberto: Shouldn't the OpenFOAM code need some massive restructuring for taking full advantage of PathCC? Or at the very least, adding OpenMP to the Pstream library?

Not a compiler expert here (I reported the news because the release of PathScale under GPL means a huge step ahead, since Linux finally has a full-featured HPC compiler), but I guess it depends on what you want to achieve.

If you mean re-writing parts of the code so that parallelisation is done with OpenMP, then yes, you need a lot of restructuring. If you choose to rely on the automatic features of the compiler for that (it seems PathScale strong point is exactly this) , then you only need "minor" changes: rewriting the compilation rules, tuning the options, and eventually patch those parts of the code that do not build.

Best,

[l_r_mcglashan]

Just tried this on our cluster on an in-house C/C++ code base (lots of monte carlo in it) with the same optimisation flags (-O2/-O3) as Gcc and it's twice as slow. Bit disappointed initially but will have a look again sometime later this week.

[alberto]

Originally Posted by l_r_mcglashan

Just tried this on our cluster on an in-house C/C++ code base (lots of monte carlo in it) with the same optimisation flags (-O2/-O3) as Gcc and it's twice as slow. Bit disappointed initially but will have a look again sometime later this week.

Looks a bit strange. However, if you do not find the reason, tell them (Freenode - #pathscale channel). Their motto is "if it's not faster than gcc, then it's a bug"

[wyldckat]

Greetings to all!

Originally Posted by l_r_mcglashan

Just tried this on our cluster on an in-house C/C++ code base (lots of monte carlo in it) with the same optimisation flags (-O2/-O3) as Gcc and it's twice as slow. Bit disappointed initially but will have a look again sometime later this week.

I'm curious about this... keep us posted if possible
But I'll remind you that gcc 3.{3,4}.x was waaaay slower that gcc 4.{3,4,5}.x! And according to their docs I posted before, their "arguments" reference for gcc was still "gcc 3.3.1", sooo...

Best regards,
Bruno

[l_r_mcglashan]

Good old benchmarks!

Yes, I have timings for gcc3.4 for my apps and the simulations are generally around 10% slower than with gcc4.6. pathCC is, like, TWICE as slow with the same flags (even had a look at a few of the extra ones, but no luck).

Anyway, better stop procrastinating. If anyone gets decent results using this then it would be nice to know.

[alberto]

This sounds a interesting, given that on benchmarks the performance improvement of PathScale is quite large compared to gcc 4.5.2 (there is a test with Poisson solvers):

http://www.phoronix.com/scan.php?pag...th4_open&num=3

http://www.phoronix.com/scan.php?pag...th4_open&num=4

Best,

[l_r_mcglashan]

Well I just tried Himeno bench 98 source code and got this (am I being fair?):

gcc (GCC) 4.6.0 20110530 (Red Hat 4.6.0-9)
gcc -c -O3 -DLARGE himenoBMT.c
gcc -O3 himenoBMT.o -o bmt
./bmt

mimax = 513 mjmax = 257 mkmax = 257
imax = 512 jmax = 256 kmax =256
cpu : 46.553092 sec.
Loop executed for 100 times
Gosa : 4.882812e-04 
MFLOPS measured : 2403.078704
Score based on MMX Pentium 200MHz : 74.467887

PathScale (tm) Compiler Suite: Version 4.0.10
GNU gcc version  (PathScale 4.0.10 driver)

pathcc-4.0.10 -c -O3 -DLARGE himenoBMT.c
pathcc-4.0.10 -O3 himenoBMT.o -o bmt
./bmt

mimax = 513 mjmax = 257 mkmax = 257
imax = 512 jmax = 256 kmax =256
cpu : 66.520140 sec.
Loop executed for 100 times
Gosa : 4.882812e-04 
MFLOPS measured : 1681.757495
Score based on MMX Pentium 200MHz : 52.115200

[l_r_mcglashan]

Small update: The above case will run just as fast with the pathcc compiler if you use the -LNOrefetch=0 flag.

So I wouldn't trust any benchmarks, especially if they're not at least compared with the GCC4.6 compiler with -O3 turned on.

[alberto]

Originally Posted by l_r_mcglashan

Small update: The above case will run just as fast with the pathcc compiler if you use the -LNOrefetch=0 flag.

So I wouldn't trust any benchmarks, especially if they're not at least compared with the GCC4.6 compiler with -O3 turned on.

Did you use SSE specific flags with pathscale?

Could you report the case to PathScale guys? I showed them this thread, and they asked to open a bug report so that they can examine the case, but I do not know the details of what you did.

About benchmarks, they are really case- and hardware-specific. Also, there is another factor: what compiler was used to build the compiler and libraries?

Best,

[linnemann]

I also tested this against the std 4.4.x version in SL6.0 and pathCC is WAY slower than gcc in the std icoFoam readme tutorial.

[alberto]

Yes, I did not have good results either in comparison to a standard build with gcc 4.5.1 on openSUSE 11.4. I'll try to file a bug report, since that's what they suggested to do.

@Niels: Our of curiosity, what options did you use?

Best,

[linnemann]

Basically just the gcc ones without one option, cant remember which one but pathCC complained about it and just removed it from the c++ rules of wmake.