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

Warp  wrote in message <44f1fe00@news.povray.org>:
> 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?

An unsigned; but it should not change anything, since it is the very same
code in both modes. Well, it could have been a long long, but I am not that
careless; and in fact, the difference between 64-bit integer arithmetic in
both modes is much smaller. Some of the missing parts are:

#define N 1000000000

static double
calc_double(void)
{
    unsigned i;
    register double r = 0; /* or not register */

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

    getrusage(RUSAGE_SELF, &t0);
    r1 = calc_double();
    getrusage(RUSAGE_SELF, &t1);

(the rest is just necessary noise)

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> Warp  wrote in message <44f1fe00@news.povray.org>:
> > 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?

> An unsigned; but it should not change anything

  Well, I asked because I suspected it was an integer, in which case
the above code doesn't make too much sense.

  In C (and C++) the sentence "(i / 100000000)" is 0 for any (unsigned)
value of i less than 100000000. That because both arguments being integer,
that's an integer division, not a floating point one.
  Then, of course, the first 'i' is multiplied by 0, so 'r' is repeatedly
added '0' to it, which makes no difference.

  I don't know if this makes a difference in speed in different processors,
but it *might* be that the AMD64 can smartly perform those operations
(which always yield '0' as the answer) faster with its 64-bit-mode
enhancements. But not necessarily. It's just a guess.

  Anyways, what you probably wanted to do is this:

        r += (double)i * (i / 100000000.0);

which makes much more sense. Could you test if it that also is considerably
faster in 64-bit mode?

>     register double r = 0; /* or not register */

  The 'register' keyword is a no-op. It doesn't do anything and is just
a useless backwards-compatible drag of history.
  (Besides, even when it meant something (like 20 years ago or so), you
couldn't possibly use it with a 'double' because registers are used for
integers only.)

-- 
                                                          - Warp

Post a reply to this message