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

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:
Code:
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";
 }
 
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.
 
LoZio said:
Code:
[ 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'

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.
 
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.
 
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
 
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.
 
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).
 
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.
 
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.
 
Back
Top