[RJARRRPCGP]

I have been wondering if it's even possible to link at least 2 PCs with cat5 to make a CPU cluster?

But, can cat5 bottleneck it? It sometimes would seem if the latency is good then it would be good.

Example: Core 2 Duo E4500 and E2180 teamed together for at least double of the usual FPS.

[Bobnova]

Depends on what you want to do.
To run a beowulf you have to use very specific *nix based OS's, at that point whether it scales at all depends on the sort of calculation you're doing, cat5 will do a gigabit easily enough on short runs, but that is only 125mb/second.
Compare that to ram access: My very slow e5200 has around 3500mb/second.

[RJARRRPCGP]

Originally Posted by Bobnova

Depends on what you want to do.
To run a beowulf you have to use very specific *nix based OS's, at that point whether it scales at all depends on the sort of calculation you're doing, cat5 will do a gigabit easily enough on short runs, but that is only 125mb/second.
Compare that to ram access: My very slow e5200 has around 3500mb/second.

But, was wondering if it would benefit the core arithmetic processing and L1 caching. I know that it would bottleneck L2.

(In other words, stuff that isn't L2 cache oriented)

Could it at least help with integer performance?

[Bobnova]

Not really, it has to send the data over a very slow bus to get it done, if the program is waiting for a result it will have to wait microseconds for a result instead of nanoseconds.

[Neuromancer]

Not good for gaming no.

L1 cache is faster than L2 BTW... (IE it is the FIRST cache that the CPU looks at...)

[freakdiablo]

Another vote for not good for gaming. It may be the equivalent of the game running out of the paging file as it sends data to the second computer and waits for it to be processed and sent back. Might be better off into selling off the dual core and looking into a cheap quad core if you were looking into teaming the two dual cores, would be faster and probably easier to do.

[RJARRRPCGP]

Originally Posted by Neuromancer

Not good for gaming no.

L1 cache is faster than L2 BTW... (IE it is the FIRST cache that the CPU looks at...)

That's what I mean, the L1 cache don't require as big amounts to transfer as L2.

(At least, it should work for games that are processor-heavy, but not size-heavy) (Usually older games)

(Example, a game with many small polygons and not monstrous texture sizes that also hardly use the GPU)

But, can cat5 send data at less than 0.5 ms? (I won't use long cat cable)

And I dunno about floating-point stuff, but may work nicely with integer calculations, and if not, it may help with old emulated games, where a second unit could offload some CPU work.

Could this help with emulating Goldeneye? (Nintendo 64)

Emulating Goldeneye is processor intensive enough that running pure interpreter could possibly be a stability tester!

And Goldeneye, CPU wise is already a struggle, it takes at least about 2.6 ghz to stop the FPS-yo-yo'ing!

I sure wish that I can find another way of linking them?

Preferably off the PCI bus.

Dang, maybe this is only good for internet applications.

[Bobnova]

There aren't any games that will work better on a beowulf.
If you're lucky they won't slow to a crawl.
That's ignoring the fact that i doubt you could even get them to run on an OS that supports beowulfing.

Your best bet by far is to buy a better cpu.


On cache:
L1 is small, yes, but it is also amazingly fast, it only takes one to three cycles to get something into or out of it, and it has astronomical bandwidth.
L2 is bigger and slower, but still very very fast.
L3 is bigger and slower, but still very fast.
Ram is bigger still and slower still, but still fast.
The communication between beowulf clusters is on the order of hard drives. Very slow.

It's great for things that can run individually, but if data needs to be communicated between cores (and it does, for games) forget it.

[Khemikal]

When setting up a cluster you need to have software to run on it. Off the shelf games will not. Most of the times you will be making in-house software to run on them. What makes them useful is to run on problems that can be chopped up into lots and lots of chunks that don't rely on each other (within reason, basically talking parallel coding). Most games are not like this. There are situations like physics simulation and weather simulation where each particle gets its next state based on the ones around it and thus each system can calculate the next step of each particle based on the current state of the surrounding ones. But in a nutshell games are not coded to be run on clusters, and probably never will be. People don't have clusters sitting around for personal gaming, so there is not target audience to spend the time coding for them.

As for the networking end, you would want to minimize the hops between two machines to 1 if at all possible. Go check out the Flat Neighborhood Network (FNN) network topology they have done research on at the Univ of Kentucky. Using this they set some processing power/cost records back in the early 2000s with some customized routing equipment and their network topology. This is why I started college out at UK until the professor decided to take some time off from teaching (no need to pay out of state tuition if the professor isn't there, so I went back home for in-state).

[RJARRRPCGP]

Originally Posted by Khemikal

When setting up a cluster you need to have software to run on it. Off the shelf games will not. Most of the times you will be making in-house software to run on them. What makes them useful is to run on problems that can be chopped up into lots and lots of chunks that don't rely on each other (within reason, basically talking parallel coding). Most games are not like this.

But, can emulating complex systems, like the Nintendo 64 benefit from this?

I was wondering if using this for parallel computations would benefit emulating complex gaming systems?

For a future recompiler?

With a future emulator?

Nintendo 64 is still overwhelming enough to possibly overwhelm a Core i7 with pure interpreter.

But, the current problem: I'm not even aware of ANY Nintendo 64 emulator that can use more than 1 core!

***RJARRRPCGP waits for a future version of Mupen64, 1964 and PJ64.

[Bobnova]

I doubt there ever will be one, the N64 only has one core so all the games are written for one core. Can't spread that over two cores.

[RJARRRPCGP]

Originally Posted by Bobnova

I doubt there ever will be one, the N64 only has one core so all the games are written for one core. Can't spread that over two cores.

I'm waiting, because the latest version of most Nintendo 64 emulators, were released in 2003 and 2005.

I'm hoping for some work to be divided to another core.

Then it's possible for Goldeneye to keep a steady FPS, even with tons of guards and shooting.

[Khemikal]

I'll try and make this short, sweet, and hopefully not too forward and mean sounding. Bob is correct, your N64 games should have no problem running on the new hardware that is out now. If they aren't, it is simply the fault of the emulator code being poorly designed and implemented.

You seem to be mixing either terminology or thoughts/ideas up. An N64 game is no where near a complex system. Clusters are designed to be relatively cheap supercomputers. They are built because the programs/problems they work on are able to be chopped up and worked on as separate parts then reassemble those parts back together. They do this because running the same code on hardware with only a few cores/threads would take days/weeks/months/years. I mentioned physics and weather simulation because these are the kind of programs designed for supercomputers/clusters. It would take so long to churn out the result of a weather simulation on a single computer that by time it was done, the data would be for a time in the past. A game for the N64 however runs just fine on the hardware they had way back in the day. There is no reason to create a cluster based emulator when a properly coded single processor base code would do the job. Games just aren't the type of problem/program that lends itself well to being massively parallel, and thus they aren't programmed to be run on these types of systems.

[RJARRRPCGP]

The problem is, most of the emulators are socket A era.

So, no optimization for the Phenom and Core processors.