RE: Why I am forced to abandon Root

From: Fine, Valeri <fine_at_bnl.gov>
Date: Thu, 3 Sep 2009 20:07:28 -0400

Hi Tom,
I think your issue has nothing to do with ROOT.

You problem comes from  

   Tom > LACK OF MODULARITY

and the reason for that is

   Tom > the simple reason that the supercomputer    Tom > does not support shared objects

The "shared libs" is the mechanism to achieve the modularity especially with with C++.

If your system does not support it, you have to provide some sort of layer to "fix" your system.

ROOT relies on the abstract interface implementations those it can load "on fly". As result, the concrete real application builds itself at RUN-TIME. This is where the real modularity comes from.

Best Regards

                         Valeri Fine

---

Brookhaven National Laboratory
Upton, NY 11973, USA
Phone: +1 631 344 7806
Fax: +1 631 344 4206
E-mail: fine_at_bnl.gov

> -----Original Message-----
> From: owner-roottalk_at_root.cern.ch [mailto:owner-roottalk_at_root.cern.ch]
On
> Behalf Of Tom Roberts
> Sent: Thursday, September 03, 2009 3:00 PM
> To: 'ROOT Talk'
> Subject: [ROOT] Why I am forced to abandon Root
>
> I have been using Root for 3-4 years, and have been reasonably happy
> with it. But I have long been frustrated with build issues, that have
> now culminated in my complete inability to build Root on a
supercomputer
> at NERSC. The underlying problem is:
>
> LACK OF MODULARITY
>
> Note that the only Root classes that my code uses are: TNtuple, TFile,
> TDirectory, and the only Root functionality is to read and write
> TNtuple-s to and from TFile-s.
>
> Performing such basic Root I/O brings in an INCREDIBLE amount of Root
> code. I understand that the desire to read arbitrary objects from Root
> files beings in Cint and related dictionary code; I could live with
> that. But this also brings in the image libraries and X-Windows -- I
> CANNOT live with that, for the simple reason that the supercomputer
does
> not support shared objects or X-windows on its compute nodes.
>
> At base, this is caused by the fact that TObject::Draw() exists, and
is
> implemented for TFile, TDirectory, and TNtuple. I understand the
reasons
> for that, but this design is preventing me from compiling Root because
> it inherently brings in the image and X-Windows code.
>
> So I am forced to use a file format other than Root. I could use ASCII
> files, but for large problems that is inefficient. I am considering
both
> SDDS and HDF5. Suggestions?
>
> Another possibility would be to make Root usable for such
applications.
> I believe this could be done with only modest effort:
> A) re-factoring TFile, TDirectory, TNtuple, etc. so they each have
> an "IO-Only" base class that has an empty Draw(); the
> current class derives from this new base class and implements
> Draw(). There might be other functions from TObject that need
> such treatment, and there might be other classes that would
> benefit from such re-factoring (e.g. TH*, ...); the idea is to
> avoid bringing in functionality unrelated to I/O, and most
> especially other libraries -- IMHO success would be if the
> IO-Only build of Root requires no external libraries other
> than system libs.
> A') Instead of that re-factoring, just use a "#ifdef IOOnly"
> to implement a dummy Draw() (etc.) in appropriate classes;
> use the build system to omit all non-I/O stuff.
> B) extending the build system so an "IO-Only" version could be
> built on a system without image libraries or X-Windows.
> C) Documenting and testing the above.
>
> In closing, I'll point out that in casual conversations at Fermilab I
> have been told by several people "don't use Root" (in a
computationally
> intensive context), for just this reason. Perhaps it is in the
interest
> of the general Root community to solve this problem. A complete
> re-organization is clearly neither possible nor desirable, but the
> ability to build and link root for JUST I/O would be most welcome. The
> existence of the non-Root "RIO" package indicates I am not alone in
this.
>
>
> Tom Roberts
Received on Fri Sep 04 2009 - 02:07:53 CEST