AMD vs. Intel

[Jerry Jones]

http://www.digitalvideoediting.com/H...el_vs_amd1.htm

[Pertti]

Interesting article, but still mainly just another benchmark, and as such has little to offer in deciding between the two platforms.

Speed isn't everything, even though the marketing departments would like us to think it is.

[wkulecz]

Agreed, "speed" is not the only parameter of importance.

I'm afraid real world performance is starting to suffer as hardware and drivers are being tweaked to score well on some stupid benchmark that marketeers love to talk about.

In my experience the AMD processors are being held back by the buggy VIA chipsets and poorly performaning IDE interfaces on most of the offerings.

Hopefully the AMD 760 chipset will change things for the better once it gets into the mainstream.

--wally.

[Brian Ellis]

... and not every software manufacturer will support their products on anything but Intel...

------------------
Brian (the terrible)

[wkulecz]

Big red flag for poor quality software!

The "supported on" is supposed to be the OS the system is running. It is the job of the OS to hide the hardware details from the software. If the application is using knowledge of the hardware not encapsulated thru a OS device driver, you are just asking for trouble latter. DirectCD and all its problems is a perfect example of this. (I use DirecCD because with it I can burn from slow 10BaseT network drives, but I don't recommend it, and certainly not for its alledged purpose of making CD-RW a "giant floppy")

I absolutely won't buy anything that is locked to a specific CPU type! Allowing this crap would take planned obsolesence to new heights!

--wally.


[This message has been edited by wkulecz (edited 18 December 2000).]

[Brian Ellis]

Wally

There are many hi-tech scientific apps that must "short-circuit" the OS to get the required performance, by using the CPU instruction set directly. The OS is used only as an interface to set the software moving and then displaying the results after the numbers have been crunched. The problem is that using Windows, in any flavour, is s-l-o-o-o-w. I developed an instrument, several years ago, that captured vast quantities of data and preprocessed it before recording a digest of it on redundant hard disks. The essential parts were using machine instructions with the fastest CPU then available, P200. It would not work with either Cyrix or AMD processors. If it had been programmed in a high-level language (even the lowest one such as C), the datarate of the capture would have been far too slow. At the other end of the scale, I developed much scientific software in the past using what was probably the highest-level language available, Asyst, a scientific dialect of Forth under MS-DOS. The makers, Keithley, only supported Intel because the compiled instruction set relied on it. For 98% of the many thousands of complex commands, there was no problem with non-Intel CPUs, but it did fail on about 2% of them, such as regressive curve fitting, which is a highly CPU-intensive operation. Another problem we had, in the good old days of 386/486 with separate math co-processors, with Cyrix chips is that the co-processor would overheat with intensive usage and eventually switch itself off, crashing the computer. We told our customers that you could run a given software on a 33 Mhz Intel (the tops!) or a 16 MHz Cyrix with a 33 MHz co-processor in it.

Although I've directed no scientific software development since 1997, the same problems still arise and direct instructions are still necessary, making the software CPU-sensitive. The real problem is that the Intel instruction set is so finely honed and covered by IP/secrecy, that other makers have to use work-arounds to avoid IP infringement and these are simply just not efficient. The Via chipset problem is a typical example of a similar thing.

It is not a question of poor programming. It would not surprise me if, as a result of higher datarates as computer-video improves, and the need for real-time NLE and processing expands, we will not eventually hit similar problems in this field, with rendering done by machine-language instructions (this is why some professional systems, often using relatively slow Pentium processors, have their own specific custom hardware, as well as software).

------------------
Brian (the terrible)

[wkulecz]

I'm not talking about needing SIMD instuctions and only supporting the Intel flavor. On stuff this specific the market is small and you truely have to develop it twice -- once for Intel and once for the AMD flavor of SIMD.

In the old days I used to write FORTH code too! For these kinds of things people buy the computer you tell them they need and its only when the competition supports the cheaper hardware that you have to start worring about it.

On shrink wrap software or hardware in retail boxes if they don't play by the rules of the OS then its a red flag that normal users shouldn't be messing with trying to use it! and in my opinion it borders on fraud to be trying to sell it to non-experts!

VIA (or anyone else) either builds chipsets that work correctly with the MS supplied drivers or they have to write the drivers to properly interface their hardware to the OS. If they can't do it, they need to go out of business.

Remember when Microsoft Flight Simulator was THE hardware compatability test?

--wally.