O compilers...

Submitted by axel on Tue, 16/06/2009 - 17:53

Hi!

ROOT does not only work on Linux SLC4, 32 bit - it is working on so many platforms that people are disappointed if it does not work on their current OS. Supporting multiple platforms is not easy (example: I am trying to re-install my old windows box from scratch, so my summer student can use it - and I am doing that since about two hours now, argh). But here I just want to talk a bit about compiler versions.

The new ROOT release will support the new GCC 4.4. Almost nowbody uses it - but the version we will publish in a few days will be used for several months, if not years. And in two years people will be frustrated if ROOT doesn't work on (in two years) the oh so common GCC 4.4 - so we do our best in getting new compilers supported as quickly as possible. GCC 4.4 is one example; I am working on getting ROOT to build with the new Microsoft compiler that's going to be available by the end of the year, so ROOT can support it a few days after Microsoft has released it.

These days, new compilers simply do better with respect to complaining about wrong code. I.e. they don't compile more but less code. OK, fine, that's what the standard is for. The problem is that many Linux distributions define their own set of rules. Something compiling with a hand-build GCC 4.4 does not necessarily build with Fedora's; something compiling with Debian's GCC 3.3 might give warnings in Ubuntu's. This makes support of new compilers really tricky...

The actual work needed to support a new compiler is thus code correctness on one hand, and CINT on the other. CINT keeps the declarations of all STL implementations we support, so it can build a dictionary for them. And STL is by far less "standard" than the name suggests: it's different for basically all compilers and even across compiler versions.

A prime example of horrible porting with respect to STL is Microsoft's Visual C compiler. They have completely changed their STL in every second compiler version; and the next version requires changes again (because they pollute it with TR1 crap that really shouldn't be there!). GCC is a lot easier to handle. We are also preparing support for OpenSolaris with the stlport4 STL implementation - that is yet another major new implementation. And because of CINT's complexity it's not just "copy and paste" of the vector, list, etc headers...

So, keep your fingers crossed that we get it right, for most platforms, so you can happily use ROOT v5.24 for the next years on your new laptop! And please don't ask why ROOT v4.04 does not compile with GCC 4.4... ;-)

Good night, Axel.

v5.18

Submitted by Nick Hastings (not verified) on Wed, 28/10/2009 - 09:18.
Well, maybe not root v4.04, but I have a patch to get v5.18 to compile with gcc 4.3. I didn't actually bother to fix any of the warnings, just added a whole bunch of standard headers. Let me know if anyone wants it.

False argument on C++? :-)

Submitted by Anonymous on Tue, 08/09/2009 - 21:04.
Axel! Nice to see you writing!! BTW - how do I sign this comment that it is me (Gordon)? It doesn't look like your blogging engine gives me that oportunity? Further, how do I get notified that someone else (like you) answered the comment so I know to come back and write some more? Do I have to keep coming back to check the page? Also, why can't I just type text and have it come out ok? It looks like it runs everything together? First of all, all the major experiments are in the middle of the 4.3 transition right now. ATLAS has a functional build that is undergoing verification and I suspect that will be done by the end of the year. So expect this ROOT to be required running in the experiments for the release right after first data (if we are lucky enough to get real data before March or April). I suspect that 4.4 won't be far behind. Second, this move to C++ is a bit of a false argument. What the experiments have done is move all their production software to C++ - that choice was rather deliberate. If the data file format had been language agnostic, then I doubt we'd see the same C++ dominance at the analysis end of things. For example, by putting a thin wrapper around the ROOT utilities suddenly people are writing full blown analysis in ROOT. The key is as usual: what is the least amount of work (except when it comes to crazy people like me or the ones that wrote the java stuff). The "least amount of work" has to factor in everything, from MVA tools to I/O. BTW - I don't know if I've mentioned it lately, but ROOT I/O causes me no end of headaches. :-)

Re: False argument on C++? :-)

Submitted by axel on Wed, 09/09/2009 - 15:07.

Hi Gordon!

Thanks for your comment! You can simply put a "Cheers, Gordon" below your posting and I'll recognize you ;-) There is aggregation on the post level, but as far as I can tell not on the comment level. So yes - I don't see that drupal is able to notify anonymous users of new comments. What y6ou're typing is HTML, by the way, that's why it runs things together. But you can also enable the WYSIWYG editor ("Switch to rich text editor").

