Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

for my new system my cpu budget will be about US$380 (NZ$550), i really
have two Athlon64 procs to choose from, the 4000+ or the X2-3800+.

the pc will be used mainly for 3D animation (single threaded), i don't
do much rendering these days, but occasionaly. gaming performance is
very important most of my $$ will be going on a 7800GT or GTX and
1920x1200 display.

at this stage the 4000+ is my preference, it crushes the X2 in gaming,
but i remember when i had a dual-cpu system (even a lowly PIII) the OS
was a bit more response... so i can't decide i've heard the X2-3800+
OCs pretty well, could that run at 2.4GHz and does it shorten the life
of the chip considerably...?

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

gimp wrote:
>
> ... gaming performance is very important most of my $$ will be
> going on a 7800GT or GTX ...
>

Not worth waiting for the ATI R520 / X1800 cards?

I know, I know. They've been ages in coming, yield problems being the
biggest issue.
However, indications are that when they're launched in 4 weeks time it
will be a hard launch, similar to the 7800GTX, with volume availability.
Just thinking it would be annoying to buy a 7800, only to have it drop
in price not long after the R520 is released, or discovering that the
equivalent ATI card completely owns it.
I'm guessing the R520 may well be an overclockers dream (considering
they're built on 90nm technology).

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Daniel wrote:
>> ... gaming performance is very important most of my $$ will be
>> going on a 7800GT or GTX ...

> Not worth waiting for the ATI R520 / X1800 cards?

> I know, I know. They've been ages in coming, yield problems being the
> biggest issue.
*snip*
> I'm guessing the R520 may well be an overclockers dream (considering
> they're built on 90nm technology).

wouldn't yeild problems indicate the opposite?

--
http://dave.net.nz <- My personal site.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Dave - Dave.net.nz wrote:
> Daniel wrote:
>
> *snip*
>
>> I'm guessing the R520 may well be an overclockers dream (considering
>> they're built on 90nm technology).
>
>
> wouldn't yeild problems indicate the opposite?
>

My understanding is that issues were primarily with the number of pipes
that could be successfully tapped out. After their 3rd attempt at taping
out the GPU, they seem to have sorted enough of the issues out to
actually release them. I understand that 16 pixel pipeline versions are
readily available (i.e. best yields), although, I'm not sure if 24pp or
even 32pp (imagine crossfire with those cards ... grrrr) versions will
be available in the first week of October.
As far as clock speed goes, it's 90nm fab process tech, so I'd expect
higher clock speeds (apparently 600-650 MHz stock for top-end R520 GPU
core).
I'd be very interested to see what the power consumption and heat output
numbers for the new ATI cards will be - once those annoying NDAs have
expired of course.
Sooner or later, NVIDIA will have to go 90nm as well or lower, otherwise
ATI will leave them in the dust.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Daniel wrote:
> gimp wrote:
>> ... gaming performance is very important most of my $$ will be
>> going on a 7800GT or GTX ...
>>
>
> Not worth waiting for the ATI R520 / X1800 cards?
>
> Just thinking it would be annoying to buy a 7800, only to have it drop
> in price not long after the R520 is released, or discovering that the
> equivalent ATI card completely owns it.


my 3D app Maya can have issues with ATI drivers unfortunately, they're
probably getting better but the industry [at least with my app] tends
towards nVidia hardware which have been solid with Maya for several
years. but good point RE the possible price drop, i won't buy before
the ATI release anyway.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

gimp wrote:
>
> my 3D app Maya can have issues with ATI drivers unfortunately, they're
> probably getting better but the industry [at least with my app] tends
> towards nVidia hardware which have been solid with Maya for several
> years. but good point RE the possible price drop, i won't buy before
> the ATI release anyway.

Cool :-)

[...readies to suggest Quadro card, then faints at price...]

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Tony Hill wrote:
> What is a bigger worry with overclocking the processor is that you
> often end up overlocking other parts of the system and usually that is
> what ends up limiting how high you can clock the chip. There are a
> number of websites out there that specialize in overclocking and which
> might offer you some decent insights into what you could expect from
> the chip.

thanks for the info been doing some googling and apparently people
have clocked it as high as 2.8GHz (!) 2.4 would be enough for me... i
would have to research it more as i've never OC'd and don't want to melt
down the chip/mobo.

i just found this:

http://forums.extremeoverclocking. [...] 83472.html

probably the X2 is gonna win out i think

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

