 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
