Re: [Math-atlas-devel] packaging ATLAS and gcc 4
Brought to you by:
rwhaley,
tonyc040457
From: M. E. (E. B. <zn...@ce...> - 2005-08-20 20:32:29
|
R Clint Whaley wrote: >Now, to respond to some of Ed's points: I agree that the clear trend is >to higher and higher levels in numerical work. My guess is most work >is done in PSEs, some work in high-level language (python) and some >in C++/C/f90/f77. All of these higher level packages really want .so/.dll, >and so this is something I want to add to the default ATLAS build, >but it'll take quite a bit of work to ensure we don't use any >(unnecessary) performance. > You might want to have a look at the way Gentoo builds and installs Atlas. I can dig up the name of the Gentoo developer who did it. In any event, Gentoo installs blas-atlas and lapack-atlas as shared libraries from the native source!! As to "scripting languages" being used for numerical work, they invariably depend on underlying C/C++ or Fortran code, either linked in statically or loaded dynamically in either a native OS form or a scripting-language dependent form. Perl has the Perl Data Language, which is probably best known in astronomical image processing. There are a couple of packages for Python, a language I'm not at all using now or planning to use. And there are similar packages for Ruby. I don't know about PHP; it's another language I don't know and don't plan to learn. In a very real sense, the "standard" numerical processing languages -- Matlab, Octave, SciLab and R are the names I know -- are also scripting languages, but they had excellent scientific computing built in out of the box, and the other "stuff" -- regular expressions, HTML output, XML parsing, etc. -- were added on later as needed. They're the inverse of Perl, Python and Ruby, which were designed to be excellent at the other stuff and had numerical processing added later as needed. :) >On the F77/C, I can't argue as I write all my F77-specific libs in C! >However, as a compiler writer, I can tell you that F77 code (due to >aliasing rules enforced by the F77 standard) is clearly >more optimizable than C. > Well ... I'm not a compiler writer but I hung out with the ones at FPS, who later became The Portland Group. They said essentially the same thing. Convex proved them wrong and outlasted FPS in the minisupercomputer market by a couple of years as a result. As long as you're willing to massage your C to make it optimizable -- and in those days, Fortran programmers were ready, willing and able to do so; it was part of the job description! -- there's no reason to lose any performance on numerical code in C. Nobody expected a C compiler to vectorize a Lisp interpreter, but they did expect it to optimize the Level 1, 2 and 3 BLAS, the Livermore Kernels, matrix multiply and FFTs. |