Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (
More info?)
George Macdonald wrote:
> On 31 Aug 2005 05:36:51 -0700, "Robert Myers" <rbmyersusa@gmail.com> wrote:
>
> >George Macdonald wrote:
> >> On 29 Aug 2005 16:58:42 -0700, "Robert Myers" <rbmyersusa@gmail.com> wrote:
> >>
> >> >
>
> >> Hmm, and you you said you didn't want to get into another "Intel/AMD"
> >> round... and yet, there you go again. I was only stating a documneted
> >> acknowledged fact - your prognostications are not relevant.
> >>
> >> The game makers have already stated that they don't expect to get much out
> >> of multi-core - it looks to me single high-speed core is what is needed
> >> there for a (long) while yet. Hell, dual CPUs have been available for long
> >> enough and they have not tweaked any gaming interest.
> >>
> >There are several different issues tangled up here:
> >
> >1. How much further single-thread performance can be pushed.
> >
> >2. How much those chips will cost.
> >
> >3. Whether single-thread chips will dominate gaming.
> >
> >4. How much of what Intel is doing is pure market-speak.
> >
> >5. The purported advantage AMD has with respect to "heat stress."
> >
> >Taking the issues in inverse order:
> >
> >5. The "heat stress" problems Intel has are the result of having to run
> >NetBurst at a higher clock to get comparable performance. The P6 core
> >derivatives have plenty of headroom.
>
> Well that's NetBust fer ya! How'd that happen? They didn't know this was
> going to happen? They did know but decided to press ahead with a spin
> angle on it anyway?... and add HT as a crutch? The "advantage AMD has" is
> not purported - it is tangible... palpable even.
>
NetBurst may be one of the few things we agree on. Intel's architect
says that he expected eventually to improve the IPC performance of
NetBurst. He also admits that his marching orders were to deliver a
processor with a high clock rate, which he did.
> >4. For many applications, performance per watt is the figure of merit
> >of greatest interest because that will determine how much muscle can be
> >packed into a given space. For those who need single-thread
> >performance, it isn't a figure of merit that's of interest. If you
> >really need single-thread performance, there will always be options, at
> >a price
> >
> >http://www.alienware.com/configurator_pages/Aurora_alx.aspx?SysCode=PC-AURORALX-SLI-D
> >
> >IOW, if it's *that* important to you right now, all you have to do is
> >to get out your checkbook.
>
> That is an extreme example and irrelevant here where most people DIY, among
> other reasons. A careful choice of processor performance slot and
> components can get very nice single-thread performance, with the obvious
> promise of more to come. Now that the heat is (temporarily) off AMD on
> single-thread CPUs there is no way of knowing how much they may be holding
> back but I still see performace ramps possible for me as prices drop as
> introduction of the next speed jump slots in at the top-end... given that
> anybody who pays the $$ for the top slot either really needs it or is just
> mad.
>
It's apparent that you don't really need it.
> >3. It may take a while, but there really isn't anywhere else to go.
> >The idea of having a separate, specialized physics engine is kind of
> >silly because there's no reason why the physics can't be done by
> >another CPU core (the solution I really like, actually, is a design
> >like Cell, which seems to get the best of both worlds). You're going
> >to accuse me of shilling for Intel, but you (or someone else reading
> >this) might be interested in
> >
> >http://www.intel.com/cd/ids/developer/asmo-na/eng/strategy/multicore/index.htm
> >
> >Scroll down past the marketing bs to "Application Development and
> >Performance Resources."
>
> Sorry but I have to hark back to my quote by Honda San: "I want to touch
> and hold a better piston, not watch another concept presentation". While
> AMD agrees with, and even pre-empted Intel on dual core, they do not appear
> to be throwing the baby out with the bath water here... in quite the same
> way.
>
While you are insisting that the world is staying single-threaded, most
of the rest of the world is going to be trying to figure out how to use
multiple threads.
> The way that Intel just can't seem to resist the spin bothers me - the
> (marketing) tail is wagging the (engineering) dog just a bit too much...
> there's a corporate sickness here. The way that you have apparently
> latched on to their latest religion from just this past week bothers me
> too.<shrug>
>
There is no reason for you to make this personal. I haven't latched
onto anybody's religion. Power consumption as an issue for HPC wasn't
invented by Intel and I didn't learn about it from Intel. I didn't
learn about power consumption as an issue for servers from Intel: I
learned about it from google and from people with power and space
constraints. And I have been posting for a long time now about the
inevitable move to more cores as a way to get more performance within
the constraints of what is possible with standard cooling.
> >> >That's why you do profiling.
> >>
> >> It makes me wonder sometimes when you spout some buzzword like that as
> >> though it is known to work well for all general purpose code working on all
> >> possible data sets.<shrug> People who use compilers know this.
> >>
> >Would you have been happier if I had said "feedback-directed
> >optimization?" The compiler can't accurately infer dependencies from
> >software written in, say, c. If those ambiguities didn't exist, there
> >would still be the problem of determining the hot paths in the
> >software. Given an accurate control and data flow graph, it's pretty
> >easy to discover the hot paths, and the main reason feedback directed
> >optimization doesn't always work well is that there is no accurate
> >control and data flow graph to begin with. Even the most unlikely of
> >software, like Microsoft Word, turns out to be incredibly repetitive in
> >the paths taken through the software.
>
> You already tried the "feedback directed..." one a while back - thanks for
> reminding me.
🙂 The thing is in a performance-oriented application -- not
> MS Word
🙂 -- how much computer cycles can you afford to "waste" on
> "profiling" the problem data-set at hand before you end up losing out on
> the balance of any gain? I'm afraid your "hot paths" are just as likely to
> be transient anyway - calling it "easy" just doesn't wash for me.
>
I chose MS Word as an example of a particularly challenging
application, because it is. I'm sure there are examples where
profiling doesn't help or helps only if you profile on the actual
problem, but I haven't encountered such a problem. The difficulty,
which you either don't understand or don't want to acknowledge, is the
way that software is written.
RM