Re: VMS
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 11/21/03
- Next message: Tsolak Petrosian: "Re: SproutMethod.pdf"
- Previous message: H. S. Lahman: "Re: Inheritance and Polymorhpism (getting back to the point)"
- In reply to: Richard Dell: "Re: VMS"
- Next in thread: JXStern: "Re: VMS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 21 Nov 2003 18:01:19 GMT
Responding to Dell...
>>Not to mention networking that was rock-solid even by mainframe
>>standards. B-) My theory is that they provided the wrong software tools.
>
>
> My experience was that their 32 bit hardware never kept up with Sun, MIPS, etc.
> We were screaming for faster boxes, but when they finally arrived (as 64-bit
> Alphas), it was too late and required too much intervention to get your old code
> working. Great shame, great system, never crashed, beautiful CLI and brill
> Fortran debugger.
This is one of those issues that will never be resolved without hard
data. B-)
FWIW, I have always seen the speed issue as a red herring. RISC is
great for drhystones and whetstones, but it places the burden of
optimization for real applications on the compiler vendor. It typically
took a decade to get good optimization for a new language on CISC. I
suspect two decades is more like it for RISC. [Of course, once one has
done it for a language the basic techniques are reusable across
particular processor flavors within the family. I just didn't see much
evidence that they had gotten there for C by the late '90s in the RISC
world. So the VAXen should have been Good Enough.]
Also, as Sun found out painfully, bus speed and caching are more
important to IT than raw ALU speed. IT applications access acres of
data without doing a whole lot with it. So when running real IT-style
applications those WinTel boxes that seemed so cretinous on paper were
blowing the socks of the SPARCs and MIPS.
[Anecdotal data point. Where I worked before retiring ('00) we were
doing device drivers that had to run on Windows or UNIX. So our
hardware system would provide a WinTel box or SPARC card as the slot 0
controller. The driver was about 250 KNCLOC of identical C (later C++)
code for each system. The state of the art SPARC typically ran our
driver at about the same throughput as a pentium from two generations
previous for both the C and C++ versions. (Which was a major issue for
the bean counters because it made the UNIX-based system more expensive
for the same throughput.)
Though we were doing R-T/E it was very similar to IT because the basic
problem we faced was to move mountains of data from one pile (a
database) to another (our own hardware's registers) without doing a lot
to it on the way. [A single digital test burst typically has ~10**9
data elements and the program to test a single digital PCB will have
~1000 bursts. When one hauls the system up to test all the electronics
in a B2 bomber, data throughput becomes a major consideration so we did
a /lot/ of profiling. B-)]
Of course this doesn't prove anything because Sun might have just had a
lousy C compiler compared to MS'. OTOH, most of the comparisons I've
seen from that era for "real" applications reflected a similar
discrepancy. Whatever the reasons, I think it just underscores the
point that ALU speed is only one piece of the pie and one has to look at
the whole pie.]
BTW, the reason we dropped VAXen and Alpha, which we used until the late
'90s, in favor of WinTel had nothing to do with ALU speed. The reasons
were (a) VMS, despite the johnny-come-lately Open VMS initiative, was
not an open system and we needed interoperability, (b) our software was
in BLISS, which was effectively a DEC proprietary language despite its
roots at CMU, and (c) our customers wanted either Windows or UNIX on
their networks so that the file system could be shared. Of those
reasons (c) was the dominant one but it had very little to do with
technical issues; it was a matter of perception.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH
- Next message: Tsolak Petrosian: "Re: SproutMethod.pdf"
- Previous message: H. S. Lahman: "Re: Inheritance and Polymorhpism (getting back to the point)"
- In reply to: Richard Dell: "Re: VMS"
- Next in thread: JXStern: "Re: VMS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
