# BSD licensed C, C++ and Fortran compiler released.



## da1 (Jun 14, 2011)

Taken from the other forum , thx BSDfan666 



> PathScale announced today that the EKOPath 4 Compiler Suite is now available as an open source project and free download for Linux, FreeBSD and Solaris. This release includes documentation and the complete development stack, including compiler, debugger, assembler, runtimes and standard libraries. EKOPath is the product of years of ongoing development, representing one of the industries highest performance Intel 64 and AMD C, C++ and Fortran compilers.



http://www.pathscale.com/ekopath4-open-source-announcement


----------



## SirDice (Jun 14, 2011)

As far as I've been able to tell only parts of it have a permissive license. Mainly a few run-time libraries and the debugger. Can't find _any_ licensing info about the rest.


----------



## B0o-supermario (Jun 14, 2011)

So when will you guys throw gcc and replace it with something better?


----------



## da1 (Jun 14, 2011)

9.0 has LLVM/Clang (for the world/kernel)


----------



## xibo (Jun 14, 2011)

When something "better" can build the ports. Right now clang is in HEAD and pcc in ports, both more "C compiler" than gcc, but you won't be able to build the majority of the ports with either of them.

Also, there's no point to drop gcc as gcc can't be built by anything other then gcc, so once gcc is out of base you won't be able to build it via ports...

Nevertheless this is promising. Especially the fact they're doing the non-direct compiler tools, too.


----------



## knk (Jun 14, 2011)

SirDice said:
			
		

> As far as I've been able to tell only parts of it have a permissive license. Mainly a few run-time libraries and the debugger. Can't find _any_ licensing info about the rest.



Had trouble finding that, too. The COPYING file in the compiler soure states:



> All files in this source package marked as (C) PathScale, (C) Cray or (C) STMicroelectronics are licensed to you under the terms of version 3 of the GPL [...]



The debugger doesn't have a LICENSE ore COPYING file, though.

Oh, and the source code can be found here: https://github.com/path64 (and, for what it's worth, the compiler builds fine and produces running binaries under FreeBSD).


----------



## B0o-supermario (Jun 15, 2011)

@knk: Do you mean it isn't BSD licensed?
IMHO apple won't change clang to GPL


----------



## aragon (Jun 15, 2011)

From what I've gathered, the compiler is GPLv3, but the debugger and certain libraries are BSD licensed.  Not very useful for the FreeBSD project, but a welcome addition to ports I'm sure.


----------



## vertexSymphony (Jun 15, 2011)

aragon said:
			
		

> From what I've gathered, the compiler is GPLv3, but the debugger and certain libraries are BSD licensed.  Not very useful for the FreeBSD project, but a welcome addition to ports I'm sure.



libcxxrt is the library you're talking about: http://forums.freebsd.org/showthread.php?t=24015
PathDB is the debugger you're talking about (CDDL'ed): https://github.com/path64/debugger
And yes, the compiler seems GPLv3: https://github.com/path64/compiler/blob/master/COPYING

Alex.


----------



## Crivens (Jun 15, 2011)

xibo said:
			
		

> Also, there's no point to drop gcc as gcc can't be built by anything other then gcc, so once gcc is out of base you won't be able to build it via ports...


I did not check that for some time. If it is true these days, this is imho a great opportunity to ask for a facepalming "WTF?" smily.


----------



## LoZio (Jun 18, 2011)

knk said:
			
		

