Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Introducing "No-Moore's Law"

Author: Matt Taylor

Date: 21:42:23 03/07/03

Go up one level in this thread


On March 07, 2003 at 23:37:24, Robert Hyatt wrote:

>On March 07, 2003 at 17:42:42, Matt Taylor wrote:
>
>>On March 06, 2003 at 11:40:16, Robert Hyatt wrote:
>>
>>>On March 06, 2003 at 08:14:00, Andrew Dados wrote:
>>>
>><snip>
>>>>Now.. when you or whoever made crafty binary didn't read specs and released
>>>>buggy software (assuming it can be compiled for PII and run on k6), you try to
>>>>blame AMD for that.
>>>
>>>I'm not blaming AMD for me not reading the specs.  If you don't follow the
>>>problem
>>>there is little I can do to convince you there is a problem.  But suppose a
>>>brand new programmer
>>>compiles something and sends it to his buddy where it promptly crashes.  Is it
>>>_his_ fault that
>>>he didn't realize Intel PII had instructions the AMD K6 (PII compatible) didn't
>>>have?
>>
>>Yes.
>>
>>Usually companies will state that it works under a specific set of conditions.
>>Some people will try to run it on other hardware, and it will sometimes work.
>>Other times it fails. When they ask for tech support, the tech tells them that
>>the company does not warranty that the product operates on his hardware.
>>
>>>You buy a car in 1966.  You put it in a garage for 10 years while you are out of
>>>the
>>>country.  You come back, and after driving it 5000 miles the engine falls apart.
>>> Upon
>>>inspection, the valve seats have worn and the valves broke, destroying the
>>>engine.  Should
>>>_you_ have known that in the 10 years you were away, we switched to unleaded
>>>fuel and
>>>your engine depended on the lead for valve seat lubrication?
>>
>>I can't speak for 1966 since I was not alive at that point in time. However, my
>>car came with a manual that specifies that my car runs best with 87 octane fuel.
>>As a result, I buy 87 octane gas when I put fuel in my car.
>>
>>In the AMD/Intel analogy, the manual is around. It is not as obvious, but
>>ignorance does not make it AMD's fault.
>
>No... but it causes problems.  IE suppose _today_ someone sells a car that
>requires leaded gas?  Who would expect that since everybody else uses
>unleaded?  Does an 80-year old Grandmother have to read all the owner's
>manual and warranty booklet to find the fine print "leaded fuel only?"

And 30 years in the automobile industry is somehow equivalent to a couple years
in the chip industry? While systems become outdated in a mere 3 months,
architectures and implementations themselves last much longer.

>That's the point.  Yes, I suppose you could make a case that anybody should
>read the docs before they use the product.  But in reality, you know that
>nobody does, because the assumption is that all vehicles use currently available
>unleaded fuel unless great big warning signs are everywhere...

Your analogy is flawed at the core. A better analogy would be condemning
Plymouth for releasing an automobile with a big sign on the side that says,
"Leaded fuel," when it breaks after the owner puts in unleaded gasoline. The K6
has a big stamp on it called CPUID that says, "I can't do cmovcc."

>><snip>
>>>That is where we were with the PII/K6 problem.  _technically_ it was a user
>>>problem.  But
>>>what about "practically"?  Does a little old lady that is 70 years old have to
>>>investigate such
>>>details about her new vehicle, when she couldn't tell the difference between a
>>>spark plug and
>>>a spare tire?
>>
>>Technically it was a developer problem because users aren't expected to know the
>>difference between a K6, Winchip, 5x86, or any of the other billion competing
>>chips. The CPUID instruction was not originally added for this purpose, but it
>>was not long before this became a very integral role of the instruction.
>
>Unfortunately, there are "80 year old grandmother developers."
>
>:)
>
>I've had more than one person send me a neat new program to test, not knowing
>that SPARC stuff won't run on my X86 box, as an example.  If they don't know
>that, they _certainly_ won't know that within a processor "family" there are
>incompatibilities.
>
>>>>I'd think that someone with that much experience would admit to error instead of
>>>>adding to ignorant hype that AMD processors are buggy etc.
>>>
>>>First, it was not obvious.  I didn't compile the code.  I wrote the code and
>>>someone else
>>>compiled it.  And it was running fine all over the world.  A few had problems
>>>trying to
>>>run it on 486 and 586 systems but we told them quickly "this requires a
>>>pentium-II
>>>processor.  Otherwise download the non-PII version that was also there.  But
>>>when it
>>>came to the K6, which _was_ advertised as PII-compatible, nobody considered that
>>>there
>>>might be missing instructions.
>>
>>You keep claiming that it was advertised as Pentium 2 compatible, but I never
>>saw these ads.
>
>I saw them sitting side-by-side in comp USA.  With signs saying "Built with
>an AMD inside."  And magazine adds hanging in front of them showing the infamous
>"faster but cheaper".  If they are put side by side, and even AMD compared
>price and performance, it is certainly _reasonable_ to consider them to be
>compatible.  After all, nobody compares a gas automobile to a diesel auto
>without _explicitly_ pointing out the pros/cons of the non-standard fuel.

Dell sells Pentium 3 systems side-by-side with Pentium 4 systems.

>>I don't know why nobody thought to try the Pentium version on their K6 or why
>>nobody compiled Crafty for the K6, but I still don't see why this is AMD's
>>fault. The manuals were around, and even Intel said CPUID was necessary. I
>>suppose you could blame the GNU people since their compiler did not produce the
>>prolog code to check for the cmovcc extension. (Actually blaming them would be
>>useful since they might fix that.)
>
>I'm not sure it is "AMD's fault".  And I didn't really say that.  I said "this
>hurt AMD's reputation in the Intel market" because it happened many times, not
>just with Crafty.  It was a topic in many software (and compiler) newsgroups
>at the time.

Happened in your world, I suppose, but it has never happened in mine. On Windows
I have -never- seen an implementation support issue. Nearly every program I have
toyed with on my Linux machines has come source-only, so I compile for whichever
machine I'm running it on.

>><snip>
>>>Nothing wrong with your liking AMD.  This was about a problem they _did_ have
>>>and
>>>it was not isolated to just Crafty.  It happened with _many_ freeware-type
>>>programs and
>>>everyone learned that pentiumII was not a good target architecture for compilers
>>>due to
>>>the AMD incompatibility with cmov.
>>
>>Not incompatibility. The spec allows a processor to not implement cmov if it
>>reports it, and the K6 does. Perhaps the GNU compiler is incompatible. They
>>should add an x86 functionality check function to the library and call it from
>>the main function to ensure that all necessary features are implemented.
>>
>>-Matt
>
>Again, technically you are correct.  But practically, ...

Practically it is still hard to say. Perhaps I think radically different, but I
would blame the software.

-Matt



This page took 0.11 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.