Why would xenon be so hard to program for?

Npl said:
How would you multithread zipping one File in Java?

I have never tried but it should be possible.
However it shouldn't be very efficient unless the communications between the threads and memory access are lightning fast.

The problem aint multithreading, thats a pretty simple concept. The problem is taking your code and actually split it into as-much-independend-as-possible Parts. The problem is at a much higher level than C++ or Java - its a design problem. For serial Problems (as like zipping since its dependand on previous data ) its nontrivial or even impossible.

I know but i said that the job would be easier,not much easier, with a language such as Java.
Off course the virtual machine or the compiler should be optimised to get much better performance.
 
scooby_dooby said:
It seems like multi-threaded middleware is going to be the key here.

I mean there's no reason each dev should have to reinvent the wheel each time they goto tackle the problem of multithreading geometry and physics(for example), right?

Doesn't it make sens to have game engines that are built to be multi-threaded, where the designers of these engines will tackle each multi-threading issue and devise workarounds as best they can?

Then developers could take these engine's and supplement them with their own tricks/knowledge, without having to rethink every problem from the ground up.

I completely agree.
I don't think developpers asked to have such exotic architectures to work with so both MS and Sony must provide the tool to make games development significantly easier.
After all one of the main reasion why they have chosen those architectures(especially MS) is to reduce their cost.
However their choice shouldn't significanlty increase games development cost and troubles for developpers.
 
Npl said:
How would you multithread zipping one File in Java?
For that particular case, so-called stream processing will work on Cell rather than plain multithreading.
 
ShootMyMonkey said:
You cannot multithread the outer loop of your game but for a few minor things (like ambient sound and effects playback). Unless you want rendering to lag behind physics for a frame, you can't run physics and "geometry" in parallel. Physics tells you where everything is... AI tells you where the bots are. The rather nebulous term of "game code" will include telling you about positions of player, camera, what animations will be playing, sound/graphical effects that should be triggered at some point, messages passed around from object to object and machine to machine.
If you are all right with letting certain computations lag behind others, you have to be sure to buffer off several copies of world states. Object transforms, bounding boxes, no big deal. Bone transforms of each and every skinned object... ha... And if anything, accessing memory on Xenon can be considered a capital offense punishable by 13 forms of torture.

So is the cell architecture better suit for multithread gaming as you have the main core which will could deal with AI,physics and geometry and using the SPE to help it for floating point intensive operations and other stuff like that ?
 
Java_man said:
So is the cell architecture better suit for multithread gaming as you have the main core which will could deal with AI,physics and geometry and using the SPE to help it for floating point intensive operations and other stuff like that ?

Well that would be the theory. It's all to be seen how things actually turn out, and how tappable all that power is.
 
It seems there is going to be more attention paid towards data access, I wonder if this will lead to threads being created more around what data they access rather than the logical concerns they address.
 
london-boy said:
Well that would be the theory. It's all to be seen how things actually turn out, and how tappable all that power is.

Then perhaps it is possible to do the same with the XeCPU.
One core to play the role of the PPE and another or the two others to help it.
However there would be the problem of the communication between the cores which can't be as fast as the Cell's.
Sometimes i seriously wonder if MS has really taken the time to develop the best CPU solution possible or if they have just decided to surf on the mutithreading wave,to overeact to the Cell FP power and especially to reduce their cost by all the means.
 
Last edited by a moderator:
Java_man said:
Then perhaps it is possible to do the same with the XeCPU.
One core to play the role of the PPE and another or the two others to help it.
However there would be the problem of the communication between the cores which can't be as fast as the Cell's.
Sometimes i seriously wonder if MS has really taken the time to develop the best CPU solution possible or if they have just decide to surf on the mutithreading wave,overeact to the Cell FP power and especially try to reduce their cost by all the means.

The shared L2 on X360 is pretty hard to beat for communication speed.....
 
Back
Top