What is bizarre about the semiconductor industry, however, is that there is sort of an ideal physical size where the price/performance/power curve has a knee (i.e. its not a linear function). My guess is that the transistor count of the supposed triple core design is closer to that knee that the single core design. We don't know the shape of that curve so we can't predict the relative costs of these alternatives.
Actually this is exactly what Moore's Law talks about. Generally the optimal size they aim for is around 120 mm^2 (this is just an observation for high performance consumer microprocessors) and with each generational improvement in process technology they can roughly double the transistors in that area. It's worth noting the PPC970 has roughly the same transistor count on the 90 nm process as the 130 nm and is quite substantially below that 120 mm^2 size.
Actually this is exactly what Moore's Law talks about. Generally the optimal size they aim for is around 120 mm^2 (this is just an observation for high performance consumer microprocessors) and with each generational improvement in process technology they can roughly double the transistors in that area. It's worth noting the PPC970 has roughly the same transistor count on the 90 nm process as the 130 nm and is quite substantially below that 120 mm^2 size.
Exactly. "Moore's Law" is so increadibly over-used I don't like to mention it explicitly.
Can't say I'm a great fan of Moore's Law either since it is more often than not misused but it is a general statement about the economics of IC manufacture tacked together with a rough observation of how often new processes are brought online.
Can't say I'm a great fan of Moore's Law either since it is more often than not misused but it is a general statement about the economics of IC manufacture tacked together with a rough observation of how often new processes are brought online.
Yes, I remember being quite surprised when I read the original statement Moore made (as opposed to the large number of interpretations). It was remarkably simple, which is probably why it has remained (approximately) true this long. I read recently even (especially?) Moore was surprised by how well it had held up.
Please pardon my igorance, but I have a question and may word it incorrectly.
With all this talk about multithreading and multicore cpu's, my question is,"Do the three cores have to be identical?" The reason I ask is, if different demands on the cpu could be directed during compiling more easily to separate cores. Since my ignorance of both hardware and software engineering is monumental, the lame examples I'll use will be graphics, physics and sound(other examples may be much more appropriate).
If each core is more or less designed to handle specific tasks, would this make programming multiple threads somewhat easier, or if proper compiler instructions added, even automatic? Possibly, then the space(#'s of transistors) could/may be designed much more efficiently.
Since we're talking about a cpu for xBox Next, which could be specifically designed for gaming, rather than general purpose desktop/workstation computing, does any of the above make any sense?
Please pardon my igorance, but I have a question and may word it incorrectly.
With all this talk about multithreading and multicore cpu's, my question is,"Do the three cores have to be identical?"
No, they don't. In fact, this sort of thing is common in consoles. And Amigas. And, actually, modern Macs - part of OS X now leans on the graphics chip to do work.
Please pardon my igorance, but I have a question and may word it incorrectly.
With all this talk about multithreading and multicore cpu's, my question is,"Do the three cores have to be identical?" The reason I ask is, if different demands on the cpu could be directed during compiling more easily to separate cores. Since my ignorance of both hardware and software engineering is monumental, the lame examples I'll use will be graphics, physics and sound(other examples may be much more appropriate).
If each core is more or less designed to handle specific tasks, would this make programming multiple threads somewhat easier, or if proper compiler instructions added, even automatic? Possibly, then the space(#'s of transistors) could/may be designed much more efficiently.
Since we're talking about a cpu for xBox Next, which could be specifically designed for gaming, rather than general purpose desktop/workstation computing, does any of the above make any sense?
This is a very good question, actually. In general purpose computers there is a lot of benefit to having symmetric cores (hence the term SMP for symmetric multiprocessing) because the software can remain largely ignorant of the particular hardware it is run on, but in specialized hardware like game consoles this isn't as important because the software is custom designed for the hardware. The PS2 has several different kinds of processors -- a MIPS core (two, actually), a couple of vector processors, a DMA engine, and a couple of sound chips. The PS3's Cell architecture is rumoured to have conventional processors with a set of slave vector processors.
What is key in this kind of design is to provide processors which can be used for a wide variety of processors, rather than over-specializing them. GPUs and SPUs are an exception because all games have lots of graphics and sound, but even there the over-specialization can limit what game developers can do (for example, the current DirectX/OpenGL vertex program model means that you can't create/destroy vertices or do inter-vertex optimizations in the GPU itself, whereas PS2 does this quite well because it uses a more general vector processor).
Even if the cores are the same, there is no requirement that the software use them in the same way. Most people tend to assume that a symmetric multi-core processor will just divide up the running pre-emptive threads, but this isn't necessarily the best way to do things.
Thank you all for the responses. My next question concerns the examples I used for multithreading, graphics/physics/sound. Are there more basic ways to separate threads directed toward individual cores.
Taking my example of graphics, I would think this might not be a good example, because graphics cards are very sophisticated and comsume a lot of transistors and ram.
I guess what I'm saying is,"Is there a way in hardware to make programming multithreading easier or automatic? And if so is there any advantage to designing each core for specific purposes?
The only example I can think of at the momment is SIMD, and this still might be a bad example. If say only one core has Altivec/VMX(or maybe two), would it be easier to program, or automate during compiling, directing this thread toward the core with SIMD?
If this all sounds redundent, chalk it up to my lack of knowledge.
I guess I just don't know enough about how threads are generated and controlling multithreading so there aren't a ton of threads stepping on each other. It is an interesting topic though, even for the technologically challenged like me.
I guess what I'm saying is,"Is there a way in hardware to make programming multithreading easier or automatic? And if so is there any advantage to designing each core for specific purposes?
Not really -- the software has to be setup to deal with multiple processors and the specific kinds of processors. The more automatic you make it, the less control developers have over it. Making hardware too specific limits what it can be used for.
GPUs are a good example: they are very specialized to rasterize 2D pixel maps from triangle vertex data and 2D textures. This makes it impossible (or really difficult anyhow) to use their massive floating point capabilities for anything other than the graphics they were designed to do. Curved surfaces, for example, don't do well through a triangle-based GPU. GPUs are getting more and more generalized all the time, first by the introduction of shaders, and now by the ever increasing expressive power of the shaders. Eventually they'll be useable for things which aren't even graphics.
Thank you all for the responses. My next question concerns the examples I used for multithreading, graphics/physics/sound. Are there more basic ways to separate threads directed toward individual cores.
I'm not sure exactly what your asking here. One way to for a thread to be generated for a specific processor is through another thread issuing a call to a system function or library function. Consider your main program that has been built to wrk with a DSP card, it may issue a call that results in code running on the DSP. While I have a hard time describing this as multi threaded you would end up with code running on a specific processor.
Generally you don't want threads going to specific cores or processors, rather you would hope that the OS can manage the correct allocation of resources. Of course there are always cases where an OS would choose a poor allotment of processors.
Quote:
Taking my example of graphics, I would think this might not be a good example, because graphics cards are very sophisticated and comsume a lot of transistors and ram.
I guess what I'm saying is,"Is there a way in hardware to make programming multithreading easier or automatic? And if so is there any advantage to designing each core for specific purposes?
When you say programming automatic I'm not sure what you are asking. There are no limits to what may be added to a processor other than the limit space on the chip. So it is possible to add hardware to a processor to make it a better machine for a multithreaded environment. That won't make anything automatic, but you could make things easier. But that easinees is at a low level and probally not what you are inquiring about.
Quote:
The only example I can think of at the momment is SIMD, and this still might be a bad example. If say only one core has Altivec/VMX(or maybe two), would it be easier to program, or automate during compiling, directing this thread toward the core with SIMD?
If you really wanted to go to all the trouble you probally could get a machine to operate with a AMD and PPC chip on the same board. Beyond a whole bunch of issues you would still need to get the OS to handle sending the right code to the right processor. You could likewise build a PPC system with a processor with SIMD and one with out, still taking into account the required OS work that would need to be done.
I'm not sure why anyone would want to do this though. Such a mix of processors may very well work in a server environment where a large number of threads just need integer operations. But again it is a software issue and one would have to wonder why not implement SMP. Come to think of it some servers do implement intelligent I/O which execute requests from the OS. I have trouble describing that as threading though.
Quote:
If this all sounds redundent, chalk it up to my lack of knowledge.
Questions never hurt though my response above may hurt a bit.
i think it's highly dependany on the APIs. Apparently DirectX10 will be used. DirectX is only on windows so, it could be possible to port the games to windows. But for MacOSX ull have to port DirectX whitch will be preety difficult. If on the other hand they choose to use OpenGl as well...it could theoretically be possible.
If they run it DirectX and run it on a PPC platform, they'll have to port it already anyway. So chances are, they could port DirectX to Mac OS X along with the games.
Comments
Originally posted by Programmer
What is bizarre about the semiconductor industry, however, is that there is sort of an ideal physical size where the price/performance/power curve has a knee (i.e. its not a linear function). My guess is that the transistor count of the supposed triple core design is closer to that knee that the single core design. We don't know the shape of that curve so we can't predict the relative costs of these alternatives.
Actually this is exactly what Moore's Law talks about. Generally the optimal size they aim for is around 120 mm^2 (this is just an observation for high performance consumer microprocessors) and with each generational improvement in process technology they can roughly double the transistors in that area. It's worth noting the PPC970 has roughly the same transistor count on the 90 nm process as the 130 nm and is quite substantially below that 120 mm^2 size.
Originally posted by Telomar
Actually this is exactly what Moore's Law talks about. Generally the optimal size they aim for is around 120 mm^2 (this is just an observation for high performance consumer microprocessors) and with each generational improvement in process technology they can roughly double the transistors in that area. It's worth noting the PPC970 has roughly the same transistor count on the 90 nm process as the 130 nm and is quite substantially below that 120 mm^2 size.
Exactly. "Moore's Law" is so increadibly over-used I don't like to mention it explicitly.
Originally posted by Telomar
Can't say I'm a great fan of Moore's Law either since it is more often than not misused but it is a general statement about the economics of IC manufacture tacked together with a rough observation of how often new processes are brought online.
Yes, I remember being quite surprised when I read the original statement Moore made (as opposed to the large number of interpretations). It was remarkably simple, which is probably why it has remained (approximately) true this long. I read recently even (especially?) Moore was surprised by how well it had held up.
Originally posted by fieldor
http://theinquirer.org/?article=13928
http://theregister.co.uk/content/54/35265.html
see for your self, just read it. This maybe coming our way eventually.
its actually sounds like a half decent microsoft product
Originally posted by G-News
What makes you think people are going to spend 700$ on a console in 2005, I ask?
Inflation
With all this talk about multithreading and multicore cpu's, my question is,"Do the three cores have to be identical?" The reason I ask is, if different demands on the cpu could be directed during compiling more easily to separate cores. Since my ignorance of both hardware and software engineering is monumental, the lame examples I'll use will be graphics, physics and sound(other examples may be much more appropriate).
If each core is more or less designed to handle specific tasks, would this make programming multiple threads somewhat easier, or if proper compiler instructions added, even automatic? Possibly, then the space(#'s of transistors) could/may be designed much more efficiently.
Since we're talking about a cpu for xBox Next, which could be specifically designed for gaming, rather than general purpose desktop/workstation computing, does any of the above make any sense?
However, how good the programs will be optimized, is mainly a matter of how good MS's development environment/compilers will be.
Originally posted by G-News
afaik, both could be possible.
However, how good the programs will be optimized, is mainly a matter of how good MS's development environment/compilers will be.
Thank you for the reply.
Well, if Mac websites are to be believed, we know Microsoft is very good at designing compilers for high Spec scores.
Originally posted by rickag
Please pardon my igorance, but I have a question and may word it incorrectly.
With all this talk about multithreading and multicore cpu's, my question is,"Do the three cores have to be identical?"
No, they don't. In fact, this sort of thing is common in consoles. And Amigas.
Originally posted by rickag
Please pardon my igorance, but I have a question and may word it incorrectly.
With all this talk about multithreading and multicore cpu's, my question is,"Do the three cores have to be identical?" The reason I ask is, if different demands on the cpu could be directed during compiling more easily to separate cores. Since my ignorance of both hardware and software engineering is monumental, the lame examples I'll use will be graphics, physics and sound(other examples may be much more appropriate).
If each core is more or less designed to handle specific tasks, would this make programming multiple threads somewhat easier, or if proper compiler instructions added, even automatic? Possibly, then the space(#'s of transistors) could/may be designed much more efficiently.
Since we're talking about a cpu for xBox Next, which could be specifically designed for gaming, rather than general purpose desktop/workstation computing, does any of the above make any sense?
This is a very good question, actually. In general purpose computers there is a lot of benefit to having symmetric cores (hence the term SMP for symmetric multiprocessing) because the software can remain largely ignorant of the particular hardware it is run on, but in specialized hardware like game consoles this isn't as important because the software is custom designed for the hardware. The PS2 has several different kinds of processors -- a MIPS core (two, actually), a couple of vector processors, a DMA engine, and a couple of sound chips. The PS3's Cell architecture is rumoured to have conventional processors with a set of slave vector processors.
What is key in this kind of design is to provide processors which can be used for a wide variety of processors, rather than over-specializing them. GPUs and SPUs are an exception because all games have lots of graphics and sound, but even there the over-specialization can limit what game developers can do (for example, the current DirectX/OpenGL vertex program model means that you can't create/destroy vertices or do inter-vertex optimizations in the GPU itself, whereas PS2 does this quite well because it uses a more general vector processor).
Even if the cores are the same, there is no requirement that the software use them in the same way. Most people tend to assume that a symmetric multi-core processor will just divide up the running pre-emptive threads, but this isn't necessarily the best way to do things.
Taking my example of graphics, I would think this might not be a good example, because graphics cards are very sophisticated and comsume a lot of transistors and ram.
I guess what I'm saying is,"Is there a way in hardware to make programming multithreading easier or automatic? And if so is there any advantage to designing each core for specific purposes?
The only example I can think of at the momment is SIMD, and this still might be a bad example. If say only one core has Altivec/VMX(or maybe two), would it be easier to program, or automate during compiling, directing this thread toward the core with SIMD?
If this all sounds redundent, chalk it up to my lack of knowledge.
I guess I just don't know enough about how threads are generated and controlling multithreading so there aren't a ton of threads stepping on each other. It is an interesting topic though, even for the technologically challenged like me.
Originally posted by rickag
I guess what I'm saying is,"Is there a way in hardware to make programming multithreading easier or automatic? And if so is there any advantage to designing each core for specific purposes?
Not really -- the software has to be setup to deal with multiple processors and the specific kinds of processors. The more automatic you make it, the less control developers have over it. Making hardware too specific limits what it can be used for.
GPUs are a good example: they are very specialized to rasterize 2D pixel maps from triangle vertex data and 2D textures. This makes it impossible (or really difficult anyhow) to use their massive floating point capabilities for anything other than the graphics they were designed to do. Curved surfaces, for example, don't do well through a triangle-based GPU. GPUs are getting more and more generalized all the time, first by the introduction of shaders, and now by the ever increasing expressive power of the shaders. Eventually they'll be useable for things which aren't even graphics.
Originally posted by rickag
Thank you all for the responses. My next question concerns the examples I used for multithreading, graphics/physics/sound. Are there more basic ways to separate threads directed toward individual cores.
I'm not sure exactly what your asking here. One way to for a thread to be generated for a specific processor is through another thread issuing a call to a system function or library function. Consider your main program that has been built to wrk with a DSP card, it may issue a call that results in code running on the DSP. While I have a hard time describing this as multi threaded you would end up with code running on a specific processor.
Generally you don't want threads going to specific cores or processors, rather you would hope that the OS can manage the correct allocation of resources. Of course there are always cases where an OS would choose a poor allotment of processors.
Quote:
Taking my example of graphics, I would think this might not be a good example, because graphics cards are very sophisticated and comsume a lot of transistors and ram.
I guess what I'm saying is,"Is there a way in hardware to make programming multithreading easier or automatic? And if so is there any advantage to designing each core for specific purposes?
When you say programming automatic I'm not sure what you are asking. There are no limits to what may be added to a processor other than the limit space on the chip. So it is possible to add hardware to a processor to make it a better machine for a multithreaded environment. That won't make anything automatic, but you could make things easier. But that easinees is at a low level and probally not what you are inquiring about.
Quote:
The only example I can think of at the momment is SIMD, and this still might be a bad example. If say only one core has Altivec/VMX(or maybe two), would it be easier to program, or automate during compiling, directing this thread toward the core with SIMD?
If you really wanted to go to all the trouble you probally could get a machine to operate with a AMD and PPC chip on the same board. Beyond a whole bunch of issues you would still need to get the OS to handle sending the right code to the right processor. You could likewise build a PPC system with a processor with SIMD and one with out, still taking into account the required OS work that would need to be done.
I'm not sure why anyone would want to do this though. Such a mix of processors may very well work in a server environment where a large number of threads just need integer operations. But again it is a software issue and one would have to wonder why not implement SMP. Come to think of it some servers do implement intelligent I/O which execute requests from the OS. I have trouble describing that as threading though.
Quote:
If this all sounds redundent, chalk it up to my lack of knowledge.
Questions never hurt though my response above may hurt a bit.
Quote:
-IF- they want that.