How many developers are using all 3 cores for X360?
- Thread starter onetimeposter
- Start date
Lysander said:
in deed. Basically, "whats left from the CELL deal"-garbage with alot of weak points, especially a shared cache for three cores which already seems to be a serious limitation according to the AGEIA people (cache issues)
It's far from executin 3 Threads independently as stated by Microsoft (not to speak about 6, that's total bs).scificube said:
I always wondered about that quote.
EDITED: while Titanio was writing
the XeCPU would be 3 (core)X (2 threads @1.6)?
wouldnt the Cell then be 1 core (2 threads@1.6) + 7 cores@3.2?
Makes no sense to me...
Last edited by a moderator:
randycat99
Veteran
The whole 2x1.6 Ghz idea is predicated on 2 threads getting "equal-time" on the actual execution process. A goes, then B, then A, and so on... Conceptually, it could operate anywhere between 2x1.6 Ghz to 1x3.2 Ghz at a given moment, depending on just how "hungry" a particular thread ends up being. You can design hardware for 2 threads or 2 "gazillion" threads, but it's always got to shoehorn into the same one core. There is no extraction of magical clock cycles of execution from thin air. You are simply maximizing useage of the finite handful of execution cycles that the hardware can facilitate.
Last edited by a moderator:
randycat99 said:
I'm slightly confused by this, but it's an issue I've wondered about for a while so..
..what's the distinction between a core/cpu with support for 2 "hardware" threads vs a core/cpu that supports only 1 "hardware" thread but just switches between software threads? Does it just provide for faster switching between two threads or..?
Uh, PPE is build from Power5 chip, that is no garbage.
Cache could be limited for stupid software makers; but chip has an ability that its data circumvent cache (L1,L2,both) and go straight to gpu and system memory.
And yes threads should be autonomous, according to X2 patent. (but how, that is the question)
randycat99
Veteran
Titanio said:
Functionally, they accomplish a very similar effect- it's just the thread granularity is taken 1 step closer to the hardware when it comes to "hardware threads" (I guess "in the hardware" would be a better description). We are digging deeper into the hardware itself to recover "unused" execution cycles.
I posted a lengthy explanation but the browser hung.
The functional unit (like a VMX unit) work on registers. With one set of registers when you context switch to another thread, the contents of those registers need to be saved out to record the current progress of the thread. When the thread is switched back in thread 2's contents need to be saved out and thread 1's loaded back in. This uses up cycles in preparing to continue where the thread left off. Hardware support has extras registers (and maybe other stuff) so each of the two threads has it's current state permenantly to hand so the moment a cycle is free is use the thread can jump right in.
The functional unit (like a VMX unit) work on registers. With one set of registers when you context switch to another thread, the contents of those registers need to be saved out to record the current progress of the thread. When the thread is switched back in thread 2's contents need to be saved out and thread 1's loaded back in. This uses up cycles in preparing to continue where the thread left off. Hardware support has extras registers (and maybe other stuff) so each of the two threads has it's current state permenantly to hand so the moment a cycle is free is use the thread can jump right in.
randycat99 said:
Not really the 2x1.6 thing is a conceptual idea to try to make it easier to get good performance out of the cores.
Basically the principal is that the instruction and memory latencies on the cores are such that it's hard to hide them, but if you consider it as two processors with half the core speed you only have to hide half of the latency.
It's probably not a bad idea to treat Xenon cores the same way. They have more registers than the PPE's, so can potentially hide more latency, but IME optimisations in the running code become less and less significant as the thread count goes up everything ends up dominated by communications and even crappy code runs just as fast as the hand optimised stuff.
randycat99
Veteran
Naturally, there will be perks to exploit all over the place. I think it still comes down to the same thing, in the end- maximizing the utilization of a finite number of execution cycles. How you do it...that is where you have all those different methods and perks to wield.
Titanio said:
A thread context switch is really expensive in software, but cheap in hardware.
You could (on a PC) burn thousands and thousands of cycles on a software managed context switch between two threads in pretty much any of the modern OSes. You could do somewhat better by switching to a special purpose RTOS or tossing the OS entirely and running on the bare metal.
But in hardware like a hyperthreaded P4, you can hardware context switch on the next cycle between two threads, because all the register state is duplicated on chip between them.
Basically, software context switching is a way to make the CPU appear to run more than one thing from the user's point of view. Humans operate on the "tens of milliseconds" time scale at best, so blowing thousands of cycles on a context switch doesn't really mean a whole lot.
But hardware context switching is a technique to recover wasted execution cycles from the CPU's point of view by having something else immediately ready to run and use the idle execution units.
Last edited by a moderator:
aaaaa00 said:
Cheers very much!
So there's no duplication of execution hardware? It's just about the switching? 3 threads executing at any one time, or can more execute if they use mutually exclusive sets of execution units?
edit - Also, if you have a pool of software threads you're switching between, with 6 of them in hardware, is it as expensive to switch one of the "software threads" into hardware as it is for a non-MT core to switch between software threads?
Which leads to the question, would you be ill-advised to use more threads in your application than you can keep "in hardware"?
Last edited by a moderator:
Titanio said:
You generally need to experiment with this and tune things.
If you have a bunch of tasks that very rarely wake up and are roughly independent of other things in your engine, then it may be cleaner to set aside one hardware thread, and put all of these tasks onto seperate software threads which will be scheduled onto that hardware thread when they need to run.
I can think of audio as a reasonably good candidate for something like this. Audio tends to operate on the human "tens of milliseconds" scale, and people just won't be able to tell the difference in latency when buffering ahead a frame. So architecturally, it may be cleaner in your engine to just have a software scheduled thread that fires and does the sound processing. Other things may work too, like network, disk I/O, user input scanning, etc.
But typically you want to stick to the number of hardware threads you have in your system, be it 2, 6, 100 or whatever.
Last edited by a moderator:
therealskywolf
Regular
Nemo80 said:
Yes but its VMX 128. The cores in Xenon are considerably more robust than the single core in the PPE.