Computer Chess Club Archives


Search

Terms

Messages

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

Author: Andrew Dados

Date: 15:09:45 03/06/03

Go up one level in this thread


On March 06, 2003 at 11:40:16, Robert Hyatt wrote:

>On March 06, 2003 at 08:14:00, Andrew Dados wrote:
>
>>On March 05, 2003 at 22:56:50, Robert Hyatt wrote:
>>
>>>On March 04, 2003 at 21:55:55, Jeremiah Penery wrote:
>>>
>>>>On March 04, 2003 at 11:23:17, Robert Hyatt wrote:
>>>>
>>>>>On March 03, 2003 at 22:05:39, Jeremiah Penery wrote:
>>>>>
>>>>>>On March 02, 2003 at 23:43:41, Robert Hyatt wrote:
>>>>>>
>>>>>>>It was about (for example) Wal-Mart.  They are _not_ copying another operation.
>>>>>>
>>>>>>No?  There weren't other large-scale discount retailers before them?  I can name
>>>>>>more than a few.  Even if they didn't copy someone, how does it say they exhibit
>>>>>>'no innovation'?
>>>>>
>>>>>What _technology_ are they copying?  Do they have to look _exactly_ like another
>>>>>store in order to sell?  What _other_ stores have both normal merchandise _and_
>>>>>large
>>>>>grocery operations together?
>>>>
>>>>KMart, Target, Meijer, to name 3 off the top of my head.
>>>
>>>We have K-marts all over the place here in alabama, most going out of
>>>business.  No groceries in any of them.  Target is the same down here.
>>>Big department store, but no groceries.  Never seen Meijer.
>>>
>>>
>>>>
>>>>>>>They are a retail seller.  What did Boeing copy?  The 707?  First commercial
>>>>>>>jet airliner?  Visa?  None of those are "innovation-heavy" things.  They are
>>>>>>>simply businesses.
>>>>>>
>>>>>>Which ones aren't innovation-heavy?  To claim that any company who has emerged
>>>>>>to market _dominance_, in ANY field, hasn't innovated a great deal is, again,
>>>>>>laughable.
>>>>>
>>>>>Har-de-har-har.  There.  I laughed.  Happy?  Now tell me what precise
>>>>>specifications Wal-Mart
>>>>>has to follow in order to compete with another store?   Precisely how fast they
>>>>>have to serve
>>>>>a customer.  How many square feet for this department, how many for that?
>>>>
>>>>So tell me precicely how many cycles AMD processors have to execute each x86
>>>>instruction, how much cache they must have, how many transistors they should
>>>>use, and the core voltage they must use in order to be "compatible" by your
>>>>definition.
>>>
>>>
>>>The precise specification is that written by Intel, which is my point.  A
>>>program with timing loops is bad programming, but it still works on Intel
>>>boxes if it is developed there.  It won't work on something that behaves
>>>differently.  But, back to the _real_ point.  A cpu that supposedly competes
>>>with the PII should be _compatible_ with the PII at any level of abstraction
>>>a user might want.  All the way up to the output from a compiler that targets
>>>the PII processor with an executable.  The K6 failed that test and led to some
>>>bad vibes.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>It's (again) _not_ the same thing and to claim it is is pretty funny.
>>>>>
>>>>>Har-de-har-har again...
>>>>
>>>>You're making absurd comparisons.
>>>>
>>>>>>>they will always be "behind".  Because Intel will change the specs, and start
>>>>>>>shipping chips, and AMD has to quickly catch up.  That's just the way it is
>>>>>>>when you are copying your competition's product exactly...
>>>>>>
>>>>>>Intel isn't forced to license the instructions (SSE, SSE2, etc.) to AMD.  If
>>>>>>they really thought that supporting some instructions that AMD doesn't support
>>>>>>would be crushing, they wouldn't license the instructions.
>>>>>>
>>>>>
>>>>>
>>>>>You need some business experience.  The issue is _timing_.  I can safely
>>>>>deliver a version of Crafty today that has something nobody has seen before.
>>>>>If it makes it better, I can sell many versions before everybody else figure
>>>>>it out and "catch up".  The "window of opportunity" is what this is about, not
>>>>>monopolistic practices..
>>>>
>>>>If you made patented advances in Crafty, which required licenses for the
>>>>opponents to use, your window would be eternity if you wanted it to be.  That's
>>>>the situation Intel is in.
>>>
>>>And???  The window is there for the leader whether there are licensing issues
>>>or not.
>>>
>>>
>>>>
>>>>>When Intel announces something "new" they have a window that stretches for
>>>>>however long it
>>>>>takes the opposition to implement the changes.  Or if they choose not to, they
>>>>>can choose to
>>>>>make those "changes" a big deal in advertising which will hurt the competition.
>>>>>So the
>>>>>followers have to follow for the most part.
>>>>
>>>>AMD _can't_ implement SSE (or whatever) unless Intel licenses it to them.  If it
>>>>was that big of a deal, Intel wouldn't license it at all.
>>>
>>>
>>>Why are we off onto SSE?  It hasn't been a problem.  Cmov _was_ a problem
>>>that was documented and mentioned in many discussion groups.
>>>
>>>
>>>
>>>
>>>>
>>>>>>Here's something funny.  The x86 ISA requires that when an FPU exception occurs,
>>>>>>a certain instruction can read what instruction caused it, and where it
>>>>>>happened.  Pentium4 can't do this.  So can we call the P4 incompatible with x86?
>>>>>>:)
>>>>>
>>>>>Doesn't matter.  PIV is compatible with PIV.  It is the "leader".  It doesn't
>>>>>matter what they
>>>>>do, what matters is can the followers do it too so that they can sell???
>>>>
>>>>If you have software that depends on that feature, which worked on EVERY x86
>>>>processor EVER, you'd call the P4 buggy.  P4 claims to be completely backward
>>>>compatible (You even claimed earlier it was compatible with the old 4004), but
>>>>it is demonstrably not in this instance.  You demonize AMD for claiming
>>>>compatibility with the K6, and use buggy software as a demonstration that the
>>>>claim is untrue.  But when the P4 is not even backward compatible (which is FAR
>>>>more important) it's somehow ok?
>>>
>>>
>>>I haven't "demonized" anyone.  I pointed out a specific problem that I had to
>>>deal with.  One, a bad processor (K5).  Two, an incompatibility issue between
>>>two supposedly "equal" processors, the K6 and the P2.  If that is "demonizing"
>>>then I guess I did it, but that was not my intent.  It simply points out that
>>>Intel is setting the "standard" because a program runs on _all_ their PII
>>>processors, and when it doesn't run on a competitor's processor because they
>>>_chose_ to leave something out, that can be an issue.
>>>
>>>
>>>>
>>>>>>>>Several companies had commercial aircraft before Boeing.
>>>>>>>
>>>>>>>Who made the first commercial jet airliner?  'nuff said.
>>>>>>
>>>>>>De Havilland, not Boeing.
>>>>>
>>>>>Eh?  First commercial/military jet I saw, as I grew up, was the 707.  If
>>>>someone
>>>>>beat them by a few months, oh well.  But they weren't _copying_ anything as
>>>>>there
>>>>>was nothing to copy.
>>>>
>>>>The DeHavilland Comet came out years before the 707.  Those other jet airliners
>>>>I mentioned were also years before the 707.
>>>>
>>>>>Right.  Don't you think if they were _exact_ clones, just cheaper, they would be
>>>>>selling
>>>>>_more_?
>>>>
>>>>If that were so, WalMart brand tissues would outsell Kleenex, but I doubt they
>>>>do.  It's about brand name.  You would buy Intel anyway, and so would a whole
>>>>lot of other people, just because they're Intel.
>>>
>>>Absolutely _wrong_.  We buy them because the name is "intel" _and_ we have had
>>>good success using Intel.  They could be called stinkems instead of Intel and
>>>if the reputation had been built over the 25-30 years of microprocessors, then
>>>we'd all be buying stinkems instead.  The name is tied to success, and _that_
>>>is what leads me back to them.  I will occasionally try new things, but when
>>>things are critical, I want what works _first_ and I'll try something new when
>>>I'm playing, to see if it works.
>>>
>>
>>And yet you are using linux... strange. Microsoft name is tied to success :)
>
>If Microsoft had released a unix system, I'd probably be using it, too.  I have
>been
>a unix user since the late 70's after Ken Thompson got me interested.  That is
>why I
>use Linux.  "features".  Not "name".  Although in the public-domain unix
>variants,
>Linux has become the "Intel" of unix when you mention SCO, Xenix, Solaris-X86,
>and so forth, as they are all lousy compared to Linux.
>
>>
>>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?
>
>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?
>
>OK.  Not a real good case.  Lets turn it in to you buy a 1968 Plymouth Road
>Runner with
>the 426 Hemi engine from someone in 1978.  You run it for a bit and the engine
>falls
>apart.  Who is at fault?  You made a valid assumption (the car will run on pump
>gas with
>a minimum octane as specified on the filler lid).  It was wrong.
>
>Now to the AMD/INTEL comparison.  You buy a car from X that's brand new, and
>after
>$5K miles it falls apart.  You take it to the dealer and he says "Hey, you are
>using unleaded
>fuel and you ruined the engine.  It isn't covered by the warranty if you read
>through the 100 page
>warranty manual you got with the car."  You notice every _other_ automobile on
>the road runs
>just fine on unleaded, and you assumed yours did too.  Who's at fault?
>Technically, the owner's
>manual mentions it in one sentence out of 100 pages.  Technically you could find
>out about the
>engine's specs and discover the valve seats and heads are not hardened and need
>lead for
>lubrication.  But _practically_ you are screwed because someone makes an
>automobile that
>competes with the others on the market, with one significant problem.
>
>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?


I think putting equal sign between end user and developer is wrong.

Better analogy: You produce transmissions for Chrysler engines. Engines are all
compatible. One of them has a bit higher rpm specs which wears your transmission
off in a month. And rpm is documented. And checking for that is trivial.

Now, the old lady will blame Chrysler. Chrysler will sue you, win the case and
use other supplier.

cmov is processors _feature_, like sse or mmx. Noone relies blindly on mmx
presence, why one would rely on cmov presence? One may say it is gcc fault not
to check if your build was sane and will run on actual processor. I say if
developer knows to put very specific compile options he should better learn what
they do.

-Andrew-
>
>
>
>
>
>
>>
>>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.
>
>If that was my fault, in your mind, fine.  I accept responsibility for not
>taking the time
>to pull up _all_ the hardware documentation for AMD and Intel and comparing
>those
>3-4000 pages of information in detail to be sure everything was compatible.  I
>was too
>lazy.
>
>
>
>
>
>
>
>>
>>They are cheaper and faster for most of us on this forum... and they run all
>>OSes and programs for me just fine. And P4 is an expensive, slow cow for me.
>>
>>-Andrew-
>
>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.



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.