The Perfect Computer - 36 bits?
|
From: Brian Inglis on 31 Mar 2007 02:08 On Thu, 29 Mar 2007 15:34:16 +0200 in alt.folklore.computers, Jan Vorbr�ggen <jvorbrueggen(a)not-mediasec.de> wrote: >> Neither would matter. Look if you increase your "CPU speed" by twice, >> your system will then be constantly waiting on I/O becaues the >> CPU got its job done faster. YOur system software and usage had >> been tweaked over the years to accomodate the behaviour of a VAX >> with its peripherals (this includes memory). Now you replace >> the CENTRAL processing unit with something that goes twice as fast. > >If VAX processor speed had increased in parallel with the rest of the >industry, that would be a valid comment that applied almost all around, >but it did not. And I and many people I know are in the HPC department with >regard to processor speed - heck, for a lot of codes I used we got practically >linear speedup with processor MHz, main memory speed be damned. I/O speed - if >not paging or swapping - was simply irrelevant. > >Even for Oracle, I/O isn't necessariyl the limiting factor. Oracle was really nippy on multiprocessor Tru64 systems with lots of cache and memory. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Brian Inglis on 31 Mar 2007 02:13 fOn Thu, 29 Mar 07 12:53:25 GMT in alt.folklore.computers, jmfbahciv(a)aol.com wrote: >In article <eue2f9$3o5$1(a)gemini.csx.cam.ac.uk>, > nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote: >> >>In article <460a8773$0$17152$4c368faf(a)roadrunner.com>, >>Peter Flass <Peter_Flass(a)Yahoo.com> writes: >>|> Jan Vorbr�ggen wrote: >>|> >>|> > There is one particular case where the playing ground was as even as >>|> > possible to allow comparison of two implementations of a CISC and a RISC >>|> > architecture: The NVAX+ implementation of the VAX architecture and the >>|> > 21064 implementation of the Alpha architecture (IIRC) both used the same >>|> > design tools in the same company, the same foundry and the same process. >>|> > And there sure were competent people working all aspects of the design >>|> > on both teams. The end result: the Alpha processor was, by most >>|> > measures, about twice faster than the VAX. >>|> >>|> Is this MIPS or real-world thruput? What kind of workload? I'm not >>|> intimately familiar with Alpha, but one VAX instruction had to often >>|> equal three or four Alpha instructions, what with string instr, >>|> three-address instr., etc. This would be a good test, if someone >>|> actually did a fair comparison and published the results. >> >>Real-world, but your second question is very relevant. The VAX was >>relatively constant in performance between workloads, but the Alpha >>varied by an incredible factor (ten or more, on practical workloads). > >Where were the bottlenecks on the Alphas you saw? My guess would >be disk. That would be normal in the evolution of system gear >development. You stick in a lot of controllers and a lot of arms and the I/O problems go away. You only have problems when the h/w or s/w can't handle that number of controllers or arms. PPoE had PDP-11/70s close to maxing out theoretical drive performance, and with same h/w, VAX did no better, worse with multiple interactive terminal loads, until DECservers became available, acting as outboard muxes or FEs. How many FE machines could you attach to a PDP-10? -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Brian Inglis on 31 Mar 2007 02:28 On Fri, 30 Mar 07 12:12:22 GMT in alt.folklore.computers, jmfbahciv(a)aol.com wrote: >In article <573r7kF2arf8qU1(a)mid.individual.net>, > =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >>> OK, then my question goes back to Jan and Barb. Why was a full sysgen >>> required or recommended for the situations you guys were talking about? >>> Wouldn't partial gens do the job without the need for the large >>> resource commitment Jan talked about? >> >>At least for the first 10 years or so, VAX/VMS wasn't structured in a >>sufficiently loose way to make this feasible, IMO - we're talking the core of >>the OS here, > >Yes, I'm talking about that, too. > >> of course, not all of the utilities etc. that constitute the bulk >>of the code. However, if you needed to make an interface change at the >syscall >>level, you'd need to recompile everything. > >Really? Most of TOPS-10's rebuilds had to do with hardware changing, >not software. Oh, I see. ARe you talking about adding a new >syscall? That would be a new feature; it's safer to do a complete >rebuild, especially if the syscall had anything to do with disk >I/O user-mode code interfaces. > > >> >>And anyway, I can't think of a problem that would have required a rebuild. >>Significantly upgrading a subsystem, like the batch or print job management, > >Nah, on the -10 that was at the app level. > >>would have been much easier with the source - but as I said, DEC customers >>never considered such things until (too) late, in contrast to IBM's >customers. > >Our device tables, command tables, and all fields associated with them >were generated by macros based on the questions answered at MONGEN >time (a program that queried the sysmanger what hardware and software >features he wanted to put on his computer system). The best >way to make any changes to those would be to do it the "right way". >Fumble fingers can destroy machines. Without the sources, you'd just dump the tables, define your own macros to create the entries, and add new entries to the tables; find where the table origins were loaded, and patch the code to load the new origins. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Brian Inglis on 31 Mar 2007 02:37 On Thu, 29 Mar 07 12:39:33 GMT in alt.folklore.computers, jmfbahciv(a)aol.com wrote: >In article <460a8553$0$8961$4c368faf(a)roadrunner.com>, > Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >>jmfbahciv(a)aol.com wrote: >>> In article <460a471e$0$28137$4c368faf(a)roadrunner.com>, >>> Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >>> >>>>Morten Reistad wrote: >>>> >>>>> >>>>>Just watch the pain unfold when Vista cannot run your application. >>>>>With binary-only, Microsoft products you will have a similar experience >>>>>as we had when DEC folded on us. There is no Plan B in this scenario. >>>>>>>The lesson from DEC is that it can happen. >>>>>>> >>>>>>>Always have a Plan B. >>>>> >>>>As I already said, my plan B is Linux. >>> >>> >>> However, there are a lot of system owners who cannot use that >>> as their Plan -anythings because they are not in the software >>> biz. >> >>I got excited when I heard Dell was going to (again) ship retail PCs >>with Linux. Then I contacted support and found out they're going to >>pre-load some dumb version of DOS, and sell Linux separately. While >>everyone here would have no trouble installing a new OS, non-M$ systems >>will continue to lag until they're available pre-loaded and >>pre-configured. M$ knows this, and I'm sure their fingerprintes are all >>over everything. > >When JMF was dying (1994) and needed a laptop in order to speak, I >tried to order one from Dell. I was told that it would take >six months to install Unix. I'm an auld OS babe and smelt the >rat. >I have not tested this part of the OS biz since then. My first Linux install was 30 minutes from opening the Slackware CD wrapper to running the OS with an alternate boot to DOS/Windows. It then took longer just to config a customized kernel to support needed drivers and eliminate unnecessary ones; the kernel source rebuild took much longer. -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Steve O'Hara-Smith on 31 Mar 2007 05:53
On Sat, 31 Mar 2007 06:37:53 GMT Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: > My first Linux install was 30 minutes from opening the Slackware CD > wrapper to running the OS with an alternate boot to DOS/Windows. Heh my first Linux install took over an hour - but then it was SLS on rather a lot of floppies :) I considered it a vast improvement over my first X11R5 install at home which took about two weeks tweaking the Makefiles to get past limitations in the make on the box and implementing the other (server IIRC) side of the pseudo TTY transport because I didn't have sockets or streams support. -- C:>WIN | Directable Mirror Arrays The computer obeys and wins. | A better way to focus the sun You lose and Bill collects. | licences available see | http://www.sohara.org/ |