bwm@ccice2.UUCP (Bradford W. Miller) (10/15/84)
Having used this machine I would like to note that despite any wonderful architectural innovations, it basically SUCKED. It was the slowest machine I have ever used, the most limited in disk and memory, and its tools were the worst I had ever seen, except on a CP/M system. Brad Miller -- ...[rochester, cbrma, rlgvax, ritcv]!ccice5!ccice2!bwm
johnl@godot.UUCP (10/18/84)
I used a B1700 for a while, too. It gave me the distinct impression of having been designed by 3 geniuses, who gave us arbitrary bit addressing, swappable microcode, and such, but then implemented by 10,000 idiots who built an unpleasant card-oriented batch operating system on top of it. (And yes, I used the CANDE terminal monitor, which confirmed my opinion about the card-oriented batch system -- it was often faster to get up, go over to the keypunch, punch some cards, and feed them in than to wait for terminal response. And there was just 1 terminal. Sigh.) John Levine, ima!johnl PS: Talk about tesselation buffers, which are not cheap, tends to confirm the hypothesis that for general computing allowing arbitrary byte alignment isn't worth it.
phil@unisoft.UUCP (Phil Ronzone) (10/19/84)
>> Having used this machine I would like to note that despite any wonderful >> architectural innovations, it basically SUCKED. It was the slowest machine >> I have ever used, the most limited in disk and memory, and its tools were >> the worst I had ever seen, except on a CP/M system. >> >> Brad Miller Yeah - but is sure is elegant!
mwm@ea.UUCP (10/21/84)
/***** ea:net.arch / ccice2!bwm / 5:02 pm Oct 18, 1984 */ Having used this machine I would like to note that despite any wonderful architectural innovations, it basically SUCKED. It was the slowest machine I have ever used, the most limited in disk and memory, and its tools were the worst I had ever seen, except on a CP/M system. Brad Miller -- ...[rochester, cbrma, rlgvax, ritcv]!ccice5!ccice2!bwm /* ---------- */ If CP/M is the worst system you have ever seen, then you are very, very lucky. My poor CP/M for several years (1978-1982) had better tools than I could get at the local university, under either Unix, VMS or MVS. This is no longer true of the Unix & VMS systems, but is still true of the MVS (now VM) system. Oh, yeah - it's still faster than VM or the 2.9 BSD system most of the day. <mike
herbie@watdcsu.UUCP (Herb Chong, Computing Services) (10/23/84)
You say MVS was slower than CP/M, which I agree with, but not having the
tools may be inaccurate. Having been a systems programmer in an MVS
environment, I know that approximately half the really useful tools are
kept hidden, on principle from the general user. They tend to do too much
that could violate the security and/or require too detailed knowledge
of things. MVS is not a fair comparison anyways. How can you compare
~20 Mb of code to 8-10kb? Not being aware of the tools and not having them
are two different things. As for the VM environment, which I work in about
as often as Unix lately, the same goes (except only ~2Mb of code). Speed
is not a good thing to compare anyway. The systems you mentioned were
designed for completely different tasks and really is like comparing
apples and oranges. As for user-accessible tools, I think Unix is the
best I have used, but the documentation for our 4.2bsd makes me wish
that they would have written some.
Herb...
I'm user-friendly -- I don't byte, I nybble....
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
BITNET: herbie at watdcs,herbie at watdcsumwm@ea.UUCP (10/29/84)
/***** ea:net.arch / watdcsu!herbie / 2:38 am Oct 25, 1984 */ You say MVS was slower than CP/M, which I agree with, but not having the tools may be inaccurate. Having been a systems programmer in an MVS environment, I know that approximately half the really useful tools are kept hidden, on principle from the general user. /* ---------- */ The tools I was talking about: Visual editors with split-screen & multiple buffers (the universities 4.2 system has one - I put it there so I wouldn't have to put up with (ugh) vi); a reasonable selection of programming languages - LISP, C, FORTRAN, COBOL, ALGOL, Pascal; a symbolic debugger that worked at the language level, not the assembler level; text formatters that knew something about the structure of a document (think Scribe & TEX); graphics hardware other than bogosity on the line printer; typesetting software to use said hardware; communications software; probably others that I've forgotten. Something tells me that these aren't the tools that are being hidden from me by the MVS wizards. <mike
herbie@watdcsu.UUCP (Herb Chong, Computing Services) (10/31/84)
All the tools that you described were available to the general user
on the MVS systems I have worked on. Maybe you had management that
didn't feel that they were "cost effective". If so, maybe they ought
to have their heads examined. Not having things like a nice text editor
(even ISPF isn't that bad), text processing (DCF), and a whole lot of
programming languages is very narrow minded on the part of the system
management. I was refering to more obscure (but very useful) tools like
source control (like make, but far more comprehensive, and more expensive)
and multiple processes, symbolic debuggers, and command processors.
Herb...
I'm user-friendly -- I don't byte, I nybble....
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
BITNET: herbie at watdcs,herbie at watdcsupdbain@wateng.UUCP (Peter Bain) (06/20/85)
In article <5694@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >Actually, my impression was that most everyone had been discouraged by >the B1700's flaws. The concept was fine, but performance was not Myers (see below), quotes a performance comparison of the B1700, a general- purpose (sort of) machine against the IBM System 3 Model 10, a contemporary machine designed to run RPG II exclusively. While the B1700 cost 75% more, as the Sys 3, it ran compute-bound RPG programs EIGHT TIMES AS FAST. The Sys 3's average instruction time was 6 microseconds, as opposed to 35 for the B1700, but, as you might expect, the B1700 had to execute significantly fewer instructions. The citation is: G.L. Myers,Advances in Computer Architecture, 2nd Ed., 1982, John Wiley and Sons, P. 214 -- - peter bain ...!{allegra|decvax|clyde|ihnp4 }!watmath!wateng!pdbain hard mail: CCNG, CPH-2369A, University of Waterloo, Waterloo, Ont. Canada N2M 5G4 telephone: (519) 885-1211 x2810
henry@utzoo.UUCP (Henry Spencer) (06/20/85)
> Myers (see below), quotes a performance comparison of the B1700, a general- > purpose (sort of) machine against the IBM System 3 Model 10, > a contemporary machine designed to run RPG II exclusively. > While the B1700 cost 75% more, as the Sys 3, it ran compute-bound > RPG programs EIGHT TIMES AS FAST. ... I have been told (I have not confirmed this) that when you used a decent programming language, and compared against a decent machine (the System 3 series were real turkeys), the B1700 showed a strong tendency to come out second best. Speaking from only the vaguest memories, RPG and friends are well-suited to microcode implementations: a small set of relatively high-level primitives. Snobol would probably be another favorable case. But when the language primitives get low-level (C, Pascal, Ada) so that one does not get as much mileage out of mapping lots of ordinary-machine instructions into one customized-machine instruction, then things fall down badly. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry