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

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