Computer Chess Club Archives


Search

Terms

Messages

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

Author: Robert Hyatt

Date: 12:17:12 03/04/03

Go up one level in this thread


On March 04, 2003 at 13:38:53, Matt Taylor wrote:

>On March 04, 2003 at 00:39:55, Robert Hyatt wrote:
>
>>On March 04, 2003 at 00:09:19, Matt Taylor wrote:
>>
>>>On March 03, 2003 at 20:21:47, Robert Hyatt wrote:
>>>
>>>>On March 03, 2003 at 19:59:47, Matt Taylor wrote:
>>>>
>>>>>On March 03, 2003 at 17:25:18, Robert Hyatt wrote:
>>>>>
>>><snip>
>>>>>>Wait.  The problem happened _after_ the pentium was "gone".  IE after P6 and
>>>>>>PII were out.  I was compiling for the pentium pro and beyond, and at the time
>>>>>>AMD was still selling whatever processor they produced that didn't have CMOV.
>>>>>
>>>>>Why does that matter? From the beginning the spec said "check for cmovcc using
>>>>>cpuid." If you didn't, that's your fault, not AMD's fault. AMD processors
>>>>>followed the spec.
>>>>
>>>>What do you do for software that is running on your friend's PII, but when you
>>>>load it on your AMD it crashes?  You are simply a naive user and don't know
>>>>anything about architecture.  You just know that when you went down to comp-USA,
>>>>they told you "this machine will do anything the intel-based machine will do,
>>>>for a
>>>>few hundred bucks less."
>>>
>>>I would probably blame the software for being buggy. Then again, I'm not
>>>terribly naive.
>>>
>>>I don't see how this changes things, anyway. You're talking about perception of
>>>who is to blame. That doesn't change the fact that the software is buggy because
>>>it does not conform to spec. Every time someone assumes something that isn't
>>>guaranteed, their software always fails. That doesn't mean the new environment
>>>is to blame; it means the software is buggy.
>>
>>So, back to my earlier example, you think that "Mrs John Doe" should _know_
>>that when she sees 110v 30a that such an appliance won't plug in and run in
>>her house?  Even though it is replacing one that does plug in and run?  She
>>is supposed to verify what the salesman says?
>>
>>I think the company has some responsibility in its advertising to be specific
>>about what an appliance (or a microprocessor) will and won't do.  "equivalent
>>to Intel" has a meaning to the lay-public.  And it _isn't_ "almost the same,
>>although some programs might not run."
>>
>>>
>>>I guess I should add a 4th reason to that list. The 4th reason would be buggy,
>>>incompatible software.
>>
>>Software _can't_ be incompatible, when a chip vendor says "buy mine, it is
>>compatible with theirs and it is cheaper and faster."  The buyer has to
>>determine whether it is or not?
>
>The spec still says that you have to check via cpuid. I consider software that
>does not follow the spec to be buggy. It is the same reason why you can't always
>take a POSIX program and run it on another POSIX platform. There are bugs in the
>libraries sometimes. If they all followed spec, there would be no porting
>issues. Same thing for the ISA.

I consider roadways with huge potholes to be buggy.  But my vehicle still has to
travel over them.  I can see the potholes.  The average person can't see the
problems
they might hit until it is too late.

Remember my only point here is that the "follower" didn't keep up very quickly,
and
it introduced a "quirk" that purchasers of the "follower" had to deal with,
while
purchasers of the "leader" did not.  Some consider that a big deal.  Notably the
users
of the software that fails on the follower, and the developer of the software
that doesn't
have a "follower" processor handy and doesn't understand why his software is
breaking.

And he doesn't want to take the time to compare the two processors to see which
supports
what....




