The Perfect Computer - 36 bits?
|
From: jmfbahciv on 29 Mar 2007 08:53 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. /BAH
From: Jan Vorbrüggen on 29 Mar 2007 09:03 > Only for small problems. What do you do in the cases where a > reassembly is the way to make the problem go away? Do a complete SYSGEN? Those weren't PDP-11s, you know. VMS Engineering did a nightly rebuild, and it always needed the largest system or cluster then in existence to make this possible. No way even a small fraction of the customers could have done that, even if they had the disk space to spare. And how would that help, anyway? With the next patch release or update, you are now incompatible with the "official version". Blech. > Sure. I've fixed more. But those are a small piece of all problems. > Patching, even creatively, can only fix a small slice of problems > where a few instructions are out of place (or not in place). And those are 99% of the problems requiring the use of some form of source. For anything else, I the customer do not have enough resources. > We were in the OS development biz, not the app nor observers who played. Tell me more. You know the saying, people loved the VMS Debugger, so they needed to buy DCL, so they need to buy VMS, so they needed to buy VAXen, and that was the basis of DEC's business model. And there's more than a grain of truth to that. I do tend to believe that VMS was last OS to be sold on its own strengths, though, if that helps you any. > I understand the usages of fiche. I'm talking about when they aren't > any good and that's for most of the time w.r.t. solving problems > and customizing your site to suit your needs. Customizing on such a large scale that you need source to the OS? I don't believe even the IBM customers, who were notorious for customizing the hell out of their installations, did that. But DEC customers were very different: They always expected DEC to do that kind of work for them, and complained when they didn't (often due to lack of resources on DEC's side). It was only very late in VMS's life that DECUS guys got their act together in this respect. > And I'm telling you that DEC did not sell its software. Do you know > the difference between licensing and selling? Microsoft licenses > usage; it is not selling software. As I said, you might be believing that, but that doesn't make it true. Here in Germany, Microsoft just got its wrist slapped with regard to trying to stop people who want to resell Windows licenses. And DEC tried to make life hard for people who wanted to transfer licenses, but repeatedly needed to cave in, for both commercial and legal reasons - which of course didn't stop them from trying again and again, as management never learns. Jan
From: jmfbahciv on 29 Mar 2007 08:58 In article <571pp6F2atkpuU1(a)mid.individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> wrote: >> 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). > >Yes, and that is a very valid comment. I think there was some COBOL program >where the VAX was faster than the Alpha, but I don't remember whether it was >translated or recompiled (the latter case would be even more surprising). 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. Think about setting a Ferrari in the middle of rush hour. It will never go as fast as it is built to go because the pathway of the faster car is constrained by the slower peripherals. I don't if this one will work but it's the best I can write up at the moment. It was my third writeup. /BAH
From: jmfbahciv on 29 Mar 2007 09:05 In article <9gal035ncoglbdnvkd8m7odgl59o2opg9b(a)4ax.com>, David Powell <ddotpowell(a)icuknet.co.uk> wrote: >In article <Stydndude4YPyJTbRVnygAA(a)bt.com>, > Andrew Swallow <am.swallow(a)btopenworld.com> in >alt.folklore.computers wrote: > >>jmfbahciv(a)aol.com wrote: > > [big snip here] > >>>> We are talking LSI-11 vs 8086. Even if DEC did not sell to the consumer >>>> market the $1000 business computer on every desk market is enormous. >>> >>> And I'm telling you, again, that DEC did not have the infrastructure >>> to handle that support. DEC's main business was not retail-ish. >> >>Neither did IBM, so IBM created a new distribution infrastructure. >> > >Do you remember Hamilton Rentals, or Rapid Recall? No. > They were the two >distributors appointed by DEC (United Kingdom) in the early 1980s to >sell the small LSI-11 etc stuff. I did not say that there were none; AAMOF, I very carefully wrote that it wasn't our main business. > >>DEC sold to the technical part of companies - so the salesmen, >>warehouses and trucks needed in the first year existed. >> > >Trucks with tail-lifts to move VAXes, LSI-11 stuff came in small >cardboard boxes delivered by the postman on his pushbike. :) Did you require a full-blown soft/hardware maintenance contract? The infrastructure to provide is what I'm talking about. Swallow is ignoring this aspect of the computer biz on purpose. /BAH
From: Nick Maclaren on 29 Mar 2007 09:16
In article <eugcs5$8qk_009(a)s879.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com writes: |> |> >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. Oh, no, this was pure number-crunching. Memory access patterns was perhaps the worst, including TLB miss and cache effects, as well as needing to indirect through or branch to just-loaded addresses. Branch misprediction and enabling the trapping of SIGFPE was perhaps the second - the latter was horrible, but rare. And people doing things that were in hardware on some other systems but emulated on the Alpha was a third. Byte access on the initial Alphas was dire, for example, but at least I never saw a parallel code run on them. Integer division was a classic, too, but at least the Alpha did not make the horrible error of not having an integer multiply (as in original SPARC and PA-RISC). Regards, Nick Maclaren. |