SCIENTIFIC-LINUX-DEVEL Archives

May 2008

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andy Buckley <[log in to unmask]>
Reply To:
Andy Buckley <[log in to unmask]>
Date:
Thu, 8 May 2008 13:38:46 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (57 lines)
Matthias Schroeder wrote:
> Andy Buckley wrote:

>> But simultaneously, the single supported target platform has led to
>> non-portable experiment software and LCG middleware. My experience is
>> that *having* to ensure portability results in better code,
> 
> I completely agree on that one.
> 
>> and easier
>> portability between major releases of SL, but the enforced SL domination
>> means that this often isn't done.
> 
> Unfortunately true. But who has the resources to provide
> 
> - sufficient capacity to run enough jobs to certify other OSes,
>   compilers, libs,...

I know nothing about the certification procedure: is the intention to
test the numerical correctness of the whole system, to ensure that HEP code
compiles and runs, or to ensure hardware/support compatibility? Would you
expect numerical problems with OSes other than SL(C)? My *personal* experience
is that bugs are *much* more likely to be physicist error (myself included)
than a problem with the underlying system.

> - enough manpower to make the HEP code portable
> - enough manpower to run and analyze the test jobs

The portability problems are located at certain bottlenecks rather than
all through the code: build systems and frameworks have to interact with
the system, but most reconstruction/simulation/etc. code is only
concerned with framework objects (i.e. if reconstruction code is trying to
write directly to filesystem paths, it *is* a bug).

I bet if half the available batch CPU was on LCG-incompatible Linux distros,
manpower would miraculously appear to provide compatibility with it...

> The current mono-culture is a danger for the code quality, but I see no
> way out :(
>
>> So I (tacitly, but actively) welcome Ubuntu (and everything else*)
>> creep, in the hope that it might lead to better software!
> 
> You are optimistic.

I would view the non-portability of experiment software as a
largely-unconsidered source of error and uncertainty in LHC simulation and data
handling... surely that's pretty pessimistic! But yes, I'm idealistic.

"Reasonable people adapt themselves to the world. Unreasonable people attempt
to adapt the world to themselves. All progress, therefore, depends on
unreasonable people" - George Bernard Shaw

;)

Andy

ATOM RSS1 RSS2