Stephen <mcavoysAT@aolDOTcom> wrote:
> 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?

Why is there not a povray.flamewars newsgroup? :)

Post a reply to this message

nemesis wrote:
> Why is there not a povray.flamewars newsgroup? :)

I vote for povray.flamewar.redirect.redirect.redirect


-- 
   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 <war### [at] tagpovrayorg> wrote:
>   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.

Quotes from some AMD article I just (re-)discovered:



instructions in 64-bit threads."
(http://developer.amd.com/Pages/62720069_4.aspx)

So contrary to how I understood it so far, we're actually only talking about
that brand new 64-bit software, not the 99% of old 32-bit stuff.

(2) "AMD64 64-bit mode doubles the number of XMM registers from eight to
sixteen. [...] This option makes it much easier to create efficient sequences
of arithmetical operations and for compilers to produce highly optimized code.
As an example, math library implementation of trigonometric functions such as
sin , cos , and tan can somewhat surprisingly, significantly outperform the x87
built-in instructions for these functions."

So according to AMD, 64-bit mode comes with extensions that make the x87 FPU
obsolete. (Which explains why your P4 tests indicated otherwise.)

Hard to believe, but not impossible. For example, the AMD Phenom processor docs
specify a latency of 93 clock cycles for the x87 FCOS command. Some paper I
found on the net about some highly sophisticated algorithm for various
transcendental functions including cos gives 124 clock cycles for a
hypothetical processor, and 276 clock cycles for a real-world RISC processor
(http://perso.ens-lyon.fr/nathalie.revol/publis/RY00.pdf). Obviously even this
highly sophisticated algorithm takes more steps than the x87 FPU needs clock
cycles - but then again it may be possible to parallelize enough of these steps
to get from 124 to below 93.


So for 64-bit apps, it may indeed be of advantage to use SSE2 instead of the x87
FPU ("somewhat surprisingly", as AMD states). And 32-bit apps do not seem to be
in any danger of losing x87 FPU support any time soon.

Post a reply to this message

clipka <nomail@nomail> wrote:
> So for 64-bit apps, it may indeed be of advantage to use SSE2 instead of the x87
> FPU ("somewhat surprisingly", as AMD states). And 32-bit apps do not seem to be
> in any danger of losing x87 FPU support any time soon.

  As I said, it's completely understandable and makes sense that future
compilers (and therefore future programs) will stop using the FPU commands
if SSE is more efficient, and that using the FPU will gradually fall out
of practice. It may even be very conceivable that some future 64-bit
intel-compatible processor will have no FPU support at all.

  And that's not what I objected against. I objected against the claim that
operating systems will drop support for FPU on hardware which has a FPU.
Even for future processors, as long as they support FPU opcodes, I find it
extremely likely that all OS'es will also do so, because it's not really a
big deal.

  It's perfectly possible that some future processor will have no FPU
opcodes, and an OS compiled for *that* specific processor will, rather
obviously, have no support for them either (for the simple reason that
it can *not* have the support because the hardware is not there).

  However, backwards compatibility is such a big deal that I don't see
this coming anytime soon. It doesn't matter how much it would make sense
in a technical sense to scratch past mistakes and design a processor from
scratch, what matter is the market: People simply won't buy a computer
which cannot run their software. It's that simple.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   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?

And because they're that old, you'll have trouble running XP on them, and Vista
64 won't run on them at all. And you can compile a Linux kernel that doesn't
include support for them either.


>   The way you "deprecate" it is by making newer compilers not use it.

That's already being done, as it seems.

> The OS plays no role in this process.

It does. As long as it invokes x87 FPU commands in an attempt to store their
contents for a task switch, you can't strip those commands from your CPU,
because it would break the OS.


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

Don't ask me. Ask Microsoft, Apple, the Linux community, and Intel and AMD. I'm
not a representative of said companies / communities.

I'd say: Deprecate x87 FPU use; encourage compiler vendors to default to not
using it; introduce new OS API calls that do no longer use x87 FPU registers
for parameter passing (if applicable); deprecate the old API calls; deprecate
x87 FPU use, deprecate it again and again - and then ultimately release a new
version that just doesn't support it anymore.

By that time - to mention it again - the percentage of software actually using
the x87 FPU will have diminished. That is the "gradual" part of this phasing
out.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   However, backwards compatibility is such a big deal that I don't see
> this coming anytime soon.

Nobody is saying anything else :)

All they say is basically: "Take care - if you want your software to have a long
live expectancy, you may want to stop using x87 FPU in 64-bit mode"

> People simply won't buy a computer
> which cannot run their software. It's that simple.

:)

