>>Fortran is essentially in maintenance mode on VMS -- at F77 on VAX and
>>at F95 on Alpha.
> The Fortran90 standard came out in 1991 or something, and ALPHA in in
> 1992 or whatever. There was a decision made not to develop a Fortran90
> compiler for the VAX. I think this was a correct decision. There are
> two types of Fortran people, those who do cutting-edge number crunching
> and those running old, well tested code. The former will of course use
> the newest hardware and compiler techniques, so obviously Fortran90 and
> ALPHA were a good match. No serious number cruncher would use VAX when
> ALPHA is available, so these guys don't care about Fortran90 on VAX.
> Folks with old code running a VAX at VMS 5.5-2 obviously don't want to
> risk changing anything, so these guys wouldn't be interested in
> Fortran90 for VAX either.
Yes, I can agree with your judgement on no F95 for VAX, but if the
compiler is common and only the GEM backend different, why does it
matter? We are probably in the area of what you call "cutting-edge
number crunching". I have a 4-CPU ES40 for our production work which
runs at about 400% most days of the month. Our engineers do very large
dynamic analyses of our 4-state interconnected system where they
represent all the generator control systems and induction motors and
non-linear loads in detail.
Another use is for similarly large Monte Carlo runs to optimise use of
power producing resources.
We quickly backed off VAXes when Alpha came on the scene.
Quote:> It looks like Fortran2000 will actually appear only in 2005 or so,
> probably AFTER Itanium systems which are faster than the fastest ALPHAs
> become available.
Oh, Oh. This is a problem area. From many threads here (and I am only
on the mailing list), Alpha has been held back in capacity and Itanium
has not yet been proven in speed, etc.
As I said, which you quote below, our organisation is unlikely to allow
us any more VMS boxes. We still want to be able to improve our
performance using updated compilers even to the F95 standard. There is
still much scope in the compilers to match the easier to read
vector?matrix operations with old-fashioned DO loops. COMPLEX MATMUL,
for example, is a horrendous slug.
Quote:> So here the corresponding argument against having a
> new Fortran standard on older hardware is even stronger.
Why even stronger? The compiler code is still being developed at Intel
from our beloved folk like Steve Lionel and fellow team members for CVF.
It is the GEM back-end that translates the compiler into optimised
Regardless of when the new standard comes out (you hypothesise 2005), it
may or may not beat Itanium. Regardless, TRs are currently being issued
which vendors are incorporating into their F95+ compilers. An example
that would be pertinent to one of our applications is dynamic allocation
of arrays in structures/types. A colleague wrote into this application
this array of pointers thing to simulate this and the code is hard to
maintain. (We do not like any use of pointers in our Fortran codes).
I am not interested in the full wealth of F2K, just some of the
"trivial" aspects. But I expect enhancements in vector/array handling.
I still maintain loops which are harder to read because the compiler
generates code many times slower for vector/array operations. I assess
my bottleneck routines using PCA (also not too brilliant on Alpha).
I would also love to get compiler cross-referencing back; SCA is not
always a panacea.
Quote:> Add to that
> the fact that the lack of marketing etc has meant that academia---in the
> past a source of number crunchers using Fortran on DEC hardware---has
> largely left DEC and the argument becomes even stronger.
True (are you John Smith in disguise with this marketing pitch :-).
However, for people who have bought CVF licences, there is an upgrade
without money going back to the vendor -- as with all our licences on
VMS, but we do pay software maintenance.
>>Since our organisation has eschewed VMS (Gartner followers, and lack of
>>software), if/when the IA64 thingy (copyright J-F) comes into being we
>>shall not be able to downgrade ourselves. This means that we shall be
>>using our Alphas for as long as possible and as far as Fortran is
>>concerned we shall be stuck in maintenance mode. TRs are coming out for
>>some of the F2K stuff, yet we shall never be able to use it. I would
>>think that full F2K compilers will be out before the IA64 thingy, yet we
>>shall still be on the F95 standard Alpha compiler.
> I would have thought so too, until recently, but it looks like F2K will
> be a BIG change, even bigger than F77--F90!
Yes, and as with much of F90, I have little use for many of the changes.
I have no desire to totally rewrite proven code, but when I am doing
maintenance or a new feature, I am quite happy to use new notation since
it is more readable, but only IF IT DOES NOT DENIGRATE PERFORMANCE IN A
Secondary comment: Why did CXML go to Intel when they already have their
own optimised BLA and LAPACK routines for their architecture?
"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above. If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender. You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.
If you have received the email in error, please notify TransGrid
immediately. Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid. TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.
Please note the email address for TransGrid personnel is now