ASM Community

I'm pretty sure my P3 1.3ghz celly with whatever disks and 256bit AES encryption would have no problems deliviring 3 video streams (DivX or XviD) at once... guess I should test it, got 3 client boxes hooked up to it anyway :)

Heck, I'm a developer, and my PC is now in its 3rd year I think. It's an XP1800+, and not exactly high-end anymore (I don't think you can actually buy PCs this slow anymore :)).
But it still works as well as the day I got it. It compiles my sources quickly enough, I can navigate through any program effortlessly, and I'm not even running into memory limits yet (I have 'only' 512 mb).
The only thing that must be upgraded is my videocard. Which brings me to the next point...



The main difference with GPUs and CPUs is that GPUs do not have a fixed instructionset. They don't have to, because Direct3D offers a meta-shading language, which is quite similar to the way that .NET and Java do their work. You store a compiled program in bytecode, and let the machine compile to native code at runtime.
This led to much more competition and variation in GPUs than x86 can ever dream of, and that's one of the reasons why GPUs could develop so quickly.
So quickly in fact, that the developers could not keep up. But that is solved now. Direct3D 8 still used an asm-language to write shaders. This was very time-consuming, especially since you could write only for one shader version at a time.
Now we have HLSL, and you can write in a C-like language, and easily target multiple shader versions.

The effects are quite obvious, I think. Until recently, most games either used no shaders, or only ps1.1 or so, in a very simple way.
I would say that Doom3 would be the first to really take ps1.1 to the extreme.
But now that DirectX 9 has arrived, we see incredible new rendering technology in games like Halflife 2, and Unreal. Especially the previews of Unreal Engine 3.0 are incredible.

So I think the developers have pretty much caught up again, now that they are familiar with shaders, and have better tools to develop them.

But to get back to the differences between CPUs and GPUs... GPUs are not in their final form yet, unlike CPUs. With CPUs, it's quite clear that you need a bunch of registers, some ALUs, FPUs, and that's about it. You can vary the components, or tie them together in a different way (SIMD, HTT, multi-core), but that's about it.
These rules apply to GPUs aswell, but there is more. The way GPUs render today, is not the final way. They have changed incredibly since the early VooDoos (first GPU-assisted poly setup, then hardware T&L, then programmable shaders), and the plans for DirectX Next show that there are still many changes to come.
One such change will be the unification of vertex and pixelshaders. Currently the vertexshaders are more powerful and have more precision (except on GeForce FX/6800), but pixelshaders are getting closer... The next step is to make them functionally equivalent, and re-use the physical components.
This alone should be quite a big step... Imagine that today's GPUs have 6 vertex units and 16 pixel units.
After this step, you would effectively have a chip with 22 vertex units and 22 pixel units!
So especially polycount can become much larger. I can already guess the next step... an optimization to output polygons <= 1 pixel large directly from the vertexshader, bypassing the triangle rendering unit.

Another new thing will be the topology processor. Perhaps we can then run Marching Cubes entirely on a GPU? Amazing.

And since PCI-Express is full-duplex, unlike AGP, it will become much more interesting to share main memory, and have the GPU assist the CPU in calculations.
Another addition will be a kind of virtual memory on the GPU. So it can more easily page main memory in and out, and the onboard videomemory will become a kind of cache.

And this kind of thing might also happen if .NET will allow CPU manufacturers to experiment freely with their architecture.

Apparently you didn't read or understand my story on the (not-so-distant) future of GPUs.
The technologies that I described will mainly open up new possibilities, most notably that of using the GPU as a massively parallel vector processor (not necssarily graphics-related, perhaps a much better option for your parallel processing than a quad Opteron, ever considered it?).
The new possibilities will sell the GPUs, as they always have.

I think it's safe to say that speed hasn't been the main selling point for quite some time. We have been able to play games at 60+ fps in 1024x768+ resolutions for quite some time now. People don't upgrade for faster graphics. They upgrade for better graphics. Better texture filtering, antialiasing, new shading methods, high dynamic range, etc (I don't think that many people accept the current level of realism yet, so more realistic graphics is a good reason to upgrade, also for professionals ofcourse. The better their realtime previews of their work, the better they can do their work).

So clearly the new GPUs are going somewhere, unlike 64-bit CPUs (for most people anyway).
To explain that more clearly... There is nothing I cannot do with a 32-bit CPU that I can do with a 64-bit CPU. And most things don't even require more effort on 32-bit CPUs, since 32-bit is sufficient for it.
On the other hand it is impossible to emulate new GPU features on an older model, since it lacks the speed, accuracy and flexibility. More abstract: CPUs are Turing-complete, GPUs are not (yet?).

Well, many movies are already largely CG (Matrix? :)), or even completely (Finding Nemo! \o/).
We may be able to play such movies realtime with hardware eventually (the latest NVIDIA and ATi demos are getting closer and closer. ATi also used real actors with motion capture, who were replaced by CG models in the demo. This may be the future of acting?). And then you can be your own director, move freely in the 3d world... etc. Doesn't have to be interactive though.

And games are already getting close to movie budgets...