They keep buying new OS versions which cannot run their software (they even run
for leaked pre-beta versions), so why should they be any more picky with their
hardware :)

Post a reply to this message

clipka <nomail@nomail> wrote:
> > People simply won't buy a computer
> > which cannot run their software. It's that simple.

> :)

> They keep buying new OS versions which cannot run their software (they even run
> for leaked pre-beta versions), so why should they be any more picky with their
> hardware :)

  Even Windows Vista can run Windows 1.0 software (with some tweaking).
Just google for it.

  Sure, *some* software has stopped working with new versions of Windows,
but a rather small amount of them.

  What you are talking is completely different. It's a total cut from
software older than a certain age.

-- 
                                                          - Warp

Post a reply to this message

clipka <nomail@nomail> wrote:
> And you can compile a Linux kernel that doesn't
> include support for them either.

  I can compile a Linux kernel that doesn't run at all. What does that prove?

> > The OS plays no role in this process.

> It does. As long as it invokes x87 FPU commands in an attempt to store their
> contents for a task switch, you can't strip those commands from your CPU,
> because it would break the OS.

  And as long as the OS is run on a system with FPU and with programs using
the FPU, the OS cannot drop support. It's that simple.

  As I have said like a dozen times, it makes absolutely no sense for an OS
to drop support for the FPU if the computer has one.

  The OS does *not* play any role in the migration from FPU to SSE.

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

> Don't ask me.

  I'm asking you because you said it.

> Ask Microsoft, Apple, the Linux community, and Intel and AMD.

  They are not dropping support for the FPU in their OS, so why should
I ask them? Why are they not dropping it? I have repeated it a dozen of
times already: It doesn't make any freaking sense. If the hardware has
an FPU, the OS supports the FPU, period.

  You can't "migrate" the OS to "not support the FPU" over several years.
It either supports it or doesn't. There's no middle ground.

> I'd say: Deprecate x87 FPU use; encourage compiler vendors to default to not
> using it; introduce new OS API calls that do no longer use x87 FPU registers
> for parameter passing (if applicable); deprecate the old API calls; deprecate
> x87 FPU use, deprecate it again and again

  Which is completely different from the OS refusing to run software which
uses the FPU.

> - and then ultimately release a new
> version that just doesn't support it anymore.

  Which would be absolutely nonsensical in a computer with a FPU.

  What are they going to do? Pop up an error dialog saying "sorry, although
this computer does have a FPU, I'm not going to allow you to use it, tough
luck"? Haha.

  How many times do I have to repeat myself? It doesn't make any sense.

> By that time - to mention it again - the percentage of software actually using
> the x87 FPU will have diminished. That is the "gradual" part of this phasing
> out.

  Even if there's 0 new software which uses the FPU, if the OS is run on
a computer with an FPU, it makes absolutely no sense not supporting it and
actively boycotting any software which tries to use it.

-- 
                                                          - Warp

Post a reply to this message

On Fri, 02 Jan 2009 10:46:51 -0800, Darren New <dne### [at] sanrrcom> wrote:

>nemesis wrote:
>> Why is there not a povray.flamewars newsgroup? :)
>
>I vote for povray.flamewar.redirect.redirect.redirect

RTFM My son :-)

BTW Not aimed at you ;)
-- 

Regards
     Stephen

Post a reply to this message

Warp wrote:
> 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...

Wow, any idea what for?

Post a reply to this message