>
>>>>It won't, always.  I didn't fail to test the CPUID capability flags, and the
>>>>compiler wasn't
>>>>told to do so for speed reasons.  And there starts a long, complex, worrisome
>>>>path to
>>>>aggravation.  Because the "compatible processor" wasn't "really compatible".  We
>>>>can
>>>>argue about whose fault it is, whether the salesperson should have said "it is
>>>>almost
>>>>the same but it is missing some new instructions that might cause you problems
>>>>if an
>>>>application is compiled specifically for the pentiumII."  Or whether the
>>>>compiler should
>>>>test for CMOV capability, which I would strongly object to when I want to target
>>>>a specific
>>>>machine for max performance.  Or whether we should blame Microsoft (they seem to
>>>>be
>>>>a good company to blame for anything.  :)  )
>>>
>>>The CPUID test can be done during initialization. For a flexible system, you can
>>>use function pointers and do it at runtime. This has obvious disadvantages. You
>>>can also patch the program at runtime. There are a billion options, but the
>>>fallback method is to bail up-front if you don't have support for cmovcc. That's
>>>easy, and it costs only a few nanoseconds during initialization.
>>>
>>
>>
>>And branches everywhere you need to decide which block of code to
>>use (CMOV or CMP/JE/JNE).
>
>Nope. The easiest way is to check for cmov in the init code. If you have no
>cmov, then:
>    printf("Your system is not supported.);
>    exit(-1);

That is no better than crashing.  You save the developer the debugging time.
But you
have a dissatisfied user because his machine was labeled "Intel compatible."



>
>Alternatively you can trap the illegal instruction exception and emulate it
>(horribly slow on processors that don't support cmovcc). Or you can self-modify
>(cache line flush paid for each cmovcc). Or you can use a bloated exe and use
>function pointers to dynamically select which routines you use (penalty paid
>every time a new branch is encountered). Or you can dynamically relink yourself
>(penalty paid on startup, no runtime penalty).
>
>There are a thousand ways to handle this, some easier than others, but all are
>better than crossing your fingers and hoping the end user has cmovcc support.
>They're also better than trying to figure out why the program broke for one
>person and not another.

And all I am is a person that wrote a program, and am giving it away for others
to
use.  And I (I = any software developer, knowledgable or not) have to figure out
what
might or might not be supported, when I don't even know that my compiler is
using
cmov nor what that is...




>
>>>The fault still lies in the software because CPUID vector 1 feature flag
>>>detection is the -standard- way to do it, and it has been well publicized in
>>>Intel literature. The Pentium does not support cmovcc
>>
>>No, but the PII did.  And AMD _claimed_ that the K6 was (a) compatible;
>>(b) faster and (c) cheaper.  (b) and (c) are meaningless if (a) is false.
>
>But compatible means nothing...


<the point>

:)

But to some users it means a promise of something...




>
>>Is it good practice to do that?  IE by PII buddy compiles a program and I say
>>"hey, I just bought me a shiney new AMD that is faster than your PII, so let
>>me try that...  wwwhhhaaattttt???  It crashes every time?  What would cause
>>that?"
>>
>>I think that is gross.
>
>Software that uses CPUID vector 1 to check feature flags doesn't crash like
>this. I used a K6 for a couple years, and I've never seen a program crash that
>wasn't reputably buggy.

Crafty.

Hardly "reputably buggy".  In SpecINT.  In various linux distributions.  Yet it
caused problems for the case mentioned.  I _knew_ it was using a PII
instruction.
Earlier versions used a pentium instruction (BSF/BSR) and was so noted.  But I
had no idea that AMD processors did not have the normal PII instructions.  And
had no place to look without having one on hand.  And if I had had a complete
set
of docs, I wouldn't have looked because it was _unexpected_.


>
>>_many_ people don't even know they are running AMD.  Again, the old crafty list
>>would have shown this clearly.  It was a pretty common issue back when PII and
>>K6 were competing.  And it got to the point that for every crash, the first
>>response from anybody on the list would be "AMD?  or Intel?"
>>
>>That highlights the problem.
>>
>>I spent a lot of time setting up positions, testing, and communicating with
>>the users reporting problems.  Until we finally stumbled onto the AMD issue.
>
>But it is a non-issue. How can you ignore Intel specifically saying you need to
>check the feature flags? Intel has set the spec up so they can remove newer
>parts of the ISA if they want. If you rely on the assumption that they never
>remove features, your program will break.

Again, take a programmer using a compiler to compile his program and give it to
others.  Does that programmer have a responsiblity to understand the underlying
processor ISA?  If so, why do we even have compilers to abstract away the
underlying
hardware ISA in the first place?  Those are details that the average users don't
understand,
and don't even know exist.


>
>>>>But, in reality, there was an unhappy user.  And a lot of testing back and forth
>>>>with emails
>>>>to the crafty list, before we figured out what was happening.
>>>>
>>>>Now I know to ask that question (Intel or AMD) but I didn't at the time, not
>>>>being an
>>>>AMD user.  I assumed that if Intel and AMD were producing chips at the same
>>>>time,
>>>>with AMD claiming compatibility, that the two _really_ were compatible.  not
>>>>that
>>>>one had missing instructions that I could detect if I wanted to...
>>>
>>>Compatibility with the spec, yes. Part-for-part compatibility, no. No Intel chip
>>>has been part-for-part compatible with any other Intel chip.
>>
>>_Every_ PII would run any pre-PII program.  _every_ PIII would run any PII or
>>earlier program.  We said "PII required".  And at that time, AMD was claiming
>>superiority in terms of speed and price.  But it _wasn't_ "fully compatible".
>
>Again, the spec says you must check CPUID vector 1 for feature flags. The K6 was
>perfectly compatible because it reports that it doesn't have cmovcc.
>"Compatibility" does not mean "supports the same things," it means "correctly
>follows the specification." I've never heard AMD say, "Our K6 can do everything
>the Pentium 2 can do!" They simply claimed Intel compatibility, and they were
>right. Crafty is the only instance I have heard of where ISA implementation
>differences broke a program.

And again, it doesn't matter what the "spec says".  It matters that the sticker
on the box
says AMD processor, Intel compatible.  And the user takes that at its face
value.  The
term "compatible" means one thing to an assembly language programmer with O/S
and
architecture experience.  It means _something else_ to the average end-user.
That's
my point.  And it is where AMD had a bad rep (perhaps undeservedly to the
technically
savvy).


>
>The branch mispredict penalty on a K6 was something like 3 cycles. That's
>probably why they didn't bother implementing cmovcc.
>

And nobody says that was unreasonable.  It just caused headaches for _others_.



>>>The spec -still- says you don't have to support cmovcc, MMX, SSE, etc. In fact,
>>>the VIA C3 processor doesn't support most of it. (I can't remember what they do
>>>support, but it's very minimalist.) The VIA C3 is perfectly compliant because it
>>>properly reports this through CPUID vector 1.
>>>
>>>Any software that assumes the processor has cmovcc should either publish that
>>>fact, or it should check the processor with cpuid. (Users are stupid so it
>>>should probably check anyway.)
>>>
>>>>>>I didn't tell the compiler "produce code that will run on any machine" I told
>>>>>>it "produce code for the P6 instructions (or PII, I don't recall now)"  And
>>>>>>new AMD machines were having problems.  I certainly don't remember now whether
>>>>>>it was only K5 or early K6, that was too far back.  I just remember the problem,
>>>>>>although we also saw it a _few_ times with people using old original pentium
>>>>>>processors of course...
>>>>>
>>>>>If you require P6 instruction support, it won't work on the K6. You wouldn't
>>>>>expect a Pentium to work with P6 instructions, would you? The K6 is stuck
>>>>>somewhere in between.
>>>>
>>>>I understand.  But the problem is that the K7 was selling at _exactly_ the same
>>>>time
>>>>as the P6/PII.  And advertised as "compatible but more bang for the buck."  And
>>>>it
>>>>did cause some confusion.
>>><snip>
>>>
>>>The K6 is compatible by the docs. A lot of software is broken, but there is only
>>>so much you can do about that. It is unfortunate that AMD is penalized for
>>>making a better product.
>>
>>In this case it _might_ have been better.  But the advertisements which put
>>it head to head with the PII were not exactly kosher.
>
>What advertisements are you talking about?

Go to Comp-USA and look at the boxes.  Or advertisements in PC-Magazine,
PC-World,
etc.  back when the k6 and PII were head-to-head.  Or various web sites that
compared both
in the way of "consumer reports"...





>
>>>Technically AMD didn't make any such claims about the K6 because they haven't
>>>been allowed to advertise.
>>
>>I don't know what that means. They won't sell without marketing.
>
>Ask Vincent. They aired commericials in Europe. They're not allowed to do that
>in the U.S.

Not talking only about TV.


>
>>>>>I wouldn't either. It's annoying to support. However, it is part of the
>>>>>architecture. Perhaps this is why VC does not generate instructions for newer
>>>>>CPUs.
>>>>>
>>>>>You encounter the same issues when dealing with people that use the original
>>>>>Pentium, 486, etc. This is why you're supposed to use cpuid to detect the
>>>>>feature set at runtime to double check. You can at least bail if it doesn't have
>>>>>a required feature. It's a bit harder when dealing with GCC because you might
>>>>>not think of some feature the compiler uses, but AMD can't really be blamed for
>>>>>that.
>>>>
>>>>I just tell everyone "it _must_ have a pentium pro  or PII or beyond."  I had
>>>>the
>>>>same problem in the 486 days where I had one floating point operation in the
>>>>whole
>>>>program to compute NPS, and on a 486SX...  crash.
>>><snip>
>>>
>>>Not all 486's had cpuid, but you can still trap the exception (Unix signal). For
>>>that matter, the cpuid instruction can also be avoided by trapping illegal
>>>instructions.
>>
>>What would I say?  I have no idea what failed, in a C program.  Bogus floating
>>point (486)?  no cmov (vanilla pentium and AMD prior to K7)?  Etc...
>
>Since it's a C program and the fault lies in the machine, you can always have
>the user recompile Crafty for their machine. That is the beauty of open-source.

There are, at last count, _way_ over 1M different machines that have downloaded
the
crafty executables.  We stopped counting 2-3 years ago after it passed 1M.  That
is
for executables.  For the source, it is more like 50K sites that have downloaded
it.

The point is that 90+% of the users don't have a C compiler, must less know how
to use
it.

I can point you to _several_ docs here at UAB that have talked to me about
Crafty, and
not a one can compile _anything_.  One is at the top of the world heap on
numbers of
heart transplants done.  So he isn't a dummy.  Just not a computer jock.


>
>Still, this is one of extremely few cases where implementation differences
>burned AMD. The biggest difference between AMD and Intel lies in their vector
>instructions, and I've never heard of an SSE program failing on a pre-Palomino
>AMD chip. I've never heard of an SSE 2 program failing on any AMD chip. They
>always behave well -- that is, they check the CPUID feature flags and bail
>(rather than crashing) when the instructions aren't supported.
>
>-Matt


And again, for commercial software, that is a reasonable requirement.  But we
are _now_
talking about freeware applications, which is becoming (if not already there)
the largest part
of the PC market.



This page took 0.01 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.