Alain <ele### [at] netscapenet> wrote:
> OK then. So, as long as your results STAY in the FPU and you keep on reusing 
> them, you can keep an improved acuracy. But, as soon as you need to put your 
> results anywhere else, you fall back to 64 bits acuracy.

  Not really. You can store the numbers in memory using the 80-bit
accuracy. In C/C++ you can usually do that with the 'long double' type.

  I don't know, however, if there's a speed penalty in storing/reading
memory in units larger than 64 bits...

-- 
                                                          - Warp

Post a reply to this message

Warp nous apporta ses lumieres en ce 08/08/2006 05:46:
> Alain <ele### [at] netscapenet> wrote:
>> OK then. So, as long as your results STAY in the FPU and you keep on reusing 
>> them, you can keep an improved acuracy. But, as soon as you need to put your 
>> results anywhere else, you fall back to 64 bits acuracy.
> 
>   Not really. You can store the numbers in memory using the 80-bit
> accuracy. In C/C++ you can usually do that with the 'long double' type.
> 
>   I don't know, however, if there's a speed penalty in storing/reading
> memory in units larger than 64 bits...
> 
Probably, one more write/read operation. You also have word alignment concerns, 
the extra 16 bits = 1/2 word, 1/4 word on 64 bit platform.
How long before we get quad, 128 bit, precision FPU?

-- 
Alain
-------------------------------------------------
Fighting for peace is like screwing for virginity.
  - The Bayou, Baton Rouge , LO

Post a reply to this message

On Tue, 08 Aug 2006 11:46:01 +0200, Warp <war### [at] tagpovrayorg> wrote:
> Alain <ele### [at] netscapenet> wrote:
>> OK then. So, as long as your results STAY in the FPU and you keep on  
>> reusing
>> them, you can keep an improved acuracy. But, as soon as you need to put  
>> your
>> results anywhere else, you fall back to 64 bits acuracy.
>
>   Not really. You can store the numbers in memory using the 80-bit
> accuracy. In C/C++ you can usually do that with the 'long double' type.

Not with a Microsoft C++ compiler though. In their infinite wisdom they  
chose the 64-bit type for both 'double' and 'long double'.


>   I don't know, however, if there's a speed penalty in storing/reading
> memory in units larger than 64 bits...

There was on the original Pentium. Newer processors may have wider data  
paths though.


-- 
FE

Post a reply to this message

Fredrik Eriksson <noo### [at] nowherecom> wrote:
> Not with a Microsoft C++ compiler though. In their infinite wisdom they  
> chose the 64-bit type for both 'double' and 'long double'.

  It's the same wisdom that makes 'long' 32-bit even when compiling to
a 64-bit binary... (This is the only compiler in the world that I know
of which does that.)

-- 
                                                          - Warp

Post a reply to this message

"Mike Sobers" <sob### [at] mindspringcom> wrote:

> Your question was "why do some people think it could be twice as fast?".
> It's because some people understand math and binary operations, but not
> neccessarily how computer architecture is designed around them.  That's why
> the question was asked in the first place, because a lot of us have a lot to
> learn about what advantages the new higher-precision hardware/software will
> provide.
>
> Mike

Well said! And, I might add, it shouldn't be necessary for us POV users to
have to become computer scientists or programming/architecture experts just
in order to understand why 64-bit POV on a 64-bit machine is faster (or
slower) than the 32-bit one. Simple, real-world benchmarks would
suffice...not a lot of holier-than-though technical browbeating.

Ken W.

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> And, I might add, it shouldn't be necessary for us POV users to
> have to become computer scientists or programming/architecture experts just
> in order to understand why 64-bit POV on a 64-bit machine is faster (or
> slower) than the 32-bit one.

  If someone doesn't understand the difference between a 32-bit and a
64-bit processor and has the misconception that the latter will be
twice (or at least considerably) faster than the former and makes a
buying decision based on that misconception, he is up to a disappointment.
  I don't think it's a bad thing to know the real difference.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > And, I might add, it shouldn't be necessary for us POV users to
