Re: Non-intel benchmarks on Conroe vs AMD's AM2 FX62

krw wrote:

In article <ijl8721m1a7sv475ju46mcj83vhnd36b03@xxxxxxx>,
chrisv@xxxxxxxxxxxxxx says...

I understand where you're coming from, Keith, and ordinarily I'd agree
with you. But today we are in a situation just a couple months short
of the rare occasion completely redesigned X86 CPU, with early reports
being VERY promising. Personally, knowing what I know today, I would
delay my purchase until these things are available, just in case they
are that much better.

I'd be waiting more than a couple of months! Let the shake-out
happen.

Are you advocating waiting, for some future "shake-out" or price
reduction? Why is that more reasonable than waiting for an entirely
new and promising CPU?

DO you think these things are going to be free?

No, I do not think they will be free. Strange question...

I do think that consumers will benefit, perhaps even immediately, by
having Intel competitive again. Indeed, they may have already, given
recent price-cuts. If Intel has FUD'ed AMD, they've also FUD'ed their
own current CPU products.

In any event, the value should be fair. It's not like they're going
to suddenly start charging us more, in terms of dollars per unit
performance, than what they are today (or what AMD will be charging
then).

No, buy what you need when you need it.

If you really "need" it, yes. However, for most people, there's quite
a bit of slop in the time-frame where they will "need" a new PC
(unless the old one dies). That's where "want" comes in, and I'm
afraid that not all "wants" are purely logical and precisely timed for
maximal value/dollar, whether it's a new PC or a new car. I think
this is especially true of enthusiasts, for whom these devices are not
merely tools, but something that they think is "cool" - there's not
much cooler than a brand new CPU design on a brand new manufacturing
process.

The performance difference simply
won't be astronomical. Those days are *long* gone.

Astronomical? No. Significant? Very possible. From early reports,
this may be the biggest leap in desktop CPU performance that we've had
in some years.

After all, A64, while a very elegant design, didn't really leap us
forward in performance - it basically performs like an Athlon clocked
at whatever frequency. AMD's recent dominance in the performance
arena is mostly the result of Intel falling on it's arse with "Net
Burst".

I do not disagree with the "if your old machine ain't cutting it, get
a new one now" rule. But, given the flexibility that most of us have
regarding our old machine "cutting it", and the new CPU due shortly,
I'd say it's a very reasonable decision at this time to wait and see
how this thing performs.

.

Relevant Pages

  • Re: Non-intel benchmarks on Conroe vs AMDs AM2 FX62
    ... Are you advocating waiting, for some future "shake-out" or price ... new and promising CPU? ... much better reason to wait than are future price reductions. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: f9: question on load average
    ... i.e. those that could do something if they had the cpu. ... are waiting for something to happen, e.g. I/O to complete, can't use the ... Here's a more technical explanation of how the LA is calculated: ...
    (Fedora)
  • Re: Win 200 SP4 Boot time
    ... waiting for something good to happen, and speeds up when you're waiting ... >>I suspect the security program is the core problem. ... Clicking on the CPU heading in that window will arrange the ... >>executing processes by CPU cycles used. ...
    (microsoft.public.win2000.setup)
  • Re: [PATCH] Delay accounting, fix incorrect delay time when constantly waiting on runqueue
    ... This patch corrects the incorrect value of per process run-queue wait time ... When a process leaves the CPU and immediately starts waiting for CPU on ... on the runqueue from this point of re-entry upto the next time it hits the CPU ...
    (Linux-Kernel)
  • Re: On the necessity of threads having sleep time...
    ... thread will consume all CPU time for the process and will not allow ... one thread that reads from client connections when a client has a ... There are also some rare situations where you wouldn't want any waiting or ... Have the thread monitor a variable that ...
    (comp.programming.threads)