..If the G6 is announced I will perform a intimate act with JYD...<hr></blockquote>
I'm sure our favorite Wiener Dr. Freud would have something to say about that, but he's dead so I won't hold my breath.
I think it's time we all take a 45-second break with our significant other / spouse / 1-900-dial-a-freak / gerbil / teen-idol-of-the-week poster before posting about things that start with the letter A or G.
Because it is expensive. I don't know the specs on Sun's bus offhand, but it is probably fast and wide which makes the boards and chips quite costly to produce. The bus interface has to be built into each processor in a shared bus system. Also, the farther you spread a bus, the slower it is going to get -- do you have a link to specs on Sun's bus, I'm curious what they have.
A NUMA will generally be faster as long as a processor can work out of its local pool most of the time. </strong><hr></blockquote>
Question: Would it be possible to address some of these design expenses/challenges by using daughter cards?? Where each daughter card would have its' own memory MaxBus 133 or 166 and cache and a shared pipe RapidIO to the system chip, for disk access, firewire access, and other services. Adding capacity would mean adding more daughter cards. You would add capacity by adding daughter cards to the RapidIO Bus. There by avoiding having to design one board with multiple memory paths. Just using RIO to the system chip and the daughter cards for communication. The system chip could have some memory as well to boost disk performance, and other communication tasks. Also I guess that RapidIO would be the conduit that would allow the processors to talk to each other. I would imagine that to make design easier that the cards would be sold with a set amount of memory and if one wished to have more they could add it the whole system, like in XServe, but if each processor had 256MB or 512MB than there may not be that much chatter for memory access through the system chip.
Question: Would it be possible...<hr></blockquote>
I suspect you'd want to remove all traces of the MPX and integrate the memory controllers into the processors before attempting what you are suggesting. I don't know if RapidIO can be routed across slot connectors (electrical issues?) but otherwise your description isn't far from what is outlayed on RapidIO.org.
Take a greyscale bitmap at 800x600 at 8bits per pixel and you get @3840000 bits.
Assume your applying a brightness filter. You would get 16 pixels into the 128bit altivec register at 8bits each. You would have to cycle through this @30000 times to change the brightness of the whole pick. Are you saying that there is no way to easily queu the altivec unit for width and simply feed more bits in if possible. If there isn't an autoFitToWidth facility, do you think it would take a programmer long to adapt to the larger width? Seems to me that if altivec is so good they would have made provisions for this.
Everyone is saying Altivec is starved for bandwidth. Does this mean it can't get enough bits per cycle from main memory or that it cant send them back quick enough, or both? Do all operations need to be shuffled through the 32bit cpu on their way back to main memory? Would that effectively cripple altivec to 1/4 its possible usage per cycle?
More FP units would definately help out in the 3D benchmarks .
<strong>Take a greyscale bitmap at 800x600 at 8bits per pixel and you get @3840000 bits.
Assume your applying a brightness filter. You would get 16 pixels into the 128bit altivec register at 8bits each. You would have to cycle through this @30000 times to change the brightness of the whole pick. Are you saying that there is no way to easily queu the altivec unit for width and simply feed more bits in if possible. If there isn't an autoFitToWidth facility, do you think it would take a programmer long to adapt to the larger width? Seems to me that if altivec is so good they would have made provisions for this.</strong><hr></blockquote>
AltiVec, like all current SIMD execution units on the market today, uses a fixed length vector. All code is written with this vector length as an assumption. Changing the vector length means creating a new version of this code to use on machines with the new unit (keeping the old code around for older machines) and replacing all of the implicit assumptions about vector length with new assumptions about vector length. And these aren't obvious in the code all the time, so there is an extensive debug/test cycle involved. If, instead, Moto/Apple/IBM simply double the speed of the current AltiVec unit then all existing code still runs but it goes twice as fast.
Software development is expensive and slow -- forcing developers to re-do things they have already done is generally a bad idea. Creating multiple standards to code for complicates things and fragments the market. The AltiVec instruction set is damn good, and I'm sure more speed can be obtained without breaking all the software!
<strong> [quote]
Everyone is saying Altivec is starved for bandwidth. Does this mean it can't get enough bits per cycle from main memory or that it cant send them back quick enough, or both? Do all operations need to be shuffled through the 32bit cpu on their way back to main memory? Would that effectively cripple altivec to 1/4 its possible usage per cycle?</strong><hr></blockquote>
Both. The CPU isn't 32-bit, the integer units are. Data from the vector unit goes to/from the load/store unit in units of 128-bits (or is it 256 bits?). The problem is not within the chip -- Moto has done a good job of that. The problem is simply that the bus protocol is 133 MHz x 64-bits.
<strong> [quote]
More FP units would definately help out in the 3D benchmarks </strong><hr></blockquote>
Would it be really difficult to add a couple of fpus to the G4's solitary one?
If moto have lost further PPC contracts for desktop cpus then why bother? Just up the mhz on .13 wait until the contract expires for the AIM alliance? Then sod off and focus on their embedded space?
Even at 1.33 mhz then the G4 won't look too bad.
I don't mind the low mhz but the G4 has low fpu, low mhz, low ram speed and low bus speed compared to its competition...
Assume your applying a brightness filter. You would get 16 pixels into the 128bit altivec register at 8bits each. You would have to cycle through this @30000 times to change the brightness of the whole pick.
Comments
<strong>
BIG ol' difference between UHF frequencies & CPU clock cycles.... <img src="graemlins/oyvey.gif" border="0" alt="[No]" /> </strong><hr></blockquote>
I still remember when everyone was freaking about 100Mhz busses and the problem of avoiding FM Radio interference.
..If the G6 is announced I will perform a intimate act with JYD...<hr></blockquote>
I'm sure our favorite Wiener Dr. Freud would have something to say about that, but he's dead so I won't hold my breath.
I think it's time we all take a 45-second break with our significant other / spouse / 1-900-dial-a-freak / gerbil / teen-idol-of-the-week poster before posting about things that start with the letter A or G.
[quote] <strong>Originally posted by Programmer:
Because it is expensive. I don't know the specs on Sun's bus offhand, but it is probably fast and wide which makes the boards and chips quite costly to produce. The bus interface has to be built into each processor in a shared bus system. Also, the farther you spread a bus, the slower it is going to get -- do you have a link to specs on Sun's bus, I'm curious what they have.
A NUMA will generally be faster as long as a processor can work out of its local pool most of the time. </strong><hr></blockquote>
Question: Would it be possible to address some of these design expenses/challenges by using daughter cards?? Where each daughter card would have its' own memory MaxBus 133 or 166 and cache and a shared pipe RapidIO to the system chip, for disk access, firewire access, and other services. Adding capacity would mean adding more daughter cards. You would add capacity by adding daughter cards to the RapidIO Bus. There by avoiding having to design one board with multiple memory paths. Just using RIO to the system chip and the daughter cards for communication. The system chip could have some memory as well to boost disk performance, and other communication tasks. Also I guess that RapidIO would be the conduit that would allow the processors to talk to each other. I would imagine that to make design easier that the cards would be sold with a set amount of memory and if one wished to have more they could add it the whole system, like in XServe, but if each processor had 256MB or 512MB than there may not be that much chatter for memory access through the system chip.
[ 07-04-2002: Message edited by: Brendon ]
[ 07-04-2002: Message edited by: Brendon ]
[ 07-04-2002: Message edited by: Brendon ]</p>
Indulge me while I re-ask a question:
Question: Would it be possible...<hr></blockquote>
I suspect you'd want to remove all traces of the MPX and integrate the memory controllers into the processors before attempting what you are suggesting. I don't know if RapidIO can be routed across slot connectors (electrical issues?) but otherwise your description isn't far from what is outlayed on RapidIO.org.
Assume your applying a brightness filter. You would get 16 pixels into the 128bit altivec register at 8bits each. You would have to cycle through this @30000 times to change the brightness of the whole pick. Are you saying that there is no way to easily queu the altivec unit for width and simply feed more bits in if possible. If there isn't an autoFitToWidth facility, do you think it would take a programmer long to adapt to the larger width? Seems to me that if altivec is so good they would have made provisions for this.
Everyone is saying Altivec is starved for bandwidth. Does this mean it can't get enough bits per cycle from main memory or that it cant send them back quick enough, or both? Do all operations need to be shuffled through the 32bit cpu on their way back to main memory? Would that effectively cripple altivec to 1/4 its possible usage per cycle?
More FP units would definately help out in the 3D benchmarks
<strong>Take a greyscale bitmap at 800x600 at 8bits per pixel and you get @3840000 bits.
Assume your applying a brightness filter. You would get 16 pixels into the 128bit altivec register at 8bits each. You would have to cycle through this @30000 times to change the brightness of the whole pick. Are you saying that there is no way to easily queu the altivec unit for width and simply feed more bits in if possible. If there isn't an autoFitToWidth facility, do you think it would take a programmer long to adapt to the larger width? Seems to me that if altivec is so good they would have made provisions for this.</strong><hr></blockquote>
AltiVec, like all current SIMD execution units on the market today, uses a fixed length vector. All code is written with this vector length as an assumption. Changing the vector length means creating a new version of this code to use on machines with the new unit (keeping the old code around for older machines) and replacing all of the implicit assumptions about vector length with new assumptions about vector length. And these aren't obvious in the code all the time, so there is an extensive debug/test cycle involved. If, instead, Moto/Apple/IBM simply double the speed of the current AltiVec unit then all existing code still runs but it goes twice as fast.
Software development is expensive and slow -- forcing developers to re-do things they have already done is generally a bad idea. Creating multiple standards to code for complicates things and fragments the market. The AltiVec instruction set is damn good, and I'm sure more speed can be obtained without breaking all the software!
<strong> [quote]
Everyone is saying Altivec is starved for bandwidth. Does this mean it can't get enough bits per cycle from main memory or that it cant send them back quick enough, or both? Do all operations need to be shuffled through the 32bit cpu on their way back to main memory? Would that effectively cripple altivec to 1/4 its possible usage per cycle?</strong><hr></blockquote>
Both. The CPU isn't 32-bit, the integer units are. Data from the vector unit goes to/from the load/store unit in units of 128-bits (or is it 256 bits?). The problem is not within the chip -- Moto has done a good job of that. The problem is simply that the bus protocol is 133 MHz x 64-bits.
<strong> [quote]
More FP units would definately help out in the 3D benchmarks
It would help in a lot of math intensive code.
Would it be really difficult to add a couple of fpus to the G4's solitary one?
If moto have lost further PPC contracts for desktop cpus then why bother? Just up the mhz on .13 wait until the contract expires for the AIM alliance? Then sod off and focus on their embedded space?
Even at 1.33 mhz then the G4 won't look too bad.
I don't mind the low mhz but the G4 has low fpu, low mhz, low ram speed and low bus speed compared to its competition...
Thoughts?
Lemon Bon Bon
<strong>...
Assume your applying a brightness filter. You would get 16 pixels into the 128bit altivec register at 8bits each. You would have to cycle through this @30000 times to change the brightness of the whole pick.
...
</strong><hr></blockquote>
The Altivec has 32 128b registers, not one.
So the answer is 937.
POWER=Performance Optimised With Enhanced RISC (RISC=Reduced Instruction Set Computer)
At least that's the case with IBM's POWER chip...I guess Apple just used the word instead of the acronym...