You are missing the point. Games need to be interactive, but movies aren't, and there is a huge market for those aswell.
There are already experiments of (non-interactive) movies with game technology going on (see http://www.insidemacgames.com/news/story.php?ArticleID=2564), and this may well be a future form of entertainment.

A point the Randy has argued recently has been the end of "Moore's Law" and if I have the context correct, he has argued the end of the formula that Intel have sold using "Moore's Law" of a time based ratio of technology/cost advancement.

Their own admission that one of their current technologies in the PIV core is coming to the end of its development life on the basis of future need for exotic cooling for higher clock speeds. The M core being developed in Israel addresses that problem to some extent because of its background as a notebook chip where power consumption is lower but it is yet to be seen if it can be clocked fast enough to improve much on the current PIV core.

Scali has mentioned the GPU technology that is current and this tends to be one of the ways of getting around processor based problems at the moment by delegating tasks to other hardware to free up the CPU. Extending this view to current technology in other areas, using a SCSI controller card with current technology reduces the CPU demand as well and when applied to enough categories of IO in a computer, it does work as a future architecture where an increasing number of tasks are delegated to other dedicated hardware.

If you take a reasonably current low end computer with a Winmodem, junk graphics card and cheapie HDDs plus any other CPU consuming functionality, you have a model for what NOT to do in making faster and more powerful computers and to extend this idea further, the alternative is to do exactly the opposite by isolating the functionality of different tasks so thaqt you don't have a collective loss in CPU power when its needed for other tasks.

Multiple CPUs can help a lot here as you can handle all of the OS junk in one processor while doing time intensive work on another. A fast GPU that frees the CPU from othr tasks helps more and certainly using high end disk IO with decent controller cards removes one of the more noticable bottlenecks in processing disk intensive data.

Now with all of these tasks delegated to other hardware so you get the appropriate bang for you buck with the existing CPU, you run into tasks at a commercial level like physically sorting a 100 gig database and its tasks like this that leave a current 32 bit CPU panting for a very long time as the task is literally too big for it in memory and CPU grunt terms yet with known technology in 64 bit, a task as messy as this one can be approached in a very different way on a far larger scale.

Now think of the demand for editing very high resolution movies special effects where you need to be able to manage multiple videos in real time with the capacity to cut and paste with fades and the like is a task too big for current 32 bit x86 technology. A dual Apple G5 will do a lot better but future computer technology will do a lot better again if it is managed properly.

The virtue of extending x86 hardware to 64 bit is the use of existing experience in x86 while being able to adapt to handling far larger amounts of data. The only hardware that actually handles native x86 instructions was an 8086 circa 1980. Everything since has produced an interface to that instruction set with almost totally unrelated internals and this is why the interface has lasted so long.

Most of the later implimentations have sneaked in RISC by having a preferred instruction set and leaving the rest to microcode so the idea that the old instruction set is a major limitation does not fit the available hardware that is current.

Bus limits are still with us and it shows in things like the SATA versus the PATA interfaces where the PATA interface is still tied to the board's bus speed. Some of the major improvements in performance have come with the end of the ISO bus and later with AGP for video but future technology will dramatically improve this area.

If you want to be pedantic, you'll note that Moore's "Law" never has really held anyway. Look up the paper entitled "The Lives and Deaths of Moore's Law" on the internet for more details.

BTW, the 18-month period turns out to be a fabrication. In 1965 Gordon Moore claimed 12 months. By 1979 he was claiming 24 months. The press just averaged the two numbers to arrive at 18 months. In fact, the time needed to achieve a doubling of transistors keeps increasing with time.

The doubling of speed could really be called "Gates Law" as Bill Gates is the one that made this statement, based on Moore's Law, in the late 1980's (again, the "Lives and Deaths of Moore's Law" offers some interesting perspectives on this).



But it is also much slower. Witness the latest turns of the Itanium.


The G5 is indeed a great machine. But it totally sucks at running PC software, even under emulation, as Moto apparently dropped the "endian bit" in the PSR. Indeed, I just read an article a couple weeks ago about how Microsoft was having to hold back the release of VirtualPC for the pack exactly because of this issue. Then, of course, there is the issue of emulating a Pentium (which tops out these days at around 3.5 GHz) with a 2.5 GHz G5. No amount of hand waving by Steve Jobs is going to cover that spread.

Again, it would be wonderful to have a brand-new architecture designed for high performance from the ground up. Who's going to pay for all the new software, though?
Cheers,
Randy Hyde

http://www.mediaworkstation.com/articles/viewarticle.jsp?id=25633-1

Some interesting things to see... The Boxx dual Xeon can sometimes not beat the Dell single P4 at all. And at all times, the difference is smaller than 100%, often even considerably smaller.
(Note also that the Dell only has 1 GB, vs 4 GB of the dual machine, that probably also has some influence on the scores). Sadly there is no single Opteron included, but I'm quite sure that the reason why the dual Xeon is not faster is because the software is single-threaded, so I expect the same to happen on a single Opteron system.
Needless to say that for such tasks, it's a total waste to get more than one CPU.

Note also that the Alienware dual Xeon is still quite a bit faster in CineBench than the Opteron, while also costing less. So while the Opteron may be doing better with After Effects, it is not the best choice for everyone.

Elaborate?



Yes, but do you think that Intel and AMD try to do this verification on a simple 32 bit x86 PC or so? I doubt that sincerely.



So you get a single core with 50% waste material attached to it?
At best it works as good as a single core CPU (probably less, because building 2 cores on one die means that you have more transistors, and more problems with heat, routing of power, etc).
So how can it be interpreted as positive, since it is at best only as good as a single core?

You will at least have to point me in the right direction. That is, assuming you are not just making unfounded flames against Intel's multi-processor designs.



Wow, did someone just admit that not everything can be done in parallel in an efficient way?



If you think that MMX/SSE has anything to do with RISC, then it's you who needs to do some research.