> (and, for what it's worth, the compiler builds fine and produces running binaries under FreeBSD).



Hi,

 I'm writing a how-to to build ekopath. I can start the big build process with the steps I described here (http://www.gorlani.com/portal/Home/Articles/BuildingekopathonFreeBSD.aspx) but I stop at: 

```
[ 33%] Generating pscrt-static-x86_64/memcpy_em64t_c.o

### Assertion failure at line 812 of /tmp/compiler/src/be/../common/util/id_map.h:
### Compiler Error in file /tmp/compiler/src/libpscrt/memcpy_em64t.c during Global Optimization -- Create AUX Symbol table phase:
### ID_MAP::Insert: displaced item not found in hash table.
*** Error code 1

Stop in /tmp/build.
*** Error code 1

Stop in /tmp/build.
*** Error code 1
```

Any ideas?
Thanks

Update: the only help from IRC channel is here:

```
(12.53.20) LoZio: Well, I read the readme and started build, but it stop here: ### Assertion failure at line 812 of
 /tmp/compiler/src/be/../common/util/id_map.h:
(12.53.20) LoZio: ### Compiler Error in file /tmp/compiler/src/libpscrt/memcpy_em64t.c during Global Optimization -- Create AUX Symbol table
 phase:
(12.53.20) LoZio: ### ID_MAP::Insert: displaced item not found in hash table.
(12.53.20) LoZio: *** Error code 1
(12.53.39) LoZio: this may be not FreeBSD specific
(12.53.54) codestr0m: LoZio: ERRORPISSEDOFFATFBSDTRYAGAINANOTHERDAY
```

Just before being banned from the channel. I think they should work a bit on their community support.


----------



## expl (Jun 18, 2011)

B0o-supermario said:
			
		

> So when will you guys throw gcc and replace it with something better?



When people stop writing GCC optimized/specific code for their third-party software. And that's not going to happen any time soon as most open source developers are Linux users/fans.


----------



## knk (Jun 20, 2011)

LoZio said:
			
		

> Hi,
> 
> I'm writing a how-to to build ekopath. I can start the big build process with the steps I described here (http://www.gorlani.com/portal/Home/Articles/BuildingekopathonFreeBSD.aspx) but I stop at:
> 
> ...



Didn't get that error. If it helps, I build from bcb4f5366a5414b12f74fc136cf43e74c1162b10 and ran *cmake* like this:

```
#!/bin/sh

GCCP=/usr/lib

   cmake -DCMAKE_BUILD_TYPE=Debug \
         -DPATH64_ENABLE_TARGETS="x86_64" \
         -DPATH64_ENABLE_MATHLIBS=ON \
         -DPATH64_ENABLE_FORTRAN=OFF \
         -DPSC_CRT_PATH_x86_64=/usr/lib \
         -DPSC_DYNAMIC_LINKER_x86_64=/libexec/ld-elf.so.1 \
         -DPSC_LIBSUPCPP_PATH_x86_64=$GCCP \
         -DPSC_LIBSTDCPP_PATH_x86_64=$GCCP \
         -DPSC_LIBGCC_PATH_x86_64=$GCCP \
         -DPSC_LIBGCC_EH_PATH_x86_64=$GCCP \
         -DPSC_LIBGCC_S_PATH_x86_64=$GCCP \
         ../compiler
```


----------



## LoZio (Jun 21, 2011)

knk said:
			
		

> Didn't get that error. If it helps, I build from bcb4f5366a5414b12f74fc136cf43e74c1162b10 and ran *cmake* like this:
> 
> ```
> #!/bin/sh
> ...



Ok, I also was successful in preparing the make process also with my parameters. The problem is during the make process. Testing your command line, I can note you used Debug instead of Release. Using your command line the make process stops here:


```
[ 52%] Building CXX object src/be/be/CMakeFiles/be-exec-x8664.dir/__/com/phase.cxx.o
make: don't know how to make /usr/local/lib/libdwarf.a. Stop
*** Error code 2

Stop in /tmp/build.
*** Error code 1
```

Using the git code downloaded 5 minutes ago:

```
commit c73993b29dac4d4f641ed09f0596679de49d509c
Author: Roman Divacky <rdivacky@freebsd.org>
Date:   Tue Jun 21 10:21:34 2011 +0200
```
Using stock 8.2 compiler, gcc 4.2.1.

--Edit
Just tried my "recipe" and using "Release". It crashes with the same error, but at 18%:


```
[ 18%] Building CXX object src/be/be/CMakeFiles/be-exec-x8664.dir/__/com/phase.cxx.o
make: don't know how to make /usr/local/lib/libdwarf.a. Stop
*** Error code 2
```

-- Edit (again )
7 minutes after posting this I googled to find infos about my stop error. I found this page as the first result. Just 7 minutes later. Am I the only one to find this amazing?


----------



## cforger (Jun 22, 2011)

Hi,

Using `pkg_add -r libdwarf` will get you past that error at 18%, I'm now stuck at 28% where you were stuck at 33% before:


```
[ 28%] Generating pscrt-static-x86_64/memcpy_em64t_c.o

### Assertion failure at line 812 of /root/work/path64/src/be/../common/util/id_map.h:
### Compiler Error in file /root/work/path64/src/libpscrt/memcpy_em64t.c during Global Optimization -- Create AUX Symbol table phase:
### ID_MAP::Insert: displaced item not found in hash table.
*** Error code 1
```

I checked this link https://github.com/path64/compiler/issues/6 , and it says we can't build a release with GCC, just a debug. 

I'm using the gorlani.com make line, with Debug instead of Release for the make build type. It's compiling now, we'll see where I end up tomorrow when I check.


----------



## LoZio (Jun 22, 2011)

cforger said:
			
		

> Using `pkg_add -r libdwarf` will get you past that error at 18%, I'm now stuck at 28% where you were stuck at 33% before:
> 
> 
> ```
> ...



It goes further, but not to the end.


```
[ 30%] Generating ../../lib/x8664/64/libmv.so
/usr/bin/ld: /use/lib/crti.o: No such file: No such file or directory
*** Error code 1
```

It seems I'm missing a motion detection library from Google. I got it from https://github.com/libmv/libmv but it does not build.


----------



## cforger (Jun 22, 2011)

I managed to get to 38% before it crashed asking about the Fortran compiler. I didn't run into your errors.


```
[ 38%] Generating pathfortran-static-x86_64/__/libfi/mathlb/ieee_exceptions_F90.o, pathfortran-static-x86_64/IEEE_EXCEPTIONS.mod
gcc: /root/work/path64/src/libpathfortran/../libfi/mathlb/ieee_exceptions.F90: Fortran compiler not installed on this system
*** Error code 1
```

I believe that's a make switch option, I'll set it and try again. 

I'm running 9-CURRENT, built from 2011.05.28.15.00.00 on the csup src file.


----------



## cforger (Jun 22, 2011)

Yup, that worked, I made it to 100%. I now have a shiny new compiler to play with on FreeBSD-9. Here's my cmake command that worked for me;

`set MYLIBPATH=/usr/lib`


```
cmake ~/work/path64 \
-DPATH64_ENABLE_TARGETS=x86_64 \
-DPATH64_ENABLE_MATHLIBS=ON \
-DPATH64_ENABLE_HUGEPAGES=OFF \
-DPATH64_ENABLE_FORTRAN=OFF \
-DPSC_CRT_PATH_x86_64=$MYLIBPATH \
-DPSC_DYNAMIC_LINKER_x86_64=/libexec/ld-elf.so.1 \
-DPSC_LIBSUPCPP_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBSTDCPP_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBGCC_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBGCC_EH_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBGCC_S_PATH_x86_64=$MYLIBPATH \
-DPATH64_ENABLE_HUGEPAGES=OFF \
-DCMAKE_BUILD_TYPE=Debug
```

Of course, it could refuse to compile even a 'hello world' program, we'll see as I start to test it.


----------



## cforger (Jun 22, 2011)

Update:

I have it compiling a basic "Hello World" program, and I'm even compiling a few of the smaller ports (TinyDNS for one) using pathcc.

I notice that if I execute *pathCC --help* (the c++ version) I receive 
	
	



```
Bus error (core dumped)
```
 error message about halfway through the help output dump. Probably not a good thing, but maybe it's just a silly error. I'm able to compile simple programs with pathCC or pathcc.

I also notice that any port that uses configure doesn't like pathcc - It fails the c preprocessor tests. 


```
checking for /opt/path64/bin/pathcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of /opt/path64/bin/pathcc... gcc3
checking how to run the C preprocessor... /opt/path64/bin/pathCC
configure: error: C preprocessor "/opt/path64/bin/pathCC" fails sanity check
===>  Script "configure" failed unexpectedly.
Please report the problem to vd@FreeBSD.org [maintainer] and attach the
"/usr/ports/net-mgmt/iftop/work/iftop-0.17/config.log" including the output
of the failure of your make command. Also, it might be a good idea to provide
an overview of all packages installed on your system (e.g. an `ls
/var/db/pkg`).
*** Error code 1
```

The way I get around this is;
 - set /etc/make.conf back to the defaults (use gcc)
 - run *make configure* in the port to generate all the configure data
 - set /etc/make.conf to the pathcc files
 - *make install*

Worked for iftop, and it runs. I'm going to keep playing with some of the ports and see how this works. I'm interested in samba35, as I've seen increased performance with gcc46 and -O3 optimization on my file servers, so there could be room for pathcc to help as well. 

*Kernel:*

Being aggressively optimistic, I went for a buildkernel - And it's as messy as you'd expect. I know I won't receive help on it here, but others will want to try this, so I'm passing on what I'm finding. 

One option that is helpful for using pathcc as a drop-in for gcc is -woffoptions, the rest is manually ripped out of the kern.mk files, to see how far I can push this to compile. 

Where a buildworld dies today is:


```
### Assertion failure at line 521 of /test/path64/src/be/cg/tnutil.cxx:
### Compiler Error in file /usr/src/sys/fs/nfsclient/nfs_clbio.c during Code_Expansion phase:
### don't know how to make dedicated TN for class (null)
*** Error code 1

Stop in /usr/obj/usr/src/sys/sankernel2.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
```

I see complaints about this on the Open64 compiler threads as well. 

We'll see how much time I have tomorrow to test this further.


----------



## LoZio (Jun 23, 2011)

cforger said:
			
		

> Yup, that worked, I made it to 100%. I now have a shiny new compiler to play with on FreeBSD-9. Here's my cmake command that worked for me;
> 
> `set MYLIBPATH=/usr/lib`
> 
> ...



The only difference is that you set no fortran support, I'm trying with the same settings.
The last git code says:


```
commit 80b1b74250fd219b87ae74809172ca6b8f8363f5
Author: Alexander Esilevich <aesilevich@pathscale.com>
Date:   Wed Jun 22 18:02:30 2011 +0700

    added cmake option for path to libdwarf
```

that is installed in /usr/lib by default, and I put the line on my cmake. Not setting it will stop build at 13%. Setting the path it stop just at 52%:


```
[ 52%] Building CXX object src/be/be/CMakeFiles/be-exec-x8664.dir/iter.cxx.o
[ 52%] Building CXX object src/be/be/CMakeFiles/be-exec-x8664.dir/__/com/phase.cxx.o
Linking CXX executable ../../../lib/x8664/be
/usr/lib/libdwarf.so: undefined reference to `elf_strptr'
/usr/lib/libdwarf.so: undefined reference to `elf_getident'
```

I uninstalled the port version of libdwarf that is very old and compiled libdwarf-20110612 (that also is not easy). It reduces the number of errors in this phase, but the two above remain. I also installed LibElf with no luck.

It's becoming very very tricky.


----------



## cforger (Jun 23, 2011)

Hmm, it sounds like you should start with a fresh 8.2.

Or better yet, try going up to a fresh install of 9-CURRENT - This is all pretty "testy-feely" anyway, and by the time you have something with Path64 stable enough to be using, 9 will be out anyway, so you may as well get a head-start on it. I'm finding my copies of 9 to be quite stable.

I managed to build both istgt and samba35 with path64 last night, I'm setting up an environment for some small speed tests to see if there is a difference with path64 compiling these over gcc42 or gcc46.


----------



## LoZio (Jun 24, 2011)

cforger said:
			
		

> Hmm, it sounds like you should start with a fresh 8.2.
> 
> Or better yet, try going up to a fresh install of 9-CURRENT - This is all pretty "testy-feely" anyway, and by the time you have something with Path64 stable enough to be using, 9 will be out anyway, so you may as well get a head-start on it. I'm finding my copies of 9 to be quite stable.
> 
> I managed to build both istgt and samba35 with path64 last night, I'm setting up an environment for some small speed tests to see if there is a difference with path64 compiling these over gcc42 or gcc46.



I'm starting each time from a fresh/patched 8.2 x64 install, so messy installation is not likely. The (not so) strange thing is that every git commit results in different errors, having now "stabilized" the cmake string. I'll try with today's git and report.
Bye.


----------



## Yamagi (Jun 25, 2011)

Try the last "stable" version 4.0.10, tagged at june 08, 2011:

```
git clone https://github.com/path64/compiler.git
cd compiler/
git checkout 4.0.10
```

This one builds for me with the cmake string from cforger. After this first stage pathcc can compile itself into a "Release" configuration:

```
setenv CC pathcc
setenv CXX pathCC

cmake ../compiler \
-DCMAKE_INSTALL_PREFIX=/usr/opt/pathscale \
-DPATH64_ENABLE_TARGETS=x86_64 \
-DPATH64_ENABLE_MATHLIBS=ON \
-DPATH64_ENABLE_HUGEPAGES=OFF \
-DPATH64_ENABLE_FORTRAN=OFF \
-DPSC_CRT_PATH_x86_64=$MYLIBPATH \
-DPSC_DYNAMIC_LINKER_x86_64=/libexec/ld-elf.so.1 \
-DPSC_LIBSUPCPP_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBSTDCPP_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBGCC_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBGCC_EH_PATH_x86_64=$MYLIBPATH \
-DPSC_LIBGCC_S_PATH_x86_64=$MYLIBPATH \
-DPATH64_ENABLE_HUGEPAGES=OFF \
-DCMAKE_BUILD_TYPE=Release
```

I've uploaded the resulting binaries to: http://deponie.yamagi.org/freebsd/ekopath/ekopath_4.0.10_freebsd_8.2_amd64.tar.xz Extract in /usr/opt and add /usr/opt/pathscale/bin to your $PATH.


----------



## LoZio (Jun 26, 2011)

Thanks Yamagi for pointing out to checkout 4.0.10. I was able to build ekopath in debug and release (after an initial problem...). 

I updated the how-to with the final procedure (and credits ) on http://www.gorlani.com/portal/Home/Articles/BuildingekopathonFreeBSD.aspx. Now I'm going to build some programs I use and compare results. I'll post them when done. Thanks again to all people on the thread.


----------



## LoZio (Jun 26, 2011)

Yamagi said:
			
		

> I've uploaded the resulting binaries to: http://deponie.yamagi.org/freebsd/ekopath/ekopath_4.0.10_freebsd_8.2_amd64.tar.xz Extract in /usr/opt and add /usr/opt/pathscale/bin to your $PATH.



I built my own release, and also tried yours, but it seems to have problems with ipa optimizations. If I compile with -Ofast or -ipa alone (also setting LDFLAGS), I get

```
/usr/opt/pathscale/lib/4.0.10/x8664/ipa_link: cannot open linker script file ldscripts/elf_x86_64_fbsd.xsc: No such file or directory
```
Are you able to use ipa?


----------



## Yamagi (Jun 27, 2011)

That's a "bug" in pathcc. It searches the linker scripts in ./ldscripts, which is wrong. The correct path would be /usr/libdata/ldscripts. There are two ways:
1. Copy /usr/libdata/ldscripts into the current directory, e.g. "*cp /usr/libdata/ldscripts . ; pathcc ...*"
2. Patch pathcc to look into /usr/libdata/ldscripts:

```
diff --git a/src/ipa_link/ld/eelf_x86_64_fbsd.c b/src/ipa_link/ld/eelf_x86_64_fbsd.c
index f898437..c9d12f7 100644
--- a/src/ipa_link/ld/eelf_x86_64_fbsd.c
+++ b/src/ipa_link/ld/eelf_x86_64_fbsd.c
@@ -1094,34 +1094,34 @@ gldelf_x86_64_fbsd_get_script (int *isfile)
   *isfile = 1;
 
   if (link_info.relocatable && config.build_constructors)
-    return "ldscripts/elf_x86_64_fbsd.xu";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xu";
   else if (link_info.relocatable)
-    return "ldscripts/elf_x86_64_fbsd.xr";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xr";
   else if (!config.text_read_only)
-    return "ldscripts/elf_x86_64_fbsd.xbn";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xbn";
   else if (!config.magic_demand_paged)
-    return "ldscripts/elf_x86_64_fbsd.xn";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xn";
   else if (link_info.pie && link_info.combreloc
           && link_info.relro && (link_info.flags & DT_BIND_NOW))
-    return "ldscripts/elf_x86_64_fbsd.xdw";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xdw";
   else if (link_info.pie && link_info.combreloc)
-    return "ldscripts/elf_x86_64_fbsd.xdc";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xdc";
   else if (link_info.pie)
-    return "ldscripts/elf_x86_64_fbsd.xd";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xd";
   else if (link_info.shared && link_info.combreloc
           && link_info.relro && (link_info.flags & DT_BIND_NOW))
-    return "ldscripts/elf_x86_64_fbsd.xsw";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xsw";
   else if (link_info.shared && link_info.combreloc)
-    return "ldscripts/elf_x86_64_fbsd.xsc";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xsc";
   else if (link_info.shared)
-    return "ldscripts/elf_x86_64_fbsd.xs";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xs";
   else if (link_info.combreloc && link_info.relro
           && (link_info.flags & DT_BIND_NOW))
-    return "ldscripts/elf_x86_64_fbsd.xw";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xw";
   else if (link_info.combreloc)
-    return "ldscripts/elf_x86_64_fbsd.xc";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.xc";
   else
-    return "ldscripts/elf_x86_64_fbsd.x";
+    return "/usr/libdata/ldscripts/elf_x86_64_fbsd.x";
 }
```


----------



## vertexSymphony (Jun 27, 2011)

Yes, that was one of the things that I disliked in the first place: the building system (how it's done). Broken everywhere, I've worked with cmake and easily they could have written a CMake module and try to autodetect stuff (and, if user is interested in changing something, well ... ah, ccmake also exists, so they also could tackle that one easily), but no, they ship a source distribution that claims good FreeBSD support that actually is broken everywhere and you have to deal with it.

I'm a little bit disappointed with this first impression, but I'll be doing some benchmarks, and if the compiler is worth it, well, it simply worth it.

Cheers and sorry if I was rude.


----------



## dandelot (Jun 28, 2011)

LoZio said:
			
		

> ```
> [ 52%] Building CXX object src/be/be/CMakeFiles/be-exec-x8664.dir/iter.cxx.o
> [ 52%] Building CXX object src/be/be/CMakeFiles/be-exec-x8664.dir/__/com/phase.cxx.o
> Linking CXX executable ../../../lib/x8664/be
> ...



Those functions are a standard part of libelf (I happen to have a 1990 copy of the SVR4 Programmers Reference Manual and there they are) so either the libelf is incomplete (in the sense that it does not implement standard libelf functions) or libdwarf or libelf was somehow built wrong? These calls were in libdwarf in 1999 (that original is on the libdwarf source I maintain on the web, though the Sourceforge source does not go back very far), they are nothing new.  

Speaking as libdwarf maintainer.


----------



## cforger (Jun 28, 2011)

I've been doing some benchmarks as well, and I'm not finding it to blow the doors off gcc just yet. In fact, if you can get gcc 4.6 or similar to compile with the appropriate flags, you will probably have a very similar performance results to pathcc. Some of the threads suggest better tweaking of gcc's flags will allow it to match or beat the pathcc performance numbers on phoronix.com. 

However, the guys at pathscale look to be genuinely interested in making the product better (check the thread at this page or earlier here, before it was hijacked by the usual forum nonsense ), and I feel there are areas that I haven't encountered that pathcc would produce a better binary than gcc. If pathcc isn't what you want today, it may be tomorrow. 

I do like the fact that when I compile pathcc, it hands out % status updates. That's very cool, I wish we had that for buildworld on FreeBSD. 

I'm frustratingly close to having pathcc complete a *make buildkernel*, but the FreeBSD make tree is rather complex, and not everything listens to make.conf, requiring changes in a host of places that have unwanted consequences. 

I am struggling on seeing if I can make pathcc compile a kernel (and for that matter, gcc 4.6) - Mostly for my own personal interests - After years of blindly executing *make buildworld* I'm finally seeing the 'behind the scenes' technical detail of how everything comes together, and I love a challenge. Before anyone jumps on me for trying such a feat, my goal is knowledge, so how can I loose or waste anything other than my own time? 

However, maybe our efforts are really best put towards making clang/llvm better for FreeBSD - It's where we're going, and the effort in having two compilers able to buildworld is probably out of the question. 

I'd invest my time in helping FreeBSD progress with clang/llvm, but that's completely out of my reach at this stage, unless someone had some good suggestions.


----------



## LoZio (Jun 29, 2011)

cforger said:
			
		

> I've been doing some benchmarks as well, and I'm not finding it to blow the doors off gcc just yet.
> [...]



Hi Chris,

I'm trying to find some time to create a page with some benchmarks I did. In the meanwhile I can surely say I had the same feelings as you about pathcc code performance. Except from some benchmark, that is only useful to itself, I found performance a little bit worse than standard *gcc -O2*. I'm also trying gcc45 and the results vary a lot between applications.

The real problem is to find a benchmark representative of your load, and create a reliable test. In any case, generally speaking, I think that if you need special tests and microsecond-aware clocks to compare code behaviour, the problems shifts to finding the most practical compiler to use, the one that compiles without problems the majority of programs. In this moment, pathcc is not at that level, but hope will get there.

Looking at MY servers running MY loads, I hardly find them capped by CPU performance. I would like to have big SSD drives instead , or efficient support of NUMA architectures, that is coming in 9.0.

Let's see how the community will contribute to pathcc, for now I'm including it in the pre-release tests of my tools.

Bye


----------



## codestr0m (Jun 29, 2011)

The thing I love most about forums and sometimes the BSD community is a random patch which never makes it upstream. 

Does anyone use FreeBSD for computationally complex code, Fortran or huge c++ applications?  The former two should give good performance now and the latter is a continuous work-in-progress.


----------



## cforger (Jun 30, 2011)

Ah, and ultimately this is why the wiser FreeBSD people tell everyone else "don't mess with the base system compilers" as it's a very difficult road to tread...  ...and they get tired of explaining how to do it to each newbie every other week. 

LoZio: Thanks for the update. 

codestr0m: Welcome, I've followed your posts on Phoronix, you've been most helpful there, and I hope you have the time to follow the FreeBSD threads as well, although I understand following all the threads can be a full-time job. I believe you're the CTO at Pathscale, so you're probably our best source of information.

You can see some of us are bloggers here, and will gladly share any information about your product through our outlets - I know you guys are busy reorganizing your site and output of info to catch up with the announcement, but we'll gladly help spread the world as we're quite interested. 

High Performance Computing and FreeBSD don't always get along, for various reasons - and it's something that I know I'd like to see change. I think we have a very stable and efficient code base, but it lacks the large support that Linux receives from hardware vendors (Infiniband anyone? Or fully functional LSI drivers for recent chip-sets), thus making it a more difficult choice over Linux when a lab needs to settle on an OS for their work. I see it as a chicken-and-egg type of problem. 

Knowing where and when to use pathcc is key - Maybe we shouldn't be trying to use it for our network-intensive applications, and using it for what you suggest - computationally heavy, or large programs. Getting that word out may be critical, to avoid frustrating early-adopters who may then be quite displeased to see what pathcc can give them in an area that it's not really focused on. 

My FreeBSD world revolves around a number of very small programs trying to run as efficiently and quickly as possible, so I may be the wrong guy to be seeing if pathcc can help in my environment. 

On the other hand, I'm also quite interested in the libcxxrt that you guys released. Do the same performance guidelines about pathcc apply to this lib?

Thanks (for reading the forums, and for making it open-source).


----------



## codestr0m (Jul 1, 2011)

For your run-of-the-mill scalar applications we can possibly get you better performance, but depending on how much you want will depend how much time you can spend tuning it.  For example I'd recommend in your case to try FDO (Feedback driven optimization)

libcxxrt is part of our stack and the same performance guarantee applies.  Our goal is to make it the smallest, fastest and cleanest c++ runtime there is - end of story.  Report bugs if you find the contrary.

If a thousand people tell us they want a fast MySQL or Samba or foobar that's valuable feedback to us.  The point of open sourcing the compiler is to get everyone in the world using it.  (So please don't discourage anyone - except FreeBSD community 

I get notifications on replies to most of the forums and we have a monitoring service on our (tm).  Thus if it has general visibility on the web I'll likely see it.  In summary if I have time/interest I'll reply.

<rant>
I must say that I do get burnt out on ignorance (not the communities fault as compilers are very complex) and license bs.  I tend to focus on technical issues day-to-day and when we get shit thrown in our face for the compiler being GPLv3 it's *very* discouraging.  Having feuds against competing or alternative projects I think is somewhat natural, but doing so blindly based mostly on licensing doesn't make a bit of sense for me.

With that - I'd love to see pathcc build the whole FreeBSD world and be a default compiler option, but would it get blocked for licensing reasons above?  Please do note that all the runtime libraries are permissively licensed unlike GNU.
</rant>

@HPC - You're going to need a vendor who is willing to take a $$ risk and a significant launching customer as a case study.  The laundry list will basically be porting the HPC stack to FreeBSD (Fortran/optimized libs.. etc), IB drivers or whatever proprietary interconnect and kernel scalability/stability (this could range from network issues to multicore)  In the very near future not having things like AVX would be a complete show-stopper.  Other things like missing CUDA/GPGPU support are increasingly important.  We can help with anything outside of the kernel and hardware.


----------



## cforger (Jul 4, 2011)

codestr0m: 

Yes, I understand your lack of love for the legal/licensing matters - I share it too, but I think the GPL status of pathcc will keep it from being the default compiler for FreeBSD, regardless of other reasons keeping it from being the default compiler.

In my work, the license status doesn't matter to me as I'm not distributing anything. I'd suggest a separate thread be spawned if people wish to debate/discuss this. Let's keep this focused on the technical aspects if we can. 

I'm interested in squeezing as much performance out of FreeBSD as possible, however I'm a "well-wisher", and regular user, not a code-commiter, and I'm still at least a year away from being able to dedicate the time to start helping on some small part of FreeBSD. 

The bulk of the effort on the compiler front is switching to clang/llvm - if you can present pathcc as a viable alternative, and can dedicate some support resources to those who wish to undertake the effort, then it will work as long as there is a team dedicating the time. However, it does present more of a problem on your end, as I'm sure there's plenty of work/effort on making pathccmore compatible with gcc make files, you don't need to also be working about compatibility with clang make files. 

I for one, can't find the user manual for pathcc 4.0, only 3.2 on the net, so I can't research further into what I should be doing to drop pathcc in place of gcc for more of my applications. Maybe the first steps are updating your media/info sources so as we start trying to use the product with FreeBSD, we can progress easier. If we can find it easily from google, we're going to make better progress. Then as we start running into more concrete problems that can't be solved by RTFM, we can work with your team to progress the issue.


----------

