 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Nov 1999 22:09:22 -0600, Thorsten Froehlich wrote:
>In article <3820f651@news.povray.org> , "Chris Jeppesen"
><chr### [at] digiquill com> wrote:
>
>> And I got rid of 607 warnings with a simple #define float double
>
>I presume you are using Visual C? Just tell it to ignore the possible loss
>of "data" warning.
To do this, add one or more of the lines below to the appropriate place
in config.h.
/* disable truncation warning */
#pragma warning(disable: 4305)
/* disable precision warning */
#pragma warning(disable: 4244)
/* disable signed/unsigned warning */
#pragma warning(disable: 4018)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> On Wed, 03 Nov 1999 22:09:22 -0600, Thorsten Froehlich wrote:
> >In article <3820f651@news.povray.org> , "Chris Jeppesen"
> ><chr### [at] digiquillcom> wrote:
> >
> >> And I got rid of 607 warnings with a simple #define float double
> >
> >I presume you are using Visual C? Just tell it to ignore the possible loss
> >of "data" warning.
>
> To do this, add one or more of the lines below to the appropriate place
> in config.h.
>
> /* disable truncation warning */
> #pragma warning(disable: 4305)
>
> /* disable precision warning */
> #pragma warning(disable: 4244)
>
> /* disable signed/unsigned warning */
> #pragma warning(disable: 4018)
>
Just note that this will hide the problem, but is not a really good solution
engineering-wise. Especially 4018.
But, there's not a simple fix, since most of those come up due to the use of
macros. It might take a lot of engineering effort to correct all those in a
manner that is cross-platform and also "correct". In POV_Ray, most of the
precision and truncation warnings are due to known conversions that are
desired, thus the warnings are less important (just remember that I said "most"
and not "all possible"). Of course, any new code writen will be nice and clean
and not have any of this, right? :-)
Go ahead and put on the band-aid, but remember that it is such.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Nov 1999 06:33:49 -0800, Jon A. Cruz wrote:
>Just note that this will hide the problem, but is not a really good solution
>engineering-wise. Especially 4018.
Oh, absolutely. And I don't actually disable any of them in my own
code, either, but fixing them is fairly impractical.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3820f651@news.povray.org> , "Chris Jeppesen"
> <chr### [at] digiquillcom> wrote:
>
> > And I got rid of 607 warnings with a simple #define float double
>
> and by forcing float to be double you just make rendering slower.
That's not true. By amazing coincidence, the FPU (at least for intel arch)
is the same size as a Visual C++ double. So if your code is using floats,
they have to be converted to doubles before stuffing in the FPU (and
converted back to float on the way out of the FPU). So you lose precision
and take a performance hit by using floats.
No comment on the #define float double solution though. ;)
It's also interesting that since the '486, FPU mul/div is faster than
integer mul/div.
--
_,--"
dik `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ dic### [at] buckosoftcom / | |_\\
(_____|_|__= Guilford CT +1.203.458.0389 =__|_|_____)
_\_____=___ http://www.buckosoft.com ___=_____/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Early Net Poetry:
Wustl, Wustl, ERR RIP MIT BOOT, BIND Wustl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Nov 1999 13:34:36 -0500, Dick Balaska wrote:
>Thorsten Froehlich wrote:
>>
>> In article <3820f651@news.povray.org> , "Chris Jeppesen"
>> <chr### [at] digiquillcom> wrote:
>>
>> > And I got rid of 607 warnings with a simple #define float double
>>
>> and by forcing float to be double you just make rendering slower.
>
>That's not true. By amazing coincidence, the FPU (at least for intel arch)
>is the same size as a Visual C++ double. So if your code is using floats,
>they have to be converted to doubles before stuffing in the FPU (and
>converted back to float on the way out of the FPU).
Not really. FLD with a 32-bit real operand is 20 clocks, as opposed to the
64-bit version at 25 clocks. FST is 44 vs. 45 clocks. FMUL is 27-35 clocks
for a float, or 32-57 for a double. FDIV is 89 or 94. So floats are faster,
under ideal conditions, but not by any significant amount. (This data is for
the 386. Other processors vary, of course. Intel no longer seems to publish
this data, for the obvious reason that pipelining and other optimizations
make it useless.)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <383ADE3C.61F2BC9E@buckosoft.com> , Dick Balaska
<dic### [at] buckosoftcom> wrote:
> So if your code is using floats,
> they have to be converted to doubles before stuffing in the FPU (and
> converted back to float on the way out of the FPU). So you lose precision
> and take a performance hit by using floats.
That is wrong! There is no time for conversion required, as it is a trivial
to "cut off" the exponent (reduce it from 11 to 8 bit) and the significant
(reducing it from 52 to 23 bit) when loading/storing them.
As a matter of fact, internally all current processors store floating-point
numbers as if they were doubles (or whatever other most precise internal
format they support). When performing the calculation as single-precision,
the other bits are just not taken into account.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
Comments a little bit from back top front:
>(This data is for
> the 386. Other processors vary, of course.
And as such it is of no value. Who has a 386?
I know something like FMUL taking (if the pipelines are full) arount
1/3 clock. Double floating points are indeed a lot faster than integers.
Markus
--
Der deutsche Schlager ist aus dem Klofenster gesprungen....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <383ADE3C.61F2BC9E@buckosoft.com> , Dick Balaska
> <dic### [at] buckosoftcom> wrote:
>
> > So if your code is using floats,
> ...
>
> That is wrong! There is no time for conversion required, as it is a trivial
> to "cut off" the exponent (reduce it from 11 to 8 bit) and the significant
> (reducing it from 52 to 23 bit) when loading/storing them.
> As a matter of fact, internally all current processors store floating-point
> numbers as if they were doubles (or whatever other most precise internal
> format they support). When performing the calculation as single-precision,
> the other bits are just not taken into account.
It is a little more curious still. You can force an Intel FPU to work
in several precision modes (32, 64, 80). There are differences in the
total # of clocks from beginning to end based on how much data needs to
be pushed onto the FPU stack and the precision you run the FPU.
A secondary consideration is that with the tiny on chip cache of the
Intel chips, using larger data sizes (8 byte doubles) will cause misses
more often than using 4 byte singles. When this happens you get a huge
performance hit.
Understanding and programming around these types of things is very
important to games programmers and real time sim packages. It is also
quite platform dependent.
Xander
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 24 Nov 1999 10:20:47 +0100, Markus Becker wrote:
>Ron Parker wrote:
>
>Comments a little bit from back top front:
>>(This data is for
>> the 386. Other processors vary, of course.
>
>And as such it is of no value. Who has a 386?
>
>I know something like FMUL taking (if the pipelines are full) arount
>1/3 clock. Double floating points are indeed a lot faster than integers.
But try getting any information on instruction timings from Intel these
days. I checked both the PII and PIII reference manuals and they've dropped
that sort of information.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Markus Becker wrote:
>
.
.
.
> Markus
> --
> Der deutsche Schlager ist aus dem Klofenster gesprungen....
I just wonder when some nongerman will ask you about your sig
<bg>
Marc
--
Marc Schimmler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
