1 / 82

20-30 years of Computing in HEP

20-30 years of Computing in HEP. I nternational W orkshop on L arge S cale C omputing Kolkata 8 February 2006 Ren é Brun CERN. Hardware & Software Evolution. Looking several years back to understand how HEP software has been shaped. Punched cards.

raymond-rice
Download Presentation

20-30 years of Computing in HEP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 20-30 years of Computing in HEP International Workshop on Large Scale Computing Kolkata 8 February 2006 René Brun CERN

  2. Hardware & Software Evolution Looking several years back to understand how HEP software has been shaped

  3. Punched cards Program size limited by the size of the box and memory (32 Kb) 1973 2000 cards per box 200000 cards in all racks geant1 hbook 1500000 lines in ROOT !! 750 boxes Kolkata IWLSC workshop

  4. Mainframes, workstations,.. High level packages Graphics Mainframes Workstations 1982 HTV 1980 geant3 1986 Kolkata IWLSC workshop

  5. , OS, Desktops & Laptops CDC SCOPE IBM/OS/Wylbur CRAY VAX/VMS Apollo Aegys Unix workstations Windows Linux MacOSX Kolkata IWLSC workshop

  6. Farms & GRID(s) PROOF Kolkata IWLSC workshop

  7. The 3 technology laws • Moore's Law: formulated by Gordon Moore of Intel in the early 70's - the processing power of a microchip doubles every 18 months; corollary, computers become faster and the price of a given level of computing power halves every 18 months. (well ! Not true anymore, see later) • Gilder's Law: proposed by George Gilder, prolific author and prophet of the new technology age - the total bandwidth of communication systems triples every twelve months. New developments seem to confirm that bandwidth availability will continue to expand at a rate that supports Gilder's Law. • Metcalfe's Law: attributed to Robert Metcalfe, originator of Ethernet and founder of 3COM: the value of a network is proportional to the square of the number of nodes; so, as a network grows, the value of being connected to it grows exponentially, while the cost per user remains the same or even reduces. • But no laws about Software (well ! Murphy’s law) Kolkata IWLSC workshop

  8. Hardware & Compilers Relative units Kolkata IWLSC workshop

  9. Multi Core CPUs http://www.intel.com/technology/computing/archinnov/platform2015/ Kolkata IWLSC workshop

  10. Program Size (lines of code) MS Windows Public Libraries Experiment Code base One user Kolkata IWLSC workshop

  11. Program Size (RAM) ? Kolkata IWLSC workshop

  12. Time to compile ADA F77/90 C++ C Kolkata IWLSC workshop

  13. Files, Classes Becoming a problem. Need tools to manage dependencies The same curve can be used to show the number of people in one large experiment Kolkata IWLSC workshop

  14. Languages Business Cobol Machine code AI languages Lisp, Prolog Algorithmic Languages Formula Translation SQL C Pascal ADA Modula 2 Objective C C++ Java Eiffel Kolkata IWLSC workshop

  15. Fortran to C++ C++ complexity Java Fortran + zebra fortran power Kolkata IWLSC workshop

  16. From static modules to plug-ins • app.exe = (main.o) 1955 • app.exe = (main.o, x.o, y.o) 1965 • app.exe = (main.o, x.o, lib1.a, lib2.a) 1975 • app.exe = (main.o, x.o, lib1.a, lib2.so, lib3.so) 1985 • app.exe = (main.o, libs.so) + dyn libs.so 1995 • app.exe = (main.o,libs.so) + plug-in manager 2005 • BOOT + URLs + local caches (interp + comp) 2015 ?? • See my talk at CHEP Kolkata IWLSC workshop

  17. Current ROOT structure & libs Kolkata IWLSC workshop

  18. h.Draw() local mode CINT libX11 ------- … drawline drawtext … libCore ------- … I/O TSystem … libGpad ------- … TPad TFrame … pm pm (Plug-in Manager) pm libGraf ------- … TGraph TGaxis TPave … libHist ------- … TH1 TH2 … libHistPainter ------- … THistPainter TPainter3DAlgorithms … pm pm Kolkata IWLSC workshop

  19. Compiled + interpreted code • 1980: zcedex, mini command interpreter • 1985: kuip/paw, command and macro interp • 1986: Tk/Tcl includes a GUI • 1984: comis, Fortran77 interpreter • 1994: cint, a C & C++ interpreter • 1998: python, OO on top of C++, Java • 2002: ruby, better than python? • 200x: BOOT (inter->code generation->compiler) Kolkata IWLSC workshop

  20. Basic types and modules • 1950: basic operators (trig functions part of the application) • 1953: trig functions in a library • 1954: fortran types (integer, real, hollerith). Subroutines communication only via arguments. • 1965: subroutines communicate via a blank common, then labeled common blocks. • 1975: communication via a data structure management system • 1980: derived types • 1988: Object-Oriented programming: classes • 1995: parametrized types, templates, STL • 1996: Reflexion/RTTI (Java) Kolkata IWLSC workshop

  21. Programing models • Procedural sequential • Parallelism (MPI) • Vectorisation • Shared memory • Multi-threading • Client-server • Statefull • Stateless ->web • Corba • Distributed parallel computing (asynchronous) • Messages. Signal/slots Kolkata IWLSC workshop

  22. Problems with Fortran • Abuse of common blocks. • Unmanageable in large programs • No data structures • No generic machine independent I/O • Systems like Hydra(1974), Zbook(1975),Bos(1977),Zebra(1983) designed to overcome these problems. But most people loved it Kolkata IWLSC workshop

  23. The Zebra system (1983) • Zebra = Zbook + Hydra • Main data structure management system used by PAW and Geant3 and also many collaborations. • Powerful machine independent I/O • FZ: sequential • RZ: direct access (PAW ntuples) • Nice Data structure documentation system, including an interactive browser DZDOC. Kolkata IWLSC workshop

  24. Zebra bank descriptor Zebra style iq(lvx+vtype)= type q(lvx+vdz) = dz ltk = lq(lvx-1) I/O descriptor C/C++ style Vertex* vx; vx.vtype = type; vx.vdz = dz; Track* tk = vx.tk; Kolkata IWLSC workshop

  25. Zebra DZDOC call fzout(lun,lhdir,..) lhdir Zebra I/O could support very complex data structures A Zebra bank similar to a C++ data object Kolkata IWLSC workshop

  26. Atlas DZDOC Kolkata IWLSC workshop

  27. Zebra pros/cons • Programming style archaic • Easy to overwrite data structures • Shared global store(s) • Shared global store(s) • Self-describing structures • Concept of multi-heap (constants, histograms, event,..) • Efficient garbage collection (division wipe) • Built-in efficient and machine independent I/O • Used by Geant3,PAW and many experiments Kolkata IWLSC workshop

  28. Geant 1,2,3,……..4 • Geant1 1974 • 2000 lines of Fortran 4 • No physics, no geometry, only a bare framework • Geant2 1975 • 20000 lines of Fortran 4 • Some physics for multiple scattering, energy loss, decays, framework for geometry and tracking • Geant3 1980,81 1994 ------2006? • About 120000 lines of Fortran77 + zebra + paw • Electromagnetic physics • 4 hadronic packages (Tatina, Gheisha, Fluka, Calor) • Powerful geometry package including graphics • Hits/Digits framework • I/O subsystem (zebra) for all structures including geometry. • Used by many experiments. Still a reference!!! Kolkata IWLSC workshop

  29. Fluka  Fluka • Originally developed by safety protection group at CERN (stevenson) + aarnio + ranft) 1985 ? • Reengineered by A.Ferrari &co: Rubbia project 1990 • Probably the best for Physics processes • Simple geometry • The reference for radiation/shielding • Written in fortran77 • Interfaced with VMC (TFluka) and G4 (Flugg) Kolkata IWLSC workshop

  30. Geant4 • Started in 1994 • Originally a flagship project for the move to C++ • A huge investment in manpower • About 600000 lines of C++ • Validation process in Atlas, CMS and LHCb • Physics processes getting better and better • But still many limitations • Poor interpreter (small subset callable from python) • No I/O interface (geometry cannot yet be made persistent) • Batch style graphics Kolkata IWLSC workshop

  31. G3 G3 transport User Code VMC G4 G4 transport FLUKA transport FLUKA Reconstruction Geometrical Modeller Visualisation Generators The Virtual MC (1998) Kolkata IWLSC workshop

  32. Virtual Monte Carlo and ROOT Geometry • The ROOT geometry package (TGeo) can be used in detector simulation, reconstruction, graphics, etc. • TGeant3 • Used in production – native GEANT3 • New: TGeant3TGeo – interface to G3 using TGeo geometry • No modification required in the user code • Validated by Alice • Same speed or faster than TGeant3 • TGeant4 • Used for Geant4 physics validation – G4 native geometry built after g3tog4 conversion • No interface yet between G4 and ROOT geometry • But Andrei Gheata actively working on it (expected this spring) • TFluka • Old geometry interface using G4 geometry vis FLUGG • Currently a fully validated geometry interface based on TGeo • Validated by the Fluka team • At least 2 times slower than TGeant3 • The VMC framework is currently used by Alice, Opera, Minos, NA48b,Hades, CBM and may be STAR. Kolkata IWLSC workshop

  33. PAW: a long saga • First version (Jan 1985) by a committee • Must use GKS • GUI based on VT100 functionality • No ntuples • June 1985: developers “abolish” the committee • Higz: GKS + X11 • Row wise ntuples, then ColumnWiseNtuples (1986) • Frozen in 1994, but still maintained by ROOT team Kolkata IWLSC workshop

  34. Crisis: 1992 1999 Move to F90? Attempts to use OODBMS and commercial software

  35. Why not F90 after F77? • In 1989,90,91 assumption was F90 • Some work invested in I/O with F90 (to support derived types). We could not solve this problem, because no formal way to parse the F90 module descriptors. • In 1992 many forces pushing towards OO • CHEP Annecy, web, Next • Crisis in Dec 1992 (at least in IT software group) • 1/3 in favour of f90 • 1/3 in favour of commercial solutions • 1/3 in favour of C++ Kolkata IWLSC workshop

  36. 1993,1994,1995 • ZOO, NextPaw, Geant3.5 proposals rejected • ZOO: Zebra in the OO world • NextPaw: Paw evolution ->C->C++ • Geant3.5: Implement geometry package in C++ • Geant4 proposal (June 1994) • RD45/Objectivity project (fall 1994) • ROOT project starts (in NA49) (Jan 1995) X 1994 CERNLIB PAW GEANT3 Objectivity ROOT LHC++ GEANT4 Oracle LCG 2006 COOL Kolkata IWLSC workshop

  37. 1996 • ROOT chooses the CINT interpreter • We had been attracted by Java (Object base class, many common ideas). • Work on object persistency based on the dictionary information (introspection). • Design of ROOT Trees (split mode). Comparison with Objectivity • LHC++ project starts (against ROOT) • see Jamie’s talk Kolkata IWLSC workshop

  38. 1997->2000 • Getting experience with OO (professional developers). • Most users lost in f77->C++ • First signs of problems with Objectivity in Babar • FNAL RUN II chooses ROOT • But C++ seen as a temporary solution waiting for efficient Java at the horizon 2003. • ROOT : automatic I/O based on dictionary, automatic schema evolution. Kolkata IWLSC workshop

  39. Problems with commercial systems • Licensing • Deployment • Vendor is late to follow with compilers & OS • Difficult to request new functionality • Difficult to get good people to do support and maintenance. Programmers want to develop code. Kolkata IWLSC workshop

  40. Data Analysis Software • 1960: Do it yourself • 1968: SUMX • Histograms and data blocks described in input file. SUMX is the master. • 1973: HBOOK • Histogram library. User controls the event loop and the selection. • 1985: PAW • Interactive histograms/fitting. Ntuples • 1995: ROOT • Same as PAW + persistency for C++ objects. C++ interpreter • 2005: PROOF and GRID • Distributed analysis: client->Master->Workers (parallelism) Kolkata IWLSC workshop

  41. PAW Simple adhoc interpreter KUIP paw > set col 2 paw > hi/plot 1 paw > set col 4 paw > hi/plot 2 same paw > ntuple/plot 100 px:py px*px+py*py>1 Kolkata IWLSC workshop

  42. ROOT C++ interpreter CINT root > h1.SetLineColor(2) root > h2.SetLineColor(4) root > h1.Draw() root > h2.Draw(“same”) root > t.Draw(“px:py”,”px*px+py*py>1”) root > myobject.DoSomething(…) Kolkata IWLSC workshop

  43. Graphics & GUI evolution • Plotters (eg GD3): Calcomp • GKS times: screen is the memory • PHIGS • X11, GL: the winners • From graphics attributes set in sequence to Objects • With PAW: • set color red • Now all primitives are red • With ROOT: attribute values do not depend on the order they are set => easier to write a graphics editor • From Callbacks Messages->Signal&Slots • Signal&Slots require an interpreter (see Qt and Root) • Scriptable GUIs (a MUST) Kolkata IWLSC workshop

  44. Graphics and GUI systems • Calcomp plotters 1955 • First graphics packages (CERN GD3 1970) • HPLOT 1975…… • HPLOT -> HIGZ  GD3 1978 • HPLOT -> HIGZ US Core system (fnal) 1981 • HPLOT -> HIGZ GKS 1983 • HPLOT -> HIGZ  PHIGS 1985 • HPLOT -> HIGZ  X11 1985 • PAW ->VT100, GKS, 1985 • PAW ->MOTIF 1991 • ROOT -> X11 1995 • ROOT ->Win32 1996, 2002 • ROOT ->Qt 2002, 2006 • ROOT -> GL 2002 Kolkata IWLSC workshop

  45. Graphics and GUI systems (cont) • Most graphics/GUI systems that we have used have been based on International standards or de facto standards. • All these systems had a limited life time • The CORE system : 5 years • GKS : 10 years • PHIGS : < 10 years • X11 : > 20 years • MOTIF : < 8 years • Qt : ?? • So far, no applications built directly on top of these systems were portable to the next generation. A new generation every 8, 10 years Kolkata IWLSC workshop

  46. from plotters to objects All items are clickable objects Kolkata IWLSC workshop

  47. Can take advantage of graphics accelerators Kolkata IWLSC workshop

  48. Extremely important The ROOT GUI Is fully scriptable Kolkata IWLSC workshop

  49. ROOT GUI/graphics interoperability ROOT GUI and Graphics embedded in a WindowsMFC application The ROOT GUI events can be passed to the MFC application event loop. A ROOT canvas can be embedded in a MFC canvas Kolkata IWLSC workshop

  50. ROOT GUI/graphics interoperability ROOT GUI and Graphics embedded in a Qt application The ROOT GUI events can be passed to the Qt application event loop. A ROOT canvas can be embedded in a Qt canvas Qt browser Drag & Drop objects in the ROOT canvas One can use ROOT context menus Kolkata IWLSC workshop

More Related