Author: Robert Hyatt
Date: 15:23:59 03/06/03
Go up one level in this thread
On March 06, 2003 at 17:47:45, Jeremiah Penery wrote: >On March 06, 2003 at 11:48:47, Robert Hyatt wrote: > >>On March 05, 2003 at 22:38:44, Jeremiah Penery wrote: >> >>>On March 05, 2003 at 18:26:10, Robert Hyatt wrote: >>> >>>>The point of my comments is that Intel sets a sort of standard, and if someone >>>>follows along, >>>>but are not quite all there, it can cause problems. I had this problem with >>>>Cyrix years ago as >>>>their 387's were actually more accurate than Intel's, not to mention faster. >>>>And they would >>>>make every diagnostic program on the planet sound the alarm with floating point >>>>errors. :) >>>> >>>>And I got tired of the phone calls asking about it and quit recommending them. >>>>:) >>> >>>Why should a company be penalized for making a better product? >> >> >>Making a processor that is "PII-compatible" but really isn't, is "better"? >> >>My point. > >Please, Bob, you're forgetting to read again. You gave the example of Cyrix >being better, and being penalized for it. No. "better" is a relative term. If it is "better but incompatible" then it is ultimately not "better". Which was my point. AMD may well be faster than Intel. The K6 may have been faster than the PII. But it had a compatibility issue. > >>>>>>If everyone was a compiler expert, this might be forseeable. But they aren't. >>>>>>And I doubt >>>>>>most would think that -target=pentiumII would break a processor that is supposed >>>>>>to be >>>>>>compatible. >>>>>> >>>>>>Can I say more? >>>>> >>>>>A lot of the average programmers probably don't even know to use a specific >>>>>processor target (when using GCC), or they use some other compiler. I'd expect >>>>>someone who uses specific processor targets in their compile to have some basic >>>>>understanding of assembly. >>>> >>>>I wouldn't. If you look at the simple help files, you might see: >>> >>>And you think even 5% of people look at help files? :) >> >>Again, my point. I don't think .01% of people look at help files. They would >>assume >>that their PII-compatible processor really is PII-compatible and contact me >>about a bug >>in _my_ program. >> >>However, I'll bet that anybody compiling a C program they write will do a "man >>gcc" >>on a unix box because they have heard about -O and want to see what else there >>is to >>make their handy-dandy chess engine as fast as possible. >> >>>>They don't even understand assembly language, much less instructions, much less >>>>any >>>>more details that are necessary to even understand that there might be a >>>>problem. >>>> >>>>Remember, that intellect represents 99%+ of all the computer users on the >>>>planet. >>> >>>And probably 99.9% of those people are not going to using anything but >>>store-bought programs, which will check for processor support (or use basic >>>386-like instructions that MSVC emits), so they never run into this kind of >> >>Well over 1M _different_ IP addresses has downloaded Crafty. When you consider >>that places like AOL.com appear to use one IP for _many_ customers, you can >>figure >>that maybe that number is 2M or higher. > >AOL also uses many different IP addresses for a single customer, so you can't >use that to determine any kind of number. I've probably downloaded Crafty from >at least 20 different IP addresses myself. > >If those people are using Windows, they either just download the executable or >compile it using (probably) MSVC. Either way, they're only using basic 386 >instructions emitted by MSVC. The Linux users probably compile it themselves, >targeted to their specific processor, so there's no chance of failure there >either. There's a very tiny chance that someone will run into an >incompatibility. Yeah, it's happened a couple times before, but some people >have been hit by lightning multiple times too. I can only relay raw numbers of course. We quit counting at 1M unique addresses that downloaded anything with "crafty" in the name, which excluded the tablebase stuff and the opening book stuff. I could probably get a handle on the number of addresses that downloaded the .tar/.zip files. That was way over 100K at one time, although it is hard to say whether they grabbed the wrong files (many do) or just wanted to look without compiling. > >>I do a _lot_ of continuing education courses here at UAB. Which puts me into >>contact with >>"rank beginner" type computer users. And _all_ have downloaded freeware >>programs. From >>screen-shot capturers, to chat programs, to you-name-it. I'd bet that way over >>50% of all >>computer users have sampled freeware programs, which makes this an issue again. > >Do you think chat programs and screenshot programs are anything approaching >speed-critical? No way anyone would compile that targeted at a specific >processor, knowing that it would eliminate some of their audience. Hard to say. I compile _everything_ I do with the best optimizations I have found. > >Under Windows, which almost everyone uses, this is pretty much a non-issue. >In Linux, most programs have source code released, and users should learn to >compile things on their own. > >>Of course >>AMD might have fixed the cmov problem in later versions, I don't know since I >>don't use 'em. >>But the mine was laid and armed, and way more than you might guess stepped on >>it. >> >>As far as using "basic 386 instructions" that _really_ makes me want to puke. > >Go bug Microsoft about it then. Their compiler is the one that only emits that >set of instructions. > >>Why do you >>think the Intel folks added the new instructions? Just to be incompatible? Or > >It wouldn't be surprising if that had something to do with it. MMX/SSE/SSE2 are >ok - they're somewhat usable, and even useful in certain types of applications. >They could have been made far better. Maybe they're useful for FP stuff because >the normal x87 stack-based FP is a disgusting design. I'm not going to try to speculate on "why" they added cmov. I _assume_ it was because of the performance issue associated with branch mis-predictions, and the relevant information from the alpha folks that did this first. They _could_ have been trying to cause a ripple in the compatibility issue, but I have no idea how one might go about proving that and thus the speculation is hopelessly mired in guesswork. > >>to speed things >>up? I bugged the GCC folks for a _long_ time about cmov, for example, because I >>had used >>a similar instruction on the early alpha processors and thought it was an >>interesting solution >>to a known problem. >> >>Instead of using the new stuff, you seem to be suggesting that it is better to >>only use what is >>available on _both_ processors, which (to me) is senseless. > >Again, go bug Microsoft about that one. Their compiler emits only the basic 386 >instructions, and it doesn't seem to be lagging in speed behind the other >compilers. Nope. But it could _probably_ be even faster, of course... IE Intel does produce instructions to efficiently use what their processor supports.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.