A multi socket rack server with 24 cores costs peanuts these days. Probably less than the effort of porting R with the cost of the fortran license. And those parallel processing algorithms would probably run better on a NUMA architecture anyway. Horses for courses.
On 22/01/2013, at 9:55 PM, Ze'ev Atlas <[email protected]> wrote: > The VS/Fortran (compiler and library) is indeed stuck in Fortran 77 and there > seems to be no XL/Fortran for z/OS or even z/Linux. It might be a > quasi-interesting excercise compiling all the Fortran modules in the R source > code in VS/Fortran (I suspect that most if not all will compile alright) but > it probably won't be as efficient as it could be. > One of the main selling points of R is the fact that it is a 'functional' > language with provisions for parallel processing (i.e. utilizing multi-core > CPU - se http://cran.r-project.org/web/views/HighPerformanceComputing.html). > Again, it could be interesting to see how that is working in the context of > z/OS. But I am not sure it is interesting enough. > > Ze'ev Atlas > > > > ________________________________ > From: David Crayford <[email protected]> > To: [email protected] > Sent: Tuesday, January 22, 2013 6:43 AM > Subject: Re: R statistical language. > > On 22/01/2013 11:36 AM, Ze'ev Atlas wrote: >> Well >> I was not aware about that fact, so I downloaded the source code and indeed >> it uses Fortran - interesting, I may spend some time with that stuff. >> However, both IBM and GNU provide pretty advanced Fortran compilers, but it >> becomes more and more hairy to deal with it. Yet, if there is a demand, >> somebody would probably do that. And interfacing native z/OS files and SMF >> in particular should not be that hard. > > >> Last time I heard Fortran was gathering dust in the IBM Perth lab. It's >> probably been functionally stabalized and is >withering on the vine being >> supported for the handful of customers that actually use it. >> GNU compilers are a different story. They are cheap (free), high quality and >> have be ported to most platforms. Don't hold >your breath for a full >> function GCC port to z/OS anytime soon. Porting glibc would take a herculean >> effort. It's >> been tried before by very capable people, most of them bailed. > > I like Kirks solution of piping the data onto cheaper, better suited > platforms for CPU intensive numerical workloads. Even the low-end x86 servers > have SIMD vector execution units making them perfectly suited to crunching > stats. > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
