Just to clarify here, this is not the same idea as the Cell architecture.
The Cell architecture (which may or may not be used for the PS3) is a multi-processor system designed for scalability; It really does have several processors running at the same time. In contrast, 'Hyperthreading' runs multiple threads on a single processor's core.
They both require multi-threaded code to achieve performance improvements, but fundamentally they're really quite different, and yield quite different price / performance trade-offs.
Now that's what you want! A little bit pricey, but loads of space, and it runs linux:)
I recall reading about what these guys were doing a while ago. Apparently, the original implementation had a radio link, so the guy could upload / download mp3s to his car while it was parked in the garage. Now why doesn't someone big like Compaq do something like that?
I guess it was inevitable that this debate would lead to this kind of argument, but somehow I think most people have missed the original point... If you tell a hardened ASM programmer that a compiler can produce better code than they can, the knee-jerk reaction will always be, "No way!" But we're not talking about static compilation here. The subject is runtime compilation, actually producing code during execution.
If you are writing any sort of genuinely generic code, then the likelihood is that you will not be able to envisage every possible use that the code will be put to. What this implies is that as a programmer, you cannot know the exact circumstances in which your code will be used. A run-time compiler knows the exact circumstances, including how many registers a calling function may have free, how frequently a particular piece of code is executed, argument and loop invariants, and so on.
This knowledge allows the compiler to improve the efficiency of argument passing, memory usage, cache usage and various other things dynamically according to the circumstances of execution, and it is knowledge that the original programmer simply cannot know. The only way a human programmer can perform these kinds of optimisations is through making assumptions as to the code's usage, which defeats the purposes of generic coding.
Think along the lines of writing a piece of code, then seeing the compiler product different chunks of machine code from the same source, depending on its usage. Maybe the compiler notices that a particularly frequent part of the program consistently calls your function with the same parameters. It can use this knowledge to compile your program with the constants in mind, thus saving register usage and parameter passing overhead, for this particular case. For a human programmer to perform this kind of optimisation, they would have to analyse every possible use that their function was put to. That simply isn't practical for non-trivial programming projects.
If we really want to debate the implications of run-time compilation, the question should not be whether a human programmer can optimise better than a static compiler. We should be asking whether the advantages a run-time compiler has over static compiler are enough to outweigh the overhead that is incurred by the compilation process.
Someone pointed out that a 700MHz Crusoe processor executes code at approximately the same speed as a 500MHz Pentium III. It sounds like quite a big overhead, but it would be a more meaningful statistic if we knew how fast a Crusoe processor would execute entirely native code...
Slashdot Mirror
Didn't you just totally ignore the comments of the poster you were replying to?
Just to clarify here, this is not the same idea as the Cell architecture.
The Cell architecture (which may or may not be used for the PS3) is a multi-processor system designed for scalability; It really does have several processors running at the same time. In contrast, 'Hyperthreading' runs multiple threads on a single processor's core.
They both require multi-threaded code to achieve performance improvements, but fundamentally they're really quite different, and yield quite different price / performance trade-offs.
Picture the file system directory spread out across 3d space
:-)
"It's a UNIX system!"
Nik.
Or maybe ``translucency'', which can mean ``partial transparency''. Generally speaking, one can see right through transparent things...
Nik.
http://www.empeg.com/
Now that's what you want! A little bit pricey, but loads of space, and it runs linux :)
I recall reading about what these guys were doing a while ago. Apparently, the original implementation had a radio link, so the guy could upload / download mp3s to his car while it was parked in the garage. Now why doesn't someone big like Compaq do something like that?
Nik.
I guess it was inevitable that this debate would lead to this kind of argument, but somehow I think most people have missed the original point... If you tell a hardened ASM programmer that a compiler can produce better code than they can, the knee-jerk reaction will always be, "No way!" But we're not talking about static compilation here. The subject is runtime compilation, actually producing code during execution.
If you are writing any sort of genuinely generic code, then the likelihood is that you will not be able to envisage every possible use that the code will be put to. What this implies is that as a programmer, you cannot know the exact circumstances in which your code will be used. A run-time compiler knows the exact circumstances, including how many registers a calling function may have free, how frequently a particular piece of code is executed, argument and loop invariants, and so on.
This knowledge allows the compiler to improve the efficiency of argument passing, memory usage, cache usage and various other things dynamically according to the circumstances of execution, and it is knowledge that the original programmer simply cannot know. The only way a human programmer can perform these kinds of optimisations is through making assumptions as to the code's usage, which defeats the purposes of generic coding.
Think along the lines of writing a piece of code, then seeing the compiler product different chunks of machine code from the same source, depending on its usage. Maybe the compiler notices that a particularly frequent part of the program consistently calls your function with the same parameters. It can use this knowledge to compile your program with the constants in mind, thus saving register usage and parameter passing overhead, for this particular case. For a human programmer to perform this kind of optimisation, they would have to analyse every possible use that their function was put to. That simply isn't practical for non-trivial programming projects.
If we really want to debate the implications of run-time compilation, the question should not be whether a human programmer can optimise better than a static compiler. We should be asking whether the advantages a run-time compiler has over static compiler are enough to outweigh the overhead that is incurred by the compilation process.
Someone pointed out that a 700MHz Crusoe processor executes code at approximately the same speed as a 500MHz Pentium III. It sounds like quite a big overhead, but it would be a more meaningful statistic if we knew how fast a Crusoe processor would execute entirely native code...
Nik.