Is it time to stop research in Computer Architecture ?
|
From: Bill Todd on 21 Oct 2009 20:16 Robert Myers wrote: > On Oct 21, 6:08 am, Bill Todd <billt...(a)metrocast.net> wrote: > >> Once again that's irrelevant to the question under discussion here: >> whether Terje's statement that Merced "_would_ have been, by far, the >> fastest cpu on the planet" (i.e., in some general sense rather than for >> a small cherry-picked volume of manually-optimized code) stands up under >> any real scrutiny. > > I think that Intel seriously expected that the entire universe of > software would be rewritten to suit its ISA. > > As crazy as that sounds, it's the only way I can make sense of Intel's > idea that Itanium would replace x86 as a desktop chip. Did you forget that the original plan (implemented in Merced and I'm pretty sure McKinley as well) was to include x86 hardware on the chip to run existing code natively? With that, plus only the assumption that *new* code would be written for Itanic, the replacement plan becomes at least somewhat more believable: old code doesn't have to run any faster than it did when it was written, and new code with its (seemingly) inevitable increase in bloat factor gets to be complied to run natively on Itanic with improved speed. Intel wasn't run by complete idiots, just by insufficiently skeptical (and/or 'easily impressed') but otherwise reasonably bright people. All they had to believe was that the expected performance domination would materialize (which was HP's area of expertise, and HP was at that time a reputable source) - and a hell of a lot of fairly bright people *outside* Intel bought into this right into the start of this decade, not just the middle of the last one. - bill
From: Stephen Fuld on 21 Oct 2009 20:29 Paul Wallich wrote: > Stephen Fuld wrote: snip >> Does the way your spreadsheet works force serial calculations? I.e. >> are almost all the cells that are to be recalculated dependent upon >> the previous one, thus forcing a serial chain of calculations. Or are >> there "multiple chains of dependent cells" that are only serial due >> to the way Excel itself is programmed? If the latter, one could >> enhance Open Office to use multiple threads for the recalcs which >> would take advantage of multiple cores for something useful. > > I would be that a huge chunk of the time isn't in doing the actual > calculations but in verifying that the calculations can be done. > Spreadsheets are pretty much the ultimate in mutably-typed interactive > code, and there's very little to prevent a recalculation from requiring > a near-universal reparse. Wow, I hadn't thought of that. But if you are say running multiple simulation runs, or something else where the only thing changing is the value of some parameters, not the "structure" of the spreadsheet, does Excel understand that it can skip at least most of the reparse? I suspect that Andy's spreadsheets are at the extreme of what they thought about, and perhaps beyond. They just may not have spend much time trying to eliminate or at least minimize what has to be reparsed as opposed to optimizing recalc in general. -- - Stephen Fuld (e-mail address disguised to prevent spam)
From: Robert Myers on 21 Oct 2009 20:31 On Oct 21, 6:32 pm, Andrew Reilly <andrew-newsp...(a)areilly.bpc- users.org> wrote: > On Wed, 21 Oct 2009 13:56:13 -0700, Robert Myers wrote: > > As crazy as that sounds, it's the only way I can make sense of Intel's > > idea that Itanium would replace x86 as a desktop chip. > > I don't think that it's as crazy as it sounds (today). At the time > Microsoft had Windows NT running on MIPS and Alpha as well as x86: how > much effort would it be to run all of the other stuff through the > compiler too? Maybe Rob Warnock would tell us a little more candidly than he did before just how hard it was to wring those SpecFP numbers out of Itanium. I think he already said you needed a black belt in compiling, or something like that. I've fiddled a little with the off-the-shelf Itanium compilers, but I always assumed that none of those compilers were even remotely good enough that you could expect just to run old software through them and get anything like hoped-for performance. John Dallman has had a bit to say on the subject here. When I talked about rewriting code, I meant just that, not merely recompiling it. I wasn't all that interested in the standard task: how do you feed bad code to an Itanium compiler and get acceptable performance, because I was pretty sure that the answer was: you don't. I was more interested in the question: how do you write code so that a compiler can understand enough about it to emit code that could really exploit the architectural features of Itanium? I always assumed that someone at Intel understood all that and briefed it to management and management said, "No problem. We'll have the only game in town, so people will conform their code to our hardware." If you accept that proposition, then all you need to do is to get enough code to run well to convince everyone else that it's either make their code do well on the architecture or die. I'm pretty sure that Intel tried to convince developers that that was the future they should prepare for. > > > To add spice to the mix of speculation, I suspect that Microsoft would > > have been salivating at the prospect, as it would have been a one-time > > opportunity for Microsoft, albeit with a huge expenditure of > > resources, to seal the doom of open source. > > How so? Open source runs fine on the Itanium, in general. (I think that > most of the large SGI Itanium boxes only run Linux, right?) RedHat Enterprise still supports Itanium, so far as I know. Open source depends on gcc, perhaps the cruftiest bit of code on the planet. Yes, gcc will run on Itanium, but with what level of performance? Could the open source community, essentially founded on x86, turn on a dime and compete with Microsoft running away with Itanium? Maybe with IBM's muscle behind Linux, open source would have stood a chance, but I'm not so sure. After all, IBM would always have preferred an Itanium-free world. Had I been at Microsoft, I might have seen a Wintanium future as really attractive. It's true: Itanium never came close to meeting hardware goals, but whether Itanium was even possible at all was as much a matter of software and compilers as it was a matter of hardware, and Microsoft is all about software. Robert.
From: Robert Myers on 21 Oct 2009 20:54 On Oct 21, 8:16 pm, Bill Todd <billt...(a)metrocast.net> wrote: > Robert Myers wrote: > > On Oct 21, 6:08 am, Bill Todd <billt...(a)metrocast.net> wrote: > > >> Once again that's irrelevant to the question under discussion here: > >> whether Terje's statement that Merced "_would_ have been, by far, the > >> fastest cpu on the planet" (i.e., in some general sense rather than for > >> a small cherry-picked volume of manually-optimized code) stands up under > >> any real scrutiny. > > > I think that Intel seriously expected that the entire universe of > > software would be rewritten to suit its ISA. > > > As crazy as that sounds, it's the only way I can make sense of Intel's > > idea that Itanium would replace x86 as a desktop chip. > > Did you forget that the original plan (implemented in Merced and I'm > pretty sure McKinley as well) was to include x86 hardware on the chip to > run existing code natively? I never took that capability seriously. Was I supposed to? I always thought it was a marketing gimmick. Robert.
From: Bill Todd on 21 Oct 2009 21:44
Robert Myers wrote: > On Oct 21, 8:16 pm, Bill Todd <billt...(a)metrocast.net> wrote: >> Robert Myers wrote: >>> On Oct 21, 6:08 am, Bill Todd <billt...(a)metrocast.net> wrote: >>>> Once again that's irrelevant to the question under discussion here: >>>> whether Terje's statement that Merced "_would_ have been, by far, the >>>> fastest cpu on the planet" (i.e., in some general sense rather than for >>>> a small cherry-picked volume of manually-optimized code) stands up under >>>> any real scrutiny. >>> I think that Intel seriously expected that the entire universe of >>> software would be rewritten to suit its ISA. >>> As crazy as that sounds, it's the only way I can make sense of Intel's >>> idea that Itanium would replace x86 as a desktop chip. >> Did you forget that the original plan (implemented in Merced and I'm >> pretty sure McKinley as well) was to include x86 hardware on the chip to >> run existing code natively? > > I never took that capability seriously. Was I supposed to? Why not? It ran x86 code natively in an integrated manner on a native Itanic OS. As with most things Merced the original cut wasn't impressive in terms of speed, but the relative sizes of the x86 and Itanic processors (especially given the amount of the chip area dedicated to cache) made it clear that full-fledged x86 cores could be included later if necessary as soon as the next process generations appeared. On-the-fly translation wasn't exactly common when the original plans were made (though the facilities for running x86 code on Alphas were probably well under way). Later on, after Intel had inherited a lot of those Alpha developers and the planned desktop takeover had become indefinitely postponed, it made more sense to do the work in software. - bill |