Idea: (Dual) Dual core 265 Opterons on the cheap

D

Dr. Ffreeze

Regular
Hello All,

Prices just dropped and some of us got thinking. It would be cool to fire up a MSI K8N Master2-FAR ($249) with daul 265 Opterons ($345). For not much money (well, sorta) you could snag a quasi-quad core now. Lots of room for lots-o RAM. Not too excited about SLI. Only 1 1x PCI-E slot. Only 1 PCI slot. Only 1.8GHz CPU clocks. I wonder if any gaming and/or any consumer video editing apps would benifit.

Any thoughts,
Dr. Ffreeze
 
Last edited by a moderator:
There are very few apps, I think, that would benefit from four cores. The only activities I can think of would be 3D rendering, encoding media streams and some music sequencing/ DAP.

Gaming wise, there are probably none (the very few that are SMP aware would have a job loading two cores, never-mind four, I reckon).

The only situation I can think of where you would benefit is if you are running a server with lots of multi-threaded events (eg. webserver).

One day this will all change, but I don't think the day is there yet. Dual-core, though, would be a wise choice even now. IMO, of course :)
 
Diplo said:
There are very few apps, I think, that would benefit from four cores. The only activities I can think of would be 3D rendering, encoding media streams and some music sequencing/ DAP.

Gaming wise, there are probably none (the very few that are SMP aware would have a job loading two cores, never-mind four, I reckon).

The only situation I can think of where you would benefit is if you are running a server with lots of multi-threaded events (eg. webserver).

One day this will all change, but I don't think the day is there yet. Dual-core, though, would be a wise choice even now. IMO, of course :)
Click to expand...
Ill agree, although i think that by end of the year, many games/software programs will be taking advantage of multi-core setups.

epic
 
depending on how they abstract their game architectures, it shouldn't be too hard to go multi core. i've converted some applications (batch...lots of data independance) on sequent symmetry (SMP) boxes before. and they were auto scalable. didn't matter whether there were 2 or 22 cpu's available. i assume multi core behaves this way. i didn't even need parallel compilers, libs, etc.

is there a standard gaming architecture (for say FPS)? (im guessing no at this point). is there lots of data/functional independance (im guessing yes).

hey if i can do it, anyone can!
 
Last edited by a moderator:
Well, in order to make things scalable across many cores, you need to have the majority of your processing time parallelizable.

That is to say, if you have a game where 50% of the code is parallelizable (both with itself and the single-threaded-only code), then you could at most make optimal use of two cores. If you have a game where 75% is parallelizable, then you could easily make use of four cores.

So, in the end the real solution to supporting more cores comes down just to adding parallelizable processing (like physics, AI). But with so many single-core machines, I doubt that devs will put that much emphasis in even dual-core just yet, let alone quad-core.
 
well i was doing batch billing, so i had heavy data independance (per customer), heavy functional dependance on all the operations that went into computing the bill for a customer, gathering charges, computing taxes, etc (no help there really). then their respective accounting report results, bills, etc were rejoined on the back end to be totalled and whatnot. i was like king of the joint for about 10 minutes. then they sued me.

i started with a single thread batch app. and packaged it to fork off processes that handled a certain number of customers each (computed with some pre accounting).

is there a high level (segments of screen maybe?) easy peasy way to multithread a game like that. are there elements at some level that are completely data independant (left upper, right upper...)? as opposed to functional (you do physics, you do NPC admin, you do graphics)

i was sort of assuming so, like maybe that's how crossfire/sli (though 2 approaches) cheaply pulled off their stunt.
 
Last edited by a moderator:
Well, you can always pipeline one or more of the functions to make for functional independence, like physics. This would be the primary method of making sure that your single-threaded-only code runs in parallel with the parallelizable code. That said, you wouldn't want to have too much pipelining, as you want to keep it interactive (one frame should be good enough, though, and with smart programming you might even get away with less than a full frame of latency).

But now what sorts of code are easily parallizable? Well, physics is easy: you just split up your world into boxes, calculating the physics for each box independently. There may be a little bit of "clean up" work at the end for fast-moving objects that move between these boxes, but it shouldn't be that bad.

AI could be parallelized even more easily, as you could calculate the AI behavior for this frame independently for each and every AI actor. Sure, you could send messages between AI actors for them to receive next frame to get interactions between AI actors, but there's no reason why you can't have a one-frame delay.
 
and it would be auto scalable right? like my batch process was? detected the number of cpu's you had, then depending on limits you might setup beforehand forks off the number of processes you have.

i was thinking a (some) game(s) just may lend themselves to that very simple way of taking advantage of multithreading...as opposed to rewriting all the little bits and using parallel compilers and libraries and all those gizmos. the same game runs fine whether on single or multi core.

and you don't even need a game app genius to do it.

my app was written in C for unix initially.
 
Well, sure, but the game content also has to be developed to use enough processing power in the parallelizable stuff. Otherwise you'll just be limited by the single-threaded-only processing.
 
You must log in or register to reply here.
Back
Top