Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> I believe I have provided more than enough references. You can Google for 
>> more information just as easily as I can.
> 
>   So basically you are saying that, among others, linux is going to drop
> support for programs using FPU opcodes, and you don't have any concrete
> proof of that to show me.

No, that is not what I am saying.

	Thorsten

Post a reply to this message

Warp wrote:
>   Windows, MacOS X and Linux all fully support programs which use the FPU.
> If they wouldn't, at least 99% of programs would stop working.

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?

-- 
   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

Darren New <dne### [at] sanrrcom> wrote:
> Why would Thunderbird (for example) use FP?

  To parse CSS, where many values can be represented in decimal? Also
Thunderbird most probably supports JavaScript, which in turn should
support FP...

  (Sure, it could go the hard way and use fixed-point arithmetic, but
I think it would be more logical if it used FP.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> > Why would Thunderbird (for example) use FP?

>   To parse CSS, where many values can be represented in decimal? Also
> Thunderbird most probably supports JavaScript, which in turn should
> support FP...

  Btw, out of curiosity, I downloaded the Thunderbird source code and
searched for usage of floating point. There are quite a lot of 'float'
and 'double' types used there, as well as many calls to the math.h library.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   To parse CSS, where many values can be represented in decimal? 

Thunderbird is email, but yes, granted, a lot of systems now have 
interpreters for arbitrary code built in. And a lot of systems rely on other 
systems (like the windowing system or HTML display modules) that might rely 
on FP, so I guess you could say those would break if FP stopped working.

> Thunderbird most probably supports JavaScript, which in turn should
> support FP...

I also meant that I wondered how many javascript programs actually use FP 
also. I've written programs for dozens of years, and I almost never use FP. 
Most "business"-type programs don't use FP for anything.

-- 
   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

Warp wrote:
>   Btw, out of curiosity, I downloaded the Thunderbird source code and
> searched for usage of floating point. There are quite a lot of 'float'
> and 'double' types used there, as well as many calls to the math.h library.

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.

Now you have me curious. I'll have to pull down sendmail and apache and 
subversion and etc to check. :-)  I suspect most of the FP has something to 
do with the UI, but I might be wrong there.

-- 
   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

Darren New <dne### [at] sanrrcom> wrote:
> > Thunderbird most probably supports JavaScript, which in turn should
> > support FP...

> I also meant that I wondered how many javascript programs actually use FP 
> also.

  Being a JavaScript interpreter, it doesn't have too much choice than to
support FP, does it?-)

  (Speaking of it, I noticed from Thunderbird's source code, that rather
enormous amounts of it are actually implemented in JavaScript. I suppose
its flexibility makes it a great tool for such an application.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Being a JavaScript interpreter, it doesn't have too much choice than to
> support FP, does it?-)

If the FP code failed silently, and most javascript didn't use FP, then most 
javascript wouldn't fail. :-)

Exactly the same as if your CPU didn't support FP, but your text editor 
didn't use FP, your text editor wouldn't fail.

But yes, you're right, you certainly want your javascript interpreter to 
support FP, because it wouldn't be correct if it didn't. It would just 
accidentally fail to encounter the bug in some cases.

>   (Speaking of it, I noticed from Thunderbird's source code, that rather
> enormous amounts of it are actually implemented in JavaScript. I suppose
> its flexibility makes it a great tool for such an application.)

My experience is that once one has an embedded interpreter in a program, one 
tends to move more and more of the program into that embedded interpreter. 
That's one of the beauties of languages like LISP and FORTH, where the 
entire environment is one big embedded interpreter.

-- 
   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

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?

Post a reply to this message

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? Why does my new mainboard not have Sub-D connectors for
RS232 and parallel ports anymore? Why does it only provide a single RS232 port?
Why does it provide only a single IDE channel? Why does the BIOS only support a
single floppy disc drive? Will my old floppy streamer still work? Why doesn't
the mainboard provide at least a pin header for the classic game port and MIDI
interface? Why can't I run my old DOS games from XP's command window?

What's the intention behind this? Breaking existing hard- and software? Bloody
likely not. Phasing out old stuff that has come of age and starts to get in the
way? Bloody likely yes.

Declaring something as "deprecated" doesn't mean someone intends to remove it
coming spring. It just means that someone sees a potential benefit of phasing
it out over time - and wants to make sure that it will *not* break 99% of the
software when it's actually done.

So for software developers it is prudent to heed such deprecation statements.
Otherwise their software may end up being among the remaining 1% to be broken
some day in the future.

What's the bottom line in practice?

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

If your software can't do without a lot of trigonometrics and at the same time
needs to be fast, decide for yourself, but be aware that your software may not
live forever.

BTW, while trying to see what the compiler makes of sin() and cos(), I got the
impression that POV-Ray doesn't really need fast trigonometrics. It does need
to compute some now and then, but plain vector & matrix stuff is by far the
bulk of the floating-point math. As a matter of fact, some more frequent calls
to sin() and cos() have already been replaced by pre-computed tables quite some
time ago.

Post a reply to this message