Of course a C++ centric data format will favor C++ as analysis language. But it's not just that: C++ is fast. It's standard - you can share code. And the reco frameworks are C++, too, which enables you to move analysis code back into the framework. This is what people did at D0, so it's not just a theoretical advantage. Some LHC experiment(s), on the other hand, now have to use interpreters in the event loop, because their analysis code was written in the wrong language.

Cheers, Axel.

so, why not java?

Submitted by Anonymous on Thu, 09/07/2009 - 05:40.
No need to be disappointed - You can read ROOT files using Java jHepWork project
http://jwork.org/jhepwork/
It works on any platform and without compilers. Plus it has build-in Java reflection (missing in C++) and perfect Java multi-thread support. cheers, Sergei

Re: so why not java?

Submitted by axel on Thu, 16/07/2009 - 08:48.

Hi Sergei!

Thanks for your comment!

The main advantage of Java in this respect is Sun (err Oracle). If C++ would be like Java with only one vendor defining what "true C++" is then we would probably also not see any differences in C++ implementations.

Concerning your subject "why not Java": that's not up to us to decide. The experiments flocked to C++. We can like or dislike it, but it's a reality that we have to deal with. And I believe we (HEP) show that we can deal with it :-)

Talking about C++: I'll talk about a "big" CERN visit and how we prepare for it in my next post...

Cheers, Axel.

Compilers

Submitted by Anonymous on Thu, 13/08/2009 - 16:23.
Hi, Alex I'm almost agree with you. There is only one thing: even with a single C++ vendor, widget graphics has to be portable between different systems of different vendors (KDE, gnome, Mac, windows etc). And this is where C++ weakness comes. How this can be controlled by a single hypothetical C++ vendor? Another thought: Java appears more popular language than C++ (almost factor of 2!): See article: http://veerasundar.com/blog/2009/07/job-trends-for-the-popular-languages... Remember: this was one of the reasons why we have moved from Fortran cheers, SC.

Re: Compilers

Submitted by axel on Mon, 17/08/2009 - 17:26.

Hi SC,

thanks for your comment! Yes, Java managed to create a platform independent graphics library, so why wouldn't that be possible for C++? O yes, there is Qt and ROOT ;-) But I agree with you that (luckily!) this cannot be controlled by one vendor; I was talking about a hypothetical world where C++ had only one main vendor. I believe if that was the case we would have one common graphics library, just like for Java.

There are many reports / measurements claiming that Java is more popular in general. Remember that the move the C++ was decided a while back - maybe that's the reason why C++ was chosen and not Java? To me, C++ is a given; if you and I decided to code in Java from now on, I fear our work would be irrelevant, because all the experiments are using C++.

Cheers, Axel.

Java controlled by 1 'vendor'!? Debian vs Ubuntu GCC!?

Submitted by Anonymous on Sat, 19/09/2009 - 05:11.
Hi, I think with the advent of OpenJDK the control of Java is out of Oracle's hands. But, even if it is, the nice thing about Java is that it is very well specified - the whole platform I mean - not like .Net. And given the various non-Sun/Oracle implementations of 'Java' and the fact that they interoperate I think that the point is moot. In this particular case, one overseer is a Good Thing(tm). Second point - Ubuntu and Debian GCC will _never_ (ok that's strong - very unlikely ever) differ. Fedore/RedHat however are infamous for `porting' features into GCC (sigh! - anyone remember the notorious GCC '2.96' from RH?). Oh, and Debian is moving to GCC 4.4 as we speak. Yours, Christian (If you can't guess which, then count the number of times it says 'Debian' above :-)

Re: Java controlled by 1 'vendor'!? Debian vs Ubuntu GCC!?

Submitted by axel on Mon, 21/09/2009 - 11:29.

Hi Christian-I-know-who-you-are! :-)

Thanks for your comments! My Ubuntu 9.04 tells me: gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3. And looking at info gcc one can find statements like

"NOTE: In Ubuntu 8.10 and later versions this option is enabled by
default for C, C++, ObjC, ObjC++.  To disable, use `-Wformat=0'."

Concerning Java I have an example: installing anything but the "original" Sun plugin for Firefox will break the Java applets / objects / whatever on many web pages - be it because alternatives don't work as well, or because Sun's Java uses non-standard extension. A skål to compatibility... And even if the alternative implementations would implement the same: I'd argue that their market share alone justifies the statement that Sun / Oracle controls Java.

Cheers, Axel