> > have to become computer scientists or programming/architecture experts just
> > in order to understand why 64-bit POV on a 64-bit machine is faster (or
> > slower) than the 32-bit one.
>
>   If someone doesn't understand the difference between a 32-bit and a
> 64-bit processor and has the misconception that the latter will be
> twice (or at least considerably) faster than the former and makes a
> buying decision based on that misconception, he is up to a disappointment.
>   I don't think it's a bad thing to know the real difference.
>
> --
>                                                           - Warp

Yes, but how much arcane knowledge are any of us, as individuals, expected
to know? Echoing the sentiments expressed earlier, we all have to pick and
choose what we devote our time to learning.  My refrigerator keeps my food
cold, but do I really need to know how the refrigeration cycle works in
order to use it (or buy one?) It's a bit unfair to assume that all of us
out here *should* know all about the inner workings of 64-bit processors,
and to bludgeon us if we don't. Processor architecture may be one of your
own prime interests, I don't know; but there are many of us (judging from
these posts) that *just don't need to know* such stuff. (Hey, I'm still
trying to learn POV-Ray!)

HOWEVER, that said, I do fall into the situation you've described, having
bought a 64-bit machine--an emachines T6412-- in the (seemingly mistaken!)
belief that it WOULD run POV-Ray "twice as fast" as as equivalent 32-bit
machine.  A belief based on all of the non-technical ideas expressed here
so far-- basically that 64-bit sounds like it is "twice" 32-bit. A dumb
belief? No. I think it comes from a lot of different ingredients (not the
least of which is computer manufacturer's hype.) It is indeed unfortunate
that computers, more so than just about any other technical gadget, seem to
require so VAST a store of knowledge in order to to understand (and to
purchase wisely.) Impossibly vast, IMHO. But am I disppointed with my
purchase?  Not at all! The only machine I can compare it to is my old
32-bit Pentium II 400MHZ. And it runs (32-bit) POV-Ray 6X faster. That's
all I really need to know!

SO...will it run 64-bit POV-Ray faster still? I haven't yet installed that
version, but I'm inclined to think not, judging from all that has been
discussed so far. That's disappointing.

Ken W.

Post a reply to this message

My favorite is "Long Boolean" where true="0000000000000001" and
false="0000000000000000"



"Warp" <war### [at] tagpovrayorg> wrote in message
news:44d92e04@news.povray.org...
> Fredrik Eriksson <noo### [at] nowherecom> wrote:
> > Not with a Microsoft C++ compiler though. In their infinite wisdom they
> > chose the 64-bit type for both 'double' and 'long double'.
>
>   It's the same wisdom that makes 'long' 32-bit even when compiling to
> a 64-bit binary... (This is the only compiler in the world that I know
> of which does that.)
>
> -- 
>                                                           - Warp

Post a reply to this message

Warp  wrote in message <44cdf9bd$1@news.povray.org>:
>    Now, the AMD64 is a special case: 64-bit binaries optimized for the
> AMD64 run slightly faster than 32-bit binaries optimized for the same
> processor. However, this speedup has nothing to do with the amount of
> bits used. It is because in 64-bit mode the CPU has enhancements which
> the binary can use for faster performance (the biggest enhancement is
> a bunch of additional CPU registers).

There is another point. I just remarked that the following code:

    for(i = 0; i <= N; i++)
	r += (double)i * (i / 100000000);

runs four to six times faster in 64 bits mode than in 32 bits mode on AMD64
or its intel clone, with gcc. This probably has to do with gcc using
different FPU mechanisms (SSE2 vs. x87). I am currently waiting for some of
my friends to test with different compilers and/or explain what they
understand of SSE2.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
>     for(i = 0; i <= N; i++)
>         r += (double)i * (i / 100000000);

  What is the type of 'i' there?

-- 
                                                          - Warp

Post a reply to this message