[Beowulf] cernlib
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Robert G. Brown rgb at phy.duke.eduFri Oct 14 11:11:39 PDT 2005
- Previous message: [Beowulf] cernlib
- Next message: [Beowulf] cernlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 14 Oct 2005, Mikhail Kuzminsky wrote: > But what is today free fortran source alternative to Cernlib for "universal" > numerical library ? I don't know about "universal", but the Gnu Scientific Library (GSL) is precisely what it appears to be -- a fairly complete and well implemented numerical library that is being actively developed and maintained and that has a large and active user base. It also BUILDS into an rpm quite nicely, almost a priori (RH has provided limited development resources almost from the beginning). It builds on a lot of platforms other than just linux or any single architecture as well, though. It also is readily available -- in many cases and for many distros it is a yum install gsl\* away, and is extremely well documented and easy to use. It has the significant advantage that a) it uses modern algorithms -- while it has nearly every RNG under the sun inside its universal RNG harness, its default RNGs are diehard-proofed and efficient; b) it links to BLAS externally, so you can drop in ATLAS-tuned BLAS at the link stage if you have it for your architecture. Since ATLAS BLAS is worth as much as what, 2-3x in performance on linear algebra-intensive code, this alone makes using it worthwhile. So another way to rewrite cernlib would be to go in and quickly dump all the numerical functions that are redundant with stuff provided (and likely provided better and more reliably) in the GSL. I haven't looked, but I imagine that there goes a goodly chunk of the code base and complexity and (aaaahhhh) the GSL is all written in C so there goes a bunch of Evil Fortran and hard-to-pin-down stuff along the lines of the ongoing thread on the MPI ABI. GPL all the rest, and open the entire library up to people to help port the remainder to portable and standards-compliant C. While one is at it, work on porting/adding the few things still missing (in my opinion) from the GSL that should be there, notably non-Monte Carlo multidimensional integration using e.g. cubature (a thing I've worked a bit on adding). Oh, and while doing this, break the library up into a set of libraries with non-circular dependencies. Preferrably library pieces that can be interchanged or replaced without breaking applications that use them, should somebody want to rewrite them completely but preserve the ABI. The example of GSL using an external BLAS (or LAPACK) being a good example of the benefits. >> Thanks, that's very useful. >> Well, (with this) I now have source rpms for both 2002 and 2005. > > Some years ago I attempted to find Cernlib for Linux in Joint Institute > of Nuclear Research here in Russia (in Dubna). It was not simple task :-) As > a result I received Linux source, but source RPM is clear step forward ;-) > BTW, where is now available RPMS (you worote) ? Curiously, I found the only 2005 source rpm on a server in Russia. GIYF -- lessee, here it was (in the Scientific Linux RPM set, actually): ftp://ftp.linux-ink.ru/pub/SL/4.x/SRPMS/ But this is what I'm hacking on. It "might" build if you tried building it as root, but I've had some horrendous experiences rebuilding rpm's as root (certain bugs can literally trash your system as rpm goes around recursively chmod'ing this and that). These bugs aren't that great from userland either, but it is easier to recover when you get bitten. Then there are security issues. Overall, I like rpms to build very, very cleanly from userspace with topdir pointing whereever a user wishes and not just at /usr/src/redhat. If/when I actually get something like a clean rpm build on FC4, I'll certainly pop the resulting src rpm (if I can manage to reassemble it) onto my personal yum/rpm repository where you can grab it. > > :-) I have some plus: I have MVS 3.8 working under x86 Linux at my home ! It > works through Hercules emulator and includes Fortran IV (!) > compiler. (I worked w/mainfarmes about 20 years, so it's good for nostalgie > ;-)). So theoretically I can to try to compile some sources :-) Yours Fortran IV, eh? That's the last and nearly the only version of Fortran I actually worked with as well. Who needs the sissy 77 extensions, let alone the 90 extensions. And anybody who actually writes lines of code anywhere but between columns 6 and 72, well, they are just ignorant...;-) I used to keep a full box of cards in my office with the biggest thing I ever wrote (in Fortran) in it. Kind of a Juju. But I finally dumped it, and the 9 track tape I had lying around as well. I'm still kicking myself for dumping my ibm qic with mastermind written in APL on it though -- I've actually had people ask for the source and although I have no idea how I'd get it off of the media (and it's probably encoded in EBCDIC if I did) it would almost be worth the effort to try...;-) rgb > Mikhail Kuzminsky > Zelinsky Institute of Organic Chemistry > Moscow > >> ... >> rgb >> >> -- >> Robert G. Brown http://www.phy.duke.edu/~rgb/ >> Duke University Dept. of Physics, Box 90305 >> Durham, N.C. 27708-0305 >> Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu >> >> >> _______________________________________________ >> Beowulf mailing list, Beowulf at beowulf.org >> To change your subscription (digest mode or unsubscribe) visit >> http://www.beowulf.org/mailman/listinfo/beowulf > -- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
- Previous message: [Beowulf] cernlib
- Next message: [Beowulf] cernlib
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
