The Perfect Computer - 36 bits?
|
From: Peter Flass on 28 Mar 2007 11:09 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. > This is a chink that is going to be blocked up when more > people are able to hire experts at retail prices. You can't > do that yet. There is no gas station equivalent for any > Unix maintenance yet. > > > >>I don't use any Mic$hit apps, so >>it shouldn't be too difficult. > > > If the outside world of unix went away, would you be able to continue? > That is what you need to think about. > > /BAH >
From: Peter Flass on 28 Mar 2007 11:12 jmfbahciv(a)aol.com wrote: > In article <4609993a$0$18859$4c368faf(a)roadrunner.com>, > Peter Flass <Peter_Flass(a)Yahoo.com> wrote: > >>Nick Maclaren wrote: >> >>>It is a great pity that the new RISC systems (as distinct from previous >>>inventions of the approach) concentrated entirely on making the hardware >>>simple, often at the cost of making the software hell to get right. >>>Which is one of the reasons that many aspects of modern software are >>>so much worse than they were 25 years ago. >>> >> >>I, as a programmer, shouldn't have to worry about ordering the >>instructions so as not to lose cycles (pipeline slots, whatever.) >>That's what hardware/microcode is for. > > > Sure. But you are also a system owner and a system manager. > Do the exercise and put each hat on and think from that point > of view. You are also the hardware procurer who makes the sole > decision of what you are going to purchase and plug in. > > /BAH You misunderstand. My argument is that this is, or should be, a function of hardware, microcode, etc. It's too low-level to force everyone to pay attention to it. It adds a lot of complexity to those compilers that do a good job of instruction ordering, and slows down stuff compiled by the rest.
From: Peter Flass on 28 Mar 2007 11:19 Jan Vorbr�ggen wrote: >> A much more reasonable, and possibly true, assertion would be that the >> advantage of RISC architectures decreased over time. However, even as >> late as the Pentium 1, there was a huge advantage for RISC >> architectures. With the Pentium Pro that became less clear, although >> RISCs still ruled the roost for FP heavy applications. > > > Yes, I quite agree with that. > > 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. > > Jan 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.
From: Peter Flass on 28 Mar 2007 11:25 Jan Vorbr�ggen wrote: > > Bah. In this case, diagnosis is more than half the cure, and for > diagnosis, the microfiche is more than good enough. And with PATCH (in > DDT's place), I fixed several of such cases on the fly, source or no > source. The only time I asked for source was when I wanted to use a > class driver as a template for a new one, and I wanted to skimp on the > typing job. And after a little while, I got the source. > I agree. I was able to implement an "exit" at VSAM open that improved our performance 30%, using just fiche. A release later, I could still plug it in without the fiche by disassembling the module. Fortunately, the release after that we had moved away from heavy VSAM, so I was able to forget about it. Not having source *or* fiche made me very nervous.
From: Nick Maclaren on 28 Mar 2007 11:43
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). Regards, Nick Maclaren. |