Darren New <dne### [at] sanrrcom> wrote:
> FWIW, I think you overestimate how many programs use floating point. :-)
> I think the vast majority of programs people use other than perhaps games
> and other graphics type programs don't use any FP at all. Why would
> Thunderbird (for example) use FP?

I guess you *underestimate* how many programs use floating point :)

You probably won't find any modern program with a graphical user interface that
doesn't use floating point numbers somewhere - if only because the GUI
frameworks happens to use a co-ordinate system that is rather independent of
the actual screen pixels, and therefore typically uses floating point values
for the co-ordinates. Or they have some calculation somewhere that uses a
non-integer interim result.

But maybe what you mean is trigonometric functions. These, indeed, may be not so
commonplace.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Funky. I'll have to take a look to see what they're doing. Back when
> efficiency was more a concern, compilers would go out of their way to avoid
> loading FP code (like for printf()) if they didn't need to. Maybe it's
> faster to draw lines with FP nowadays than to use Bresenham or something.

I wouldn't be surprised if, somewhere at the heart of my graphics card,
Bresenham would still be very much alive and kicking :)

But the main problem, back then, was that not every computer did have an FPU
after all. Even the 486 came without one in the SX variant. (Well, in fact it
came with one, but it probably had failed QC, so instad of throwing away the
whole die it got a fuse blown or some bonding wire not attached or what have
you to just disable the faulty FPU)

Post a reply to this message

clipka wrote:
> But the main problem, back then, was that not every computer did have an FPU
> after all. 

Actually, the places I saw avoidance of FP code was done to reduce memory 
usage. If you never use a float, you don't need the library code in printf() 
that supports %f, for example.

Follow-ups redirected.

-- 
   Darren New, San Diego CA, USA (PST)
   The NFL should go international. I'd pay to
   see the Detroit Lions vs the Roman Catholics.

Post a reply to this message

clipka wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>>>   I haven't really looked at what the gcc sincos library call is doing,
>>> but it might well be that it just executes an fsincos opcode, and that
>>> the time difference is coming from the overhead of the function call.
>> You asked what a fast SSE trigonometry implementation would look like, not
>> what code your compiler generates when targeting a P4. So clearly you should
>> not be looking at the x87 implementation using the fsincos opcode when you
>> want to know how the SSE code would look like!?!
> 
> Well, wasn't one of your points that doing trigonometrics in software would be
> more efficient than using dedicated hardware?

It was not my point, it is the point made by AMD and Intel, and also the 
approach of pretty much all other CPU vendors. I am the messenger, so don't 
shoot me if you don't like the message ;-)  And I might add that testing 
something - who knows what - on a single seven year old x86 processor and 
then claiming Intel and AMD are not saying the truth is a bit "odd"...

	Thorsten

Post a reply to this message

clipka <nomail@nomail> wrote:
> But maybe what you mean is trigonometric functions. These, indeed, may be not so
> commonplace.

  Thunderbird seemed to at least use logarithms...

-- 
                                                          - Warp

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   I still see no rational reason to deliberately and on purpose break
> > 99% of programs. What would be the point? Task switching takes a negligible
> > amount of time, so skipping storing and loading the FPU registers would be
> > a rather useless micro-optimization.

> What would the purpose be of not including ISA, EISA, VESA or at least AGP slots
> on mainboards anymore?

  You missed the point: What sense does it make to drop support for the FPU
in the OS when the hardware has perfectly good FPU support?

  The issue was not whether future processors will drop support for FPU
opcodes. The issue was whether future (PC) operating systems will do so
(by simply not taking the FPU into account in task switching, which seems
rather stupid to me).

> If your software doesn't live & breathe from fast trigonometrics, fingers off
> the x87 FPU.

  You can't go and change millions of existing programs to not to use the FPU.

-- 
                                                          - Warp

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> And I might add that testing 
> something - who knows what - on a single seven year old x86 processor and 
> then claiming Intel and AMD are not saying the truth is a bit "odd"...

  It was a ridiculous sentence on purpose. You missed my sarcasm.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > What would the purpose be of not including ISA, EISA, VESA or at least AGP slots
> > on mainboards anymore?
>
>   You missed the point: What sense does it make to drop support for the FPU
> in the OS when the hardware has perfectly good FPU support?

