best sub $400 CPU

[Daniel]

I've got some code sitting here which ought be able to soak up however
many cores I can afford to throw at it - one thread for the display
(rate limited by how fast the user flies &/or the availability of frame
buffers), one for the UI (may be mostly idle), and 1-N threads (1 per
frame) doing the calculation, (allowing as how you may have to dump
future frames if the user decides to scroll sideways). All one process,
although nobody gets to play with anyone else's frame buffer until it is
'done', and there is no interaction between frame<N> and frame <N+1>
during the calculation phase. Actually there isn't any interaction
between each scan line and the next one IIRC, so I could actually toss
1024 cores at =each= frame buffer (but it isn't coded that way).

Chess plays pretty well on multi-CPU systems of course, an I don't see
why an X2 is going to be any different from a two CPU workstation in
that regard - Fritz<n> should be able to handle it right out of the box.
Not that I'm very excited by that, except for analysis - I already can't
beat Fritz on an XP3000+.

Time for a link:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=4

Quoting Tim Sweeny:
"Writing multithreaded software is very hard; it's about as unnatural to
support multithreading in C++ as it was to write object-oriented
software in assembly language. The whole industry is starting to do it
now, but it's pretty clear that a new programming model is needed if
we're going to scale to ever more parallel architectures. I have been
doing a lot of R&D along these lines, but it's going slowly."

I would say Tim Sweeny knows a bit more about game programming than
either of us.

 

[nobody]

Time for a link:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=4

Quoting Tim Sweeny:
"Writing multithreaded software is very hard; it's about as unnatural to
support multithreading in C++ as it was to write object-oriented
software in assembly language. The whole industry is starting to do it
now, but it's pretty clear that a new programming model is needed if
we're going to scale to ever more parallel architectures. I have been
doing a lot of R&D along these lines, but it's going slowly."

I would say Tim Sweeny knows a bit more about game programming than
either of us.

In plain old C++ multithreading may be cumbersome. However, in C# or
even (cough) VB.NET it is relatively easy to run as many threads as
your app has tasks that may run asynchronously (though hardly ever had
to deal with more than 5 at a time). A bit more tricky is when you
need to synchronize the threads at some point, but still you don't
have to be a rocket scientist. While I am not a guru in Assembly
programming or C++ like some folks here, but still MCAD (Microsoft
Certified App Developer for those who don't know), so I supposedly
know a thing or two about the programming, including multi-threaded
apps. Believe me, with the spread of .NET soon most business (and not
only business) apps will be multithreaded
Rgds,
NNN

 

[Daniel]

In plain old C++ multithreading may be cumbersome. However, in C# or
even (cough) VB.NET it is relatively easy to run as many threads as
your app has tasks that may run asynchronously (though hardly ever had
to deal with more than 5 at a time). A bit more tricky is when you
need to synchronize the threads at some point, but still you don't
have to be a rocket scientist. While I am not a guru in Assembly
programming or C++ like some folks here, but still MCAD (Microsoft
Certified App Developer for those who don't know), so I supposedly
know a thing or two about the programming, including multi-threaded
apps. Believe me, with the spread of .NET soon most business (and not
only business) apps will be multithreaded
Rgds,
NNN

Errr.... oookaaay.

Free plug for C# or VB.NET.

But, I'm not quite sure how it relates to the issue?

I've also written threaded programs (albeit in Java). Being able to
write multi-threaded code is not the issue.

The issue was whether or not game developers "... know how to code dual
(or quad, or more) threaded games...", in reference to multi-core CPUs.
My stance is that the gaming industry is slowly learning to do this.
If you're talking business application or server-side programming, then
sure - multiple CPUs does a make big difference. Always has. I'm not
disputing that.

Did you read the article from that link?

Tim Sweeny said "Writing multithreaded software is very hard".

Even John Carmack and Gabe Newel have expressed concerns about multicore
technology (primarily due to the massive learning curve).

These guys are heavyweights in the gaming development industry who
really know their stuff.

Dude, if I find out Quake 4 is written in VB.NET, then I'll become a
VB.NET convert overnight, and then proceed to convert the rest of my
Unix comrades.

 

[nobody]

Errr.... oookaaay.

Free plug for C# or VB.NET.

But, I'm not quite sure how it relates to the issue?

I've also written threaded programs (albeit in Java). Being able to
write multi-threaded code is not the issue.

The issue was whether or not game developers "... know how to code dual
(or quad, or more) threaded games...", in reference to multi-core CPUs.
My stance is that the gaming industry is slowly learning to do this.
If you're talking business application or server-side programming, then
sure - multiple CPUs does a make big difference. Always has. I'm not
disputing that.

Did you read the article from that link?

Tim Sweeny said "Writing multithreaded software is very hard".

Even John Carmack and Gabe Newel have expressed concerns about multicore
technology (primarily due to the massive learning curve).

These guys are heavyweights in the gaming development industry who
really know their stuff.

Dude, if I find out Quake 4 is written in VB.NET, then I'll become a
VB.NET convert overnight, and then proceed to convert the rest of my
Unix comrades.

Surely Q4 or any upcoming game title for that matter will NOT be
written in any of .NET languages. Yet computers exist and are bought
not because of and not exclusively for games. If that was the case, a
console for a fraction of the price would be better solution. It's the
ability to run general apps that makes a PC worthwhile. Business
apps, OTOH, are migrating to .NET in droves. Need a proof? The app
I'm supporting has, among other features, links to third party sites.
Every now and then I have to update these links and guess what? every
time it is about replacing .cfm or .php or .plx or sometimes even .jsp
and .asp to, you guessed it, .aspx. It was never .aspx or .asp to
something non-Microsoft.
As to what multithreading can do for apps, witness Nero. Their 6.0,
when encoding video, would hog 100% of one CPU while the other stands
by idling (I'm running dual Opty). 6.6 changes the picture
drastically - now both CPUs are loaded on average 90% each (I guess
the limit now is the disk write speed), and seems that things are
faster more than twice.
And, back to games, I highly doubt Q4 would run under any flavor of
*nix, including Linux. Even if it will, it will be released
significantly later than Windows version, and it will be lower
framerate at lesser video settings on the same hardware. No, I am not
trying to convert you to forsake the blessed realm of UNIX for the
cursed kingdom of unclean Bill. UNIX still has its place in big tin,
though x86/Windows already started nipping on its heels.
Rgds,
NNN

 

[Douglas Bollinger]

On Sat, 17 Sep 2005 00:39:52 +0000, (e-mail address removed) wrote:

And, back to games, I highly doubt Q4 would run under any flavor of *nix,
including Linux. Even if it will, it will be released significantly later
than Windows version, and it will be lower framerate at lesser video
settings on the same hardware. No, I am not trying to convert you to
forsake the blessed realm of UNIX for the cursed kingdom of unclean Bill.
UNIX still has its place in big tin, though x86/Windows already started
nipping on its heels. Rgds,
NNN

Uhh, yeah. Actually, you are a 100% wrong here. Quake is id's franchise,
and that particular game producer is remarkable in the amount of support
they provide Unix and Linux in particular. Right now, from Doom 1 to the
latest game they produce, Doom 3, and all the games inbetween, they have
either a native Linux or Unix client. The first Doom-engine games and
Quake 1, 2, 3 have all been open-sourced and have native clients available
for many Unixes beside Linux.

Quake 4 is based the Doom 3 technology and I would be very surprised if a
native Linux client isn't available.

Also, on my hardware with same configs, the Windows and Linux Doom 3
clients are about 1 fps apart in timedemos. In you arguement, replace Q4
with HL3 and you will be back on track.

And, hey, just to bring it all full circle, I'm typing this on a SMP box
I've had for years.

 

[Daniel]

Surely Q4 or any upcoming game title for that matter will NOT be
written in any of .NET languages. Yet computers exist and are bought
not because of and not exclusively for games. If that was the case, a
console for a fraction of the price would be better solution. It's the
ability to run general apps that makes a PC worthwhile. Business
apps, OTOH, are migrating to .NET in droves. Need a proof? The app
I'm supporting has, among other features, links to third party sites.
Every now and then I have to update these links and guess what? every
time it is about replacing .cfm or .php or .plx or sometimes even .jsp
and .asp to, you guessed it, .aspx. It was never .aspx or .asp to
something non-Microsoft.
As to what multithreading can do for apps, witness Nero. Their 6.0,
when encoding video, would hog 100% of one CPU while the other stands
by idling (I'm running dual Opty). 6.6 changes the picture
drastically - now both CPUs are loaded on average 90% each (I guess
the limit now is the disk write speed), and seems that things are
faster more than twice.
And, back to games, I highly doubt Q4 would run under any flavor of
*nix, including Linux. Even if it will, it will be released
significantly later than Windows version, and it will be lower
framerate at lesser video settings on the same hardware. No, I am not
trying to convert you to forsake the blessed realm of UNIX for the
cursed kingdom of unclean Bill. UNIX still has its place in big tin,
though x86/Windows already started nipping on its heels.
Rgds,
NNN

[Sigh] - 'tis time for me to get off this particular very well-ridden
bus. I might get back on if you ever decide to return the issue -
assuming you even understand what it is.

Enjoy your crusade NN.

[...sits on the fence, awaiting the UNIX hordes to arrive...]

 

[nobody]

On Sat, 17 Sep 2005 00:39:52 +0000, (e-mail address removed) wrote:



Uhh, yeah. Actually, you are a 100% wrong here. Quake is id's franchise,
and that particular game producer is remarkable in the amount of support
they provide Unix and Linux in particular. Right now, from Doom 1 to the
latest game they produce, Doom 3, and all the games inbetween, they have
either a native Linux or Unix client. The first Doom-engine games and
Quake 1, 2, 3 have all been open-sourced and have native clients available
for many Unixes beside Linux.

Quake 4 is based the Doom 3 technology and I would be very surprised if a
native Linux client isn't available.

Also, on my hardware with same configs, the Windows and Linux Doom 3
clients are about 1 fps apart in timedemos. In you arguement, replace Q4
with HL3 and you will be back on track.

And, hey, just to bring it all full circle, I'm typing this on a SMP box
I've had for years.

I may be wrong 100%, but I am not alone there: "Doom3 for Linux stays
competitive with Doom3 for Windows, but in several instances, it falls
more than 25% behind". For full article go to
http://www.anandtech.com/printarticle.aspx?i=2241 . Considering that
Anand is a big advocate for Linux, that admission speaks for itself.
Just as you, I am typing this on an SMP box I've also had for more
than a year.
Rgds,
NNN

 

[Nate Edel]

time it is about replacing .cfm or .php or .plx or sometimes even .jsp and
.asp to, you guessed it, .aspx. It was never .aspx or .asp to something
non-Microsoft.

I've seen plenty of sites go from .asp to .jsp (including at my old company,
though that was 2002-ish so very old news), and a few drop .asp for .php.

 

[Douglas Bollinger]

I may be wrong 100%, but I am not alone there: "Doom3 for Linux stays
competitive with Doom3 for Windows, but in several instances, it falls
more than 25% behind". For full article go to
http://www.anandtech.com/printarticle.aspx?i=2241 . Considering that
Anand is a big advocate for Linux, that admission speaks for itself. Just
as you, I am typing this on an SMP box I've also had for more than a year.

That article is almost a year old.

In those eleven months, Nvidia has released several driver revisions that
closed the gap between Linux and Windows. That article uses Linux drivers
6111, whereas I'm using Linux drivers 7676.

Look, I just installed a 6800 in this computer a few days ago and ran some
benchmarks in Windows and Linux just to make sure everything was working
correctly. During the testing, I noticed that the benchmarks were almost
identical. I'm not evangelizing or anything, just relaying a experience.
Believe it or not.

 

[Lawrence D'Oliveiro]

Time for a link:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377&p=4

Quoting Tim Sweeny:
"Writing multithreaded software is very hard; it's about as unnatural to
support multithreading in C++ as it was to write object-oriented
software in assembly language. The whole industry is starting to do it
now, but it's pretty clear that a new programming model is needed if
we're going to scale to ever more parallel architectures. I have been
doing a lot of R&D along these lines, but it's going slowly."

I would say Tim Sweeny knows a bit more about game programming than
either of us.

By the way...

Apache (the world's most popular Web server) is written entirely in C
(not even C++), and it is multithreaded to kingdom come.

 

[digisol]

Depends on what sort of $ your talking, in AUD the 3500 64 bit shoul
do that, if USD the 4g 64 bit may come under $400

Can't be sure of the USD bot the AUD is correct