Um, what? A mouse is a little device with buttons. People understand that different buttons do different things, they use things with more than one button all the time. In reality, what gets people is not left-button vs right-button, but double-clicking, which is something that you don't have on CD-players, cars, etc.
The software developers don't really have a choice in the matter. Parallel computing is where it's at for at least several years until the next breakthrough in process technology comes about. Everyone is doing it, from Sun (Niagra), to IBM (POWER and Cell), to Intel and AMD. Unless software developers want the performance of their programs to remain unchanged for several years (and hence have Doom IV looking pretty much the same as Doom III), they'll just have to adapt.
However, how many of those accesses are latency sensitive? Most of the accesses you listed are streaming. For example, consider vertex buffers. The GPU doesn't do random access to vertex buffers. It processes batches of vertices at a time. Even with a small vertex cache, it's easy for a prefetch unit to mask the memory access latency. It just has to make sure that the next batch is available in the cache by the time the GPU finishes the current batch. Also consider something like the framebuffer. Most framebuffer access is writes, which are inherently independent of latency. Beyond that, you have to remember that GPUs have extremely deep pipelines. Literally hundreds of pixels may be in different stages of processing at a given time. It's easy enough for the GPU to issue something like a texture fetch early in the pipeline, so it'll be ready by the time the pixel is ready to be textured.
It's fairly easy to predict what texture a shader program will need. Shaders, even fairly complex ones, only draw from a few source textures, and even then, in a highly localized manner. Remember, nearly all textures accessed by a shader still contain data in the spatial domain. A small cache on the GPU should still do a good job of hiding memory latency for the shader.
Rough visibility culling (based on line of sight) is done long before the scene hits the graphics card. By the time the scene is in a graphics card, the shaders are going fairly linearly through a series of vertex buffers, making highly localized accesses to a few textures in the process. There are very few ambient lights in most games (8 is a common maximum), so their positions are usually stored as arguments to a pixel shader or as part of the OpenGL state. Either way, they are not randomly accessed from memory, but rather they reside in registers. As for reflected lighting, it is not calculated by chasing a ray randomly through the scene. It is calculated by rendering part of the scene to a texture, then texturing selected reflective objects with it.
GPUs are highly parallel stream processors with pipelines that strech to hundreds of stages. They do not do random-access processing very well.
BeOS was rather seriously lacking in the area of filesystem and virtual memory performance. The biggest problem was the lack of a unified file/vm cache.
Not necessarily. It depends on the application. In "streaming" applications (hint: 3D rendering like on a graphics card!) the latency doesn't matter nearly as much as bandwidth.
Because SRAM takes up 6 transistors per bit, while DRAM takes up 1 transistor per bit. The biggest mainstream CPUs run about ~150m transistors, and that's only enough (if everything were cache), about 3MB.
No they are not. Both the phase and amplitude of an em wave are real numbers. Phasors are just a short-hand way of representing them using complex arithmetic. That way, you only need to do one set of operations, not two.
No, that's not what you're saying. Okay, let me put it this way. It is possible for limits to be infinite. For example, the limit of 1/x as x goes to 0+ is +infinity. Now, the phrase "X approaches Y when Z" is a well-established short-hand for "the limit of X when Z is equal to Y". Well, the limit here is +infinity, so the phrase "m approaches +infinity when v approaches c" is a perfectly acceptable substitution.
For this reason, the phrase "X approaches infinity" is a very common shorthand in science, mathematics, and engineering. You see it all the time.
I'm not saying that it's not possible (heck, we knew what happened the last time we thought that), rather that relativity is so entrenched that disproving it would literally change all of physics. It would be an event on a par with the ultraviolet catastrophe that brought down classical physics. As a result, it's not something to be taken lightly.
I just realized that it's much simpler to just use the second part of the derived result. Don't even consider a rocket. Just consider a mass traveling at V relative to an observer. It then accelerates by dV. That dV measured from the observer is less than the dV measured by the rocket by a factor of S^2. If the rocket accelerates at a constant rate from the perspective of the rocket (which is true, assuming that Mr is much greater than Me, and Ve is constant), then dV approaches zero as V approaches C.
dV = Ve * Me / Mr, where dV is the change in velocity of the rocket, Ve is the velocity of the exhaust, and Mr is the mass of the rocket.
Now, basic relativity:
S = sqrt(1 - V^2/C^2) -> A scaling factor M' = M / S -> Mass increases as V increases. T' = T / S -> Time slows down as V increases. L' = L * S -> Lengths decrease as V increases.
Now, if you just consider M, you're right. Me' / Mr' = (Me / S) / (Mr / S) = Me / Mr. Thus, dV remains constant, because the increases cancel out.
However, you have to consider that Ve is measured relative to an observer. Further, you have to remember that lengths and times measured by the observer are not the same as those measured on the rocket. Consider that a rocket is moving at Vr relative to a stationary observer. The observer can measure the velocity of the exhaust, Ve, by measuring how far the exhaust travels in a given unit of time.
Ve = L / T.
However, that "L" and "T" are actually L' and T', because the rocket (and it's exhaust) are moving relative to the observer. So:
Ve = L' / T' = S^2 * L / T.
Since S is always less than one (eg: S at 0.99c is about 1/7), Ve measured by the observer will be less than Ve measured by the rocket by a factor of S^2. That means, as the rocket accelerates closer to the speed of light, Ve measured relative to the observer approaches zero. As a result, the rocket cannot ever accelerate to the speed of light.
My numbers could be completely wrong, but hopefully I remember my rocket physics well enough from class that the results are correct:)
1) Under the current physics, light-speed travel is impossible. As you approach the speed of light, the energy required to accelerate you further approaches infinity.
2) As you accelerate to 99.9% the speed of light, time slows down very significantly. Theoretically, at the speed of light, the passage of time stops, but since you cannot accelerate to the speed of light, that's a moot point.
Of course, the author is editorializing, like most journalists do. However, the editorializing on the part of people not affiliated with Sony or IBM shouldn't reflect negatively on Cell.
The CS monitor says it exactly like it is: PIII gets 2 gigaflops, and the PS2 get's 6.2 gigaflops. Consider the former is just for the CPU, and the latter is for the whole system (CPU + GPU), this isn't outrageous. The "twice as fast as a supercomputer" stuff was editorializing on the part of the writer.
In the Time article, Sony doesn't exaggerate at all. The PS2 really can sustain ~70M polygons per second when they are simply shaded. The "microprocessor as powerful as a supercomputer" stuff is again, editorializing on the part of the writer.
Show me actual technical literature that shows Sony exaggerating about the PS2. They take favorable numbers (eg: flat-shaded polygons instead of textured polygons), but they are for the most part verifiable. Note that the presentations about Cell aren't the same sort of thing as fluffed-up magazine articles. They are professional presentations, stuff written by geeks for people who know what a DMA controller is. If they are making stuff up for this, they'll be discredited by their peers. I doubt Sony and IBM engineers would take those risks.
There were stories about the US trying to stop G5s too because they were "super-computers". It just had to do with an outdated guage of what constituted a supercomputer for export purposes.
It doesn't sound too good to be true, if you compare Cell to other stream processors, instead of general purpose CPUs. A GeForce 6, for example, can sustain 40 gigaflops, compared to 3-4 for a G5 or P4. Given the constraints graphics chip designers work with in regards to process technology (specifically, GPU circuits cannot be hand-optimized, because of the 6-month turnaround), achieving 10x that doesn't seem that unrealistic.
The local storage is different for the following reasons:
1) It must be programmed differently. Instead of just accessing memory how you want, you must explicitly copy the part of memory you need at the moment. So, if your APU is acting as a vertex shader, you need to copy the shader code into the LS before you start processing. Essentially, the LS can give you the time savings of a cache, but you have to manage it yourself to get the benefits.
2) Since the LS isn't managed by the hardware, it doesn't need a lot of management hardware. You don't need cache tags, lookup hardware, hardware to manage misses, etc. This saves a lot of transistors.
3) A regular cache has to do some management on each access. It has to search the tags to find what cache line holds a given memory word, it has to perform write-back, etc. Since the LS doesn't need to do any of this, latency can be cut down.
4) Since the LS is addressed directly, and isn't mapped onto memory, there is no need for cache coherency protocols. A cache-coherent multi-processor system needs to communicate with it's peers to coordinate access to the cache. For example, when it writes to a memory location, it must notify all other processors caching that location that their copies are now invalid. The LS doesn't need to do any of this, and that cuts down on both management hardware and latency.
The APUs are stream processors. It is common for stream processors to not have a general memory cache. The geforce 3's vertex processor, for example, has enough cache to hold 18 vertices. The are not an LRU cache like a Pentium's, but a FIFO (much cheaper to manage), and are only used in certain circumstances. In comparison, the Cell's 128KB LS per PE is enormous!
Slashdot Mirror
Actually, this is fairly common advice in UI circles.
Um, what? A mouse is a little device with buttons. People understand that different buttons do different things, they use things with more than one button all the time. In reality, what gets people is not left-button vs right-button, but double-clicking, which is something that you don't have on CD-players, cars, etc.
The software developers don't really have a choice in the matter. Parallel computing is where it's at for at least several years until the next breakthrough in process technology comes about. Everyone is doing it, from Sun (Niagra), to IBM (POWER and Cell), to Intel and AMD. Unless software developers want the performance of their programs to remain unchanged for several years (and hence have Doom IV looking pretty much the same as Doom III), they'll just have to adapt.
However, how many of those accesses are latency sensitive? Most of the accesses you listed are streaming. For example, consider vertex buffers. The GPU doesn't do random access to vertex buffers. It processes batches of vertices at a time. Even with a small vertex cache, it's easy for a prefetch unit to mask the memory access latency. It just has to make sure that the next batch is available in the cache by the time the GPU finishes the current batch. Also consider something like the framebuffer. Most framebuffer access is writes, which are inherently independent of latency. Beyond that, you have to remember that GPUs have extremely deep pipelines. Literally hundreds of pixels may be in different stages of processing at a given time. It's easy enough for the GPU to issue something like a texture fetch early in the pipeline, so it'll be ready by the time the pixel is ready to be textured.
It's fairly easy to predict what texture a shader program will need. Shaders, even fairly complex ones, only draw from a few source textures, and even then, in a highly localized manner. Remember, nearly all textures accessed by a shader still contain data in the spatial domain. A small cache on the GPU should still do a good job of hiding memory latency for the shader.
Rough visibility culling (based on line of sight) is done long before the scene hits the graphics card. By the time the scene is in a graphics card, the shaders are going fairly linearly through a series of vertex buffers, making highly localized accesses to a few textures in the process. There are very few ambient lights in most games (8 is a common maximum), so their positions are usually stored as arguments to a pixel shader or as part of the OpenGL state. Either way, they are not randomly accessed from memory, but rather they reside in registers. As for reflected lighting, it is not calculated by chasing a ray randomly through the scene. It is calculated by rendering part of the scene to a texture, then texturing selected reflective objects with it.
GPUs are highly parallel stream processors with pipelines that strech to hundreds of stages. They do not do random-access processing very well.
BeOS was rather seriously lacking in the area of filesystem and virtual memory performance. The biggest problem was the lack of a unified file/vm cache.
Not necessarily. It depends on the application. In "streaming" applications (hint: 3D rendering like on a graphics card!) the latency doesn't matter nearly as much as bandwidth.
Because SRAM takes up 6 transistors per bit, while DRAM takes up 1 transistor per bit. The biggest mainstream CPUs run about ~150m transistors, and that's only enough (if everything were cache), about 3MB.
The link shows that the limit of 1/x as x approaches 0 is +infinity. Thus, +infinity (and - infinity) can indeed be a limit.
No they are not. Both the phase and amplitude of an em wave are real numbers. Phasors are just a short-hand way of representing them using complex arithmetic. That way, you only need to do one set of operations, not two.
A limit can be infinity, yes. Wolfram's MathWorld shows that the limit of 1/x as x approaches 0 equals +infinity.
No, that's not what you're saying. Okay, let me put it this way. It is possible for limits to be infinite. For example, the limit of 1/x as x goes to 0+ is +infinity. Now, the phrase "X approaches Y when Z" is a well-established short-hand for "the limit of X when Z is equal to Y". Well, the limit here is +infinity, so the phrase "m approaches +infinity when v approaches c" is a perfectly acceptable substitution.
For this reason, the phrase "X approaches infinity" is a very common shorthand in science, mathematics, and engineering. You see it all the time.
You mean, this experiment at NEC?
I'm not saying that it's not possible (heck, we knew what happened the last time we thought that), rather that relativity is so entrenched that disproving it would literally change all of physics. It would be an event on a par with the ultraviolet catastrophe that brought down classical physics. As a result, it's not something to be taken lightly.
+Infinity is at the upper end of the number line. -Infinity is at the lower end of the number line.
To nitpick: a given value, presuming it exists, cannot be infinite. All values that exist are finite.
I just realized that it's much simpler to just use the second part of the derived result. Don't even consider a rocket. Just consider a mass traveling at V relative to an observer. It then accelerates by dV. That dV measured from the observer is less than the dV measured by the rocket by a factor of S^2. If the rocket accelerates at a constant rate from the perspective of the rocket (which is true, assuming that Mr is much greater than Me, and Ve is constant), then dV approaches zero as V approaches C.
Okay, basic rocket physics:
:)
dV = Ve * Me / Mr, where dV is the change in velocity of the rocket, Ve is the velocity of the exhaust, and Mr is the mass of the rocket.
Now, basic relativity:
S = sqrt(1 - V^2/C^2) -> A scaling factor
M' = M / S -> Mass increases as V increases.
T' = T / S -> Time slows down as V increases.
L' = L * S -> Lengths decrease as V increases.
Now, if you just consider M, you're right. Me' / Mr' = (Me / S) / (Mr / S) = Me / Mr. Thus, dV remains constant, because the increases cancel out.
However, you have to consider that Ve is measured relative to an observer. Further, you have to remember that lengths and times measured by the observer are not the same as those measured on the rocket. Consider that a rocket is moving at Vr relative to a stationary observer. The observer can measure the velocity of the exhaust, Ve, by measuring how far the exhaust travels in a given unit of time.
Ve = L / T.
However, that "L" and "T" are actually L' and T', because the rocket (and it's exhaust) are moving relative to the observer. So:
Ve = L' / T' = S^2 * L / T.
Since S is always less than one (eg: S at 0.99c is about 1/7), Ve measured by the observer will be less than Ve measured by the rocket by a factor of S^2. That means, as the rocket accelerates closer to the speed of light, Ve measured relative to the observer approaches zero. As a result, the rocket cannot ever accelerate to the speed of light.
My numbers could be completely wrong, but hopefully I remember my rocket physics well enough from class that the results are correct
1) Under the current physics, light-speed travel is impossible. As you approach the speed of light, the energy required to accelerate you further approaches infinity.
2) As you accelerate to 99.9% the speed of light, time slows down very significantly. Theoretically, at the speed of light, the passage of time stops, but since you cannot accelerate to the speed of light, that's a moot point.
Of course, the author is editorializing, like most journalists do. However, the editorializing on the part of people not affiliated with Sony or IBM shouldn't reflect negatively on Cell.
Okay, one by one:
The CS monitor says it exactly like it is: PIII gets 2 gigaflops, and the PS2 get's 6.2 gigaflops. Consider the former is just for the CPU, and the latter is for the whole system (CPU + GPU), this isn't outrageous. The "twice as fast as a supercomputer" stuff was editorializing on the part of the writer.
In the Time article, Sony doesn't exaggerate at all. The PS2 really can sustain ~70M polygons per second when they are simply shaded. The "microprocessor as powerful as a supercomputer" stuff is again, editorializing on the part of the writer.
Show me actual technical literature that shows Sony exaggerating about the PS2. They take favorable numbers (eg: flat-shaded polygons instead of textured polygons), but they are for the most part verifiable. Note that the presentations about Cell aren't the same sort of thing as fluffed-up magazine articles. They are professional presentations, stuff written by geeks for people who know what a DMA controller is. If they are making stuff up for this, they'll be discredited by their peers. I doubt Sony and IBM engineers would take those risks.
There were stories about the US trying to stop G5s too because they were "super-computers". It just had to do with an outdated guage of what constituted a supercomputer for export purposes.
It doesn't sound too good to be true, if you compare Cell to other stream processors, instead of general purpose CPUs. A GeForce 6, for example, can sustain 40 gigaflops, compared to 3-4 for a G5 or P4. Given the constraints graphics chip designers work with in regards to process technology (specifically, GPU circuits cannot be hand-optimized, because of the 6-month turnaround), achieving 10x that doesn't seem that unrealistic.
The local storage is different for the following reasons:
1) It must be programmed differently. Instead of just accessing memory how you want, you must explicitly copy the part of memory you need at the moment. So, if your APU is acting as a vertex shader, you need to copy the shader code into the LS before you start processing. Essentially, the LS can give you the time savings of a cache, but you have to manage it yourself to get the benefits.
2) Since the LS isn't managed by the hardware, it doesn't need a lot of management hardware. You don't need cache tags, lookup hardware, hardware to manage misses, etc. This saves a lot of transistors.
3) A regular cache has to do some management on each access. It has to search the tags to find what cache line holds a given memory word, it has to perform write-back, etc. Since the LS doesn't need to do any of this, latency can be cut down.
4) Since the LS is addressed directly, and isn't mapped onto memory, there is no need for cache coherency protocols. A cache-coherent multi-processor system needs to communicate with it's peers to coordinate access to the cache. For example, when it writes to a memory location, it must notify all other processors caching that location that their copies are now invalid. The LS doesn't need to do any of this, and that cuts down on both management hardware and latency.
The APUs are stream processors. It is common for stream processors to not have a general memory cache. The geforce 3's vertex processor, for example, has enough cache to hold 18 vertices. The are not an LRU cache like a Pentium's, but a FIFO (much cheaper to manage), and are only used in certain circumstances. In comparison, the Cell's 128KB LS per PE is enormous!
Yes. A lot of new HDTVs, for example, come with DVI inputs. A lot of the new pure-digital audio receivers come with HDMI inputs.