And you missed *my* point: I just referred to hardware because it's where the
most obvious changes have been made.

The motto is phasing out old stuff. If Intel would just drop the FPU from future
designs, people would complain about *them* breaking software, and even louder
so. Everybody expects a few programs to not run under new versions of Windows -
but nobody expects any software (except very exotic ones) to crash just because
you upgraded to the newest, fastest CPU.

You have to change *somewhere* to phase out old stuff. And this *somewhere* is
the where changes *can* be made *now* without breaking *anything*: New software
being developed, and new versions of existing software being compiled. In 99% of
all cases it will just be a matter of recompiling with an up-to-date compiler
version.


> > If your software doesn't live & breathe from fast trigonometrics, fingers off
> > the x87 FPU.
>
>   You can't go and change millions of existing programs to not to use the FPU.

You didn't get *that* point either: It's currently not about those binaries out
there in the field. As of now, it's just about new binaries being *added* to
the field. The more keep going out there, the more there are to break when one
wants to actually get rid of the old stuff.

So the procedure here is deprecation, which is stopping the flow of new
"breakable" software out into the field. Once that is achieved, the procedure
will be to wait until so much of the old software has been put out of use that
not much of it will be left to be broken anyway. Most will have been replaced
by newer versions, or even whole new software.

We're not talking abount months here. We're talking about years. Lots of.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > > What would the purpose be of not including ISA, EISA, VESA or at least AGP slots
> > > on mainboards anymore?
> >
> >   You missed the point: What sense does it make to drop support for the FPU
> > in the OS when the hardware has perfectly good FPU support?

> And you missed *my* point: I just referred to hardware because it's where the
> most obvious changes have been made.

> The motto is phasing out old stuff. If Intel would just drop the FPU from future
> designs, people would complain about *them* breaking software, and even louder
> so. Everybody expects a few programs to not run under new versions of Windows -
> but nobody expects any software (except very exotic ones) to crash just because
> you upgraded to the newest, fastest CPU.

> You have to change *somewhere* to phase out old stuff. And this *somewhere* is
> the where changes *can* be made *now* without breaking *anything*: New software
> being developed, and new versions of existing software being compiled. In 99% of
> all cases it will just be a matter of recompiling with an up-to-date compiler
> version.

  And you are missing my point. All you wrote is correct, but irrelevant
with respect to what I said. Even though what you said is correct, it still
doesn't make it any more sensical for an OS to deliberately boycott 99% of
programs out there by restricting their access to a piece of hardware which
*is* there and is perfectly usable at virtually no cost.

  The day Intel decides to completely drop FPU functionality from their
new processors, that's one thing. A completely different thing is for an
OS to deliberately break millions of programs for absolutely no reason,
even though the only thing it has to do to keep them running is a few
FPU stores and loads in its task switching routines. It makes absolutely
no sense.

  If newer compilers stop producing any FPU code whatsoever, and start
producing only SSE code, that's also fine, and very understandable. It still
doesn't make it logical for an OS to boycott perfectly working hardware,
breaking millions of existing programs. It just doesn't make sense.

  Basically the OS would be making an act of sabotage against all those
programs for no good reason, which is why it doesn't make the least amount
of sense.

  Even if Intel does produce a new processor with no FPU, it would *still*
not make sense for the OS'es to drop support. Why? Because the OS'es will
be run in older processors for decades. Heck, even today there are 80386's
running and used out there. Do you remember when the 80386 was first
introduced? Something like 20 years ago?

> So the procedure here is deprecation, which is stopping the flow of new
> "breakable" software out into the field.

  You don't "deprecate" a perfectly good hardware by deliberately boycotting
it in all major operating systems and breaking 99% of programs out there.
That just doesn't make any sense.

  The way you "deprecate" it is by making newer compilers not use it. The
OS plays no role in this process.

> We're not talking abount months here. We're talking about years. Lots of.

  And exactly how does the OS drop support for the FPU gradually, during
the years?

-- 
                                                          - Warp

Post a reply to this message

On 2 Jan 2009 12:09:03 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  And you are missing my point.

Am I missing the point or is this not more suitable for OT?
-- 

Regards
     Stephen

Post a reply to this message