"gimp" <anonymous@smeg.com> wrote in message
newsg7ls7$okj$1@lust.ihug.co.nz...
> for my new system my cpu budget will be about US$380 (NZ$550), i really
> have two Athlon64 procs to choose from, the 4000+ or the X2-3800+.
>
> the pc will be used mainly for 3D animation (single threaded), i don't do
> much rendering these days, but occasionaly. gaming performance is very
> important most of my $$ will be going on a 7800GT or GTX and 1920x1200
> display.
>
> at this stage the 4000+ is my preference, it crushes the X2 in gaming, but
> i remember when i had a dual-cpu system (even a lowly PIII) the OS was a
> bit more response... so i can't decide i've heard the X2-3800+ OCs
> pretty well, could that run at 2.4GHz and does it shorten the life of the
> chip considerably...?
>
>

Im in the same boat as you.....
Personally tho, Im going for the X2 - future proofing the system for at
least 6 months (Yeah right)

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

gimp wrote:
>
> ... most of my $$ will be going on a 7800GT or GTX and
> 1920x1200 display.
>

Assuming you mean LCD (1920x1200 native res for 23/24" LCDs - AFAIK),
what make & model are looking at?

I've read the Dell 24" LCDs are awesome monitors and compare favourably
with the Apple 24" Cinema LCDs.
Also, read that the Philips 24" LCDs aren't that flash.

Just curious.

Cheers.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Bitstring <dg7ls7$okj$1@lust.ihug.co.nz>, from the wonderful person gimp
<anonymous@smeg.com> said
<snip>
>at this stage the 4000+ is my preference, it crushes the X2 in gaming,
>but i remember when i had a dual-cpu system (even a lowly PIII) the OS
>was a bit more response... so i can't decide i've heard the
>X2-3800+ OCs pretty well, could that run at 2.4GHz and does it shorten
>the life of the chip considerably...?

Only elevated temperature shortens the life of the chip, and even then
it needs to be (IIRC) about 15c higher to halve the life (from 120 years
to 60! - OK I guessed at the 120, but that's probably the usual design
goal). Merely overclocking, doesn't do any harm (although ramping the
voltage to achieve higher clock speed definitely does reduce lifetimes
too, apart from the extra heat effect).

Chip power = constant * frequency * voltage * voltage .. as you can see,
ramping the (VCore) voltage has more effect than ramping the clock, but
still not a big issue if you can get the power away, and keep the chip
cool (and remember the AMD spec says 'it'll work for X years with the
core temperature at 80c' .. so you're probably already running well
inside the window.

Get the dual Core chip - =current= games might work better on the 4000+,
but game designers know how to code dual (or quad, or more) threaded
games, so future games may run lots nicer on a dual core chip - and even
for current games you'll at least be able to have all the WinXP OS cr&p
happening in the other CPU (which is significant sometimes).

I guess you could just stick in a XP3x00+ single core chip in now, and
wait for the XP4800+ to come down in price. 8>.

--
GSV Three Minds in a Can
Contact recommends the use of Firefox; SC recommends it at gunpoint.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

GSV Three Minds in a Can wrote:
>
> ... but game designers know how to code dual (or quad, or more) threaded
> games...
>

Really?

Multi-threaded code is difficult enough in a single core CPU, let alone
a multi-core CPU.

I know that multi-core CPUs have been around for a while, but the
instances that I've seen (and worked with) allocate individual
processes/applications to a single CPU (i.e one CPU to many apps), but,
*not* the other way around - one app to many CPUs.
Please note, I'm referring to an app that is specifically written to
work with multiple cores (i.e multi-core aware), and so is therefore
able to avoid deadlock situations *between* cores.
Sure, you can divide some problems and run them in parallel (like how a
modern GPU renders complex 3D scenes). However, these are very specific
types of problems which can be easily segmented.

AMD and Intel were basically forced to go dual core because of the
limitations they encountered with higher clock speeds.

Game developers aren't exactly jumping up and down with joy over the
prospect of developing multi-core games.
Agreed, they'll have to now - particularly with next gen consoles all
using multi-core PowerPC CPUs.

However, to say that "game designers know how to code dual (or quad, or
more) threaded games" in the context of a dual (or multi) core CPU does
seem a little premature at this stage.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Bitstring <dgab82$msc$1@lust.ihug.co.nz>, from the wonderful person
Daniel <atari400@paradise.net.nz> said
>GSV Three Minds in a Can wrote:
>> ... but game designers know how to code dual (or quad, or more)
>>threaded games...
>>
>
>Really?
>
>Multi-threaded code is difficult enough in a single core CPU, let alone
>a multi-core CPU.

<snip>

Jeez, if you can do it for a 4 CPU workstation, what's the issue doing
it for a dual core CPU? Note I didn't say they were going to do it
=perfectly= and achieve a 2x speedup in the gameplay .... but there's
plenty of stuff that's just dying for some parallel processing (the
AI(s), the UI, the graphics upstream of the Graphics card, etc.)

I thought avoiding deadlocks was a solved problem since Knuth volume
<n>, more years ago than I care to count, and that was without the
hardware assistance we get these days ...

>However, to say that "game designers know how to code dual (or quad, or
>more) threaded games" in the context of a dual (or multi) core CPU does
>seem a little premature at this stage.

Hmm, guess I could make some money teaching courses then, it's not like
it's rocket science or anything. Now I have a few fractals programs
which =are= going to need a bit of rocket science, but hey, that's my
fault for coding them in x87 assembler ...

--
GSV Three Minds in a Can
Contact recommends the use of Firefox; SC recommends it at gunpoint.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

GSV Three Minds in a Can wrote:
> <snip>
>
> Jeez, if you can do it for a 4 CPU workstation, what's the issue doing
> it for a dual core CPU? Note I didn't say they were going to do it
> =perfectly= and achieve a 2x speedup in the gameplay .... but there's
> plenty of stuff that's just dying for some parallel processing (the
> AI(s), the UI, the graphics upstream of the Graphics card, etc.)
>
Okay, I'll bite.

What multi-CPU aware apps are you using then?

Just because you can run a program across X number of CPU's in a
workstation doesn't make it multi-core aware.

Also, as I said in the original post, there are some problems that can
be easily segmented - and I did mention graphics.


> I thought avoiding deadlocks was a solved problem since Knuth volume
> <n>, more years ago than I care to count, and that was without the
> hardware assistance we get these days ...
>
Avoiding deadlocks is easy. Doing so efficiently in a realtime
environment is the real trick (we already get enough deadlocks in single
core code - and yes the intention was to avoid a deadlock, but, it still
happens).

I've used shared memory and semaphores for the locking (usual IPC), to
coordinate between multiple processes running on a multi-CPU server. The
"application" in this sense is a combination of disparate processes.
However, neither of these processes "know" they're running on a
multi-CPU system. As far as they're concerned they're only running on a
single CPU. Each process has it's own process space (i.e. it's not
*shared* with the other processes).
Surely, the benefit of a multi-core CPU would be for the cores to
operate on the *same* process/memory space. Otherwise your limited to
the types of problems that both CPUs can work on simultaneously (i.e.
not much benefit vs. a single core CPU).


> Hmm, guess I could make some money teaching courses then, it's not like
> it's rocket science or anything. Now I have a few fractals programs
> which =are= going to need a bit of rocket science, but hey, that's my
> fault for coding them in x87 assembler ...
>
If you've written a multi-threaded single core program in assembler (not
to be confused with multi-tasking - sorry, just being sure), then dude -
surely you'd know the hassles involved in getting all that to work.

Now imagine all those problems multiplied because now you've got to
synchronise across 2 or more CPU cores.

Odd you should be using assembler? Compiler optimizations are pretty
good these days (unless your into deliberately writing obfuscated code
of course).
Or were you just being facetious.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

Daniel wrote:
> GSV Three Minds in a Can wrote:
>
> If you've written a multi-threaded single core program in assembler (not
> to be confused with multi-tasking - sorry, just being sure), then dude -
> surely you'd know the hassles involved in getting all that to work.
>
> Now imagine all those problems multiplied because now you've got to
> synchronise across 2 or more CPU cores.
>
> Odd you should be using assembler? Compiler optimizations are pretty
> good these days (unless your into deliberately writing obfuscated code
> of course).
> Or were you just being facetious.

Plus debugging multi-threaded code is a nightmare.

Debugging multi-threaded multi-core code.... yuk.

Archived from groups: comp.sys.ibm.pc.hardware.chips,nz.comp (More info?)

"Daniel" <atari400@paradise.net.nz> wrote in message
newsgahfi$2gs$1@lust.ihug.co.nz...
> GSV Three Minds in a Can wrote:
>> <snip>
>>
>> Jeez, if you can do it for a 4 CPU workstation, what's the issue doing it
>> for a dual core CPU? Note I didn't say they were going to do it
>> =perfectly= and achieve a 2x speedup in the gameplay .... but there's
>> plenty of stuff that's just dying for some parallel processing (the
>> AI(s), the UI, the graphics upstream of the Graphics card, etc.)