From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f03830a80d247012 X-Google-Attributes: gid103376,public From: "Tarjei T. Jensen" Subject: Re: fixed point vs floating point Date: 1997/11/29 Message-ID: <3480139C.24DF@online.no>#1/1 X-Deja-AN: 293634370 References: <65kgu4$289@lotho.delphi.com> Organization: Jensen programvareutvikling Newsgroups: comp.lang.ada Date: 1997-11-29T00:00:00+00:00 List-Id: Robert Dewar wrote: > > tmoran says ><< So the current crop of systems has fast fpt, slow integer */, and > slow memory. A few years ago that was not the case. Things like > MMX instructions start to move back toward fast integer arithmetic. > What's fast this year is not the same as what's fast next year. > As Mathew Heaney pointed out earlier, it would be wise to design > data types, etc, to match the problem, and then, if speed is > an issue, change things to optimize for the particular current target. > >> > > By all means one should choose floating-point or fixed-point in reponse > to the problem these days. But remember in this thread that a number of > people were in the mindset that one of the possible reasons for choosing > fixed-point was greater speed, and it seems that quite a few people were > unaware that with modern processors this reason, to the extent it is > valid at all, points in the other direction (of course specialized > processors, e.g. those with no fpt, may point in the opposite direction). Whether floating point performs better than fixed point would depend on the application. If you have an interrupt intensive application that uses float or fixed point it is conceivable that the processor would have a hard time getting value from a long floating point pipeline. I suspect one would get the same problem if there is a lot of floating point intensive processes (threads) and lots of context switches. I don't know if fixed point would do better since there might be some pipelining there as well. Shorter if I remember right, but there. It's a long time since I studied these things. I'm not up to date with the latest and greatest processors. > By the way, Tom, you keep mentioning MMX (one might almost think you were > an Intel salesperson), but I see MMX has having zero impact on general > purpose computing and general purpose compilation. It is intended for > very specialized hand-written code, and it seems very unlikely that it > is good for anything else. > > (I partly base this estimate on the experience with the i860. Remember that > these kinds of instructions are not new, they were on the i860 7 years ago, > but in practice were not useful for general purpose computing). The main problem with the i860 as I remember it was that it didn't cope very well with interrupts. Its long pipelines takes time to fill and an interrupt can devastate it in almost no time. The answer to this was to make i860 co-processor boards where the front processor handled interruptintensive things like I/O. The instruction set and performance of the i860 made it very popular with high performance graphics companies. To be honest I only know of one company using it in their graphics accelerator; SGI. Greetings, -- // Tarjei T. Jensen // tarjei@online.no || voice +47 51 62 85 58 // Support you local rescue centre: GET LOST!