Warp <war### [at] tagpovrayorg> wrote:
> Mike Sobers wrote:
> > If a 64-bit processor could run two 32-bit programs at the same time
>
>    How the heck could it do that?

Well, I don't know.  I'm not an OS programming expert.  Maybe it's not
possible, but in any case it's probably unlikely that an OS would be
designed to operate this way, since dual 32-bit processors would be more
efficient I would think.  Mathematically, you could use the upper 32 bits
of a 64-bit memory allocation simultaneously with the lower 32-bits by
shifting the information in the registry upward.  That way one 64-bit
operation could accomplish two 32-bit operations.  Whether this is useful
in a larger programming sense, I don't know, but I suspect not otherwise
programmers would take advantage of it. While 64-bit generally means more
_precision_ in the calculations, a program could utilize the extra memory
capacity available to each 64-bit operation to accomplish two 32-bit
operations at the same time.

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

Post a reply to this message

Mike Sobers nous apporta ses lumieres en ce 31/07/2006 18:43:
> Warp <war### [at] tagpovrayorg> wrote:
>> Mike Sobers wrote:
>>    How the heck could it do that?
> 
> Well, I don't know.  I'm not an OS programming expert.  Maybe it's not
> possible, but in any case it's probably unlikely that an OS would be
> designed to operate this way, since dual 32-bit processors would be more
> efficient I would think.  Mathematically, you could use the upper 32 bits
> of a 64-bit memory allocation simultaneously with the lower 32-bits by
> shifting the information in the registry upward.  That way one 64-bit
> operation could accomplish two 32-bit operations.  Whether this is useful
> in a larger programming sense, I don't know, but I suspect not otherwise
> programmers would take advantage of it. While 64-bit generally means more
> _precision_ in the calculations, a program could utilize the extra memory
> capacity available to each 64-bit operation to accomplish two 32-bit
> operations at the same time.
> 
> 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
> 
> 
> 
You can have more precision in integer calculations. You can do 64 bits add in 
one operation while you need to emulate it on a 32 bits CPU. BUT when you do 
floating point operations, both 32 and 64 bits CPUs use 64 bits FPUs, you may 
gain a little speed while transmiting the operands and retriving the results, 
but it's prety slim. Normaly, you do hundreds, even thousands, more FP 
calculations than INT ones.

-- 
Alain
-------------------------------------------------
To the world you may be one person, but to one
person you may be the world.

Post a reply to this message

Nicolas George spake:

> Stefan Viljoen  wrote in message <44cc7a88@news.povray.org>:
>> Would have been nice if it rendered twice as fast, though... but what is
>> the real spead increase factor (if any?) on a benchmark scene?
> 
> It is not a benchmark, but it is possible to make some estimate:
> 
> - 64-bit processors break compatibility with 32-bit processors, that
> enables
>   them to forget some bad conception problems of their ancestors, and thus
>   to run somewhat faster globally.
> 
> - Povray uses mostly floating-point arithmetic, to which the 64-bit
> quality
>   of the processor does not change anything. For arbitrary precision
>   integer arithmetics, like in asymmetric cryptography, on the other hand,
>   it changes a lot.
> 
> - 64-bit processor means bigger pointers, and therefore slower operations
>   when storing and fetching pointers to/from memory. Thus, operations on
>   complex data structures will be slower than they would have been on an
>   equivalent 32-bit processor.
> 
> All this, of course, applies in the common working domain of 32- and
> 64-bit processors. 64-bit processors allow to handle much more memory at
> once, thus allowing them either to work with subjects that a 32-bit
> processor just could not handle, or to do it in a much simpler -- and
> therefore faster -- way.

Given all everybody has said - why the heck use 64bit processors with Pov
-at all- then?

What I've gathered so far:

- They're slower, using bigger pointers that take longer to manage
- They don't give much benefit to PovRay - 32 bit processors already have
enough accuracy
- They don't have the capability (yet) of doubling the amount of memory you
can actually use, due to hardware limitations in memory management, so the
ability of adressing more memory is moot?

What's the point then? Where I live 64bit systems are incredibly expensive,
and given the thread I'm sure not making the investment of upgrading. Sure,
its naieve, stupid, shortsighted or whatever to think 64 versus 32 is
"twice" anything (my apologies for apparently severely offending people for
even thinking that) so why use them? If you're not going to be cracking
cyphers, and there is virtually no benefit at all to raytracing on the
things instead of on 32 bit systems?

-- 
Stefan Viljoen
Software Support Technician / Programmer
Polar Design Solutions

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>    Where does this idea that increasing bitness can make a binary
> faster come from? I don't get it. It's a bit like saying that reading
> a book is faster if we make the pages twice as big. It doesn't make
> any sense.
>
>    Most processor which support both 32-bit and 64-bit binaries do
> not run the 64-bit ones faster. And of course: Why would they? Where
> could any speedup come from?



I think it's not so un-intuitive.  They make snowshovels wide for a reason.
 Without any prior knowledge on the subject, I think it's not that absurd to
suppose that fewer steps would be required from shoveling more bits at a
time.

Charles

PS, Speaking of scale and making things bigger, I have a hard disk
containing one very large bit.   Heads = 1  Tails = 0  (Be very careful
though not to change it's position or it might get "erased.")

Post a reply to this message

> Given all everybody has said - why the heck use 64bit processors with Pov
> -at all- then?

Two different questions going on.
(1) Why upgrade your computer?
(2) And why is a 64 bit compile of POV not that much faster than
a 32 bit compile?

(1) If you go from an Athlon to a 64 bit Opteron or Nocona,
if it supports DDR2, you might see a 2-3x speed increase. If you go
from a Xenon to that it might only be a 1.5x increase. The bottleneck
being the memory speed, 400Mbps DDR2 (64 bit) might run nearly
identical to a 400Mbps DDR (32 bit), with little real difference resulting,
but 667Mbps DDR2 will be faster.

(2) A 64 bit machine will already try to take advantage of it's improved
achitecture to run 32 bit programs faster, so optimizing only helps a bit.
It might be possible to tweak POV to use 64 bit integer math at a
processor level (fixed point), but that would probably break cross-
platform compatability, and floating point is perty fast anyways.

Post a reply to this message

Stefan Viljoen wrote:

> Given all everybody has said - why the heck use 64bit processors with Pov
> -at all- then?
> 
> What I've gathered so far:
> 
> - They're slower, 
Nope, they are faster simply because they are newer
Core development gives more efficient cores

> using bigger pointers 
Yes

> that take longer to manage  
Nope, the pointers are bigger but the memory path is wider

> - They don't give much benefit to PovRay - 32 bit processors already have
> enough accuracy
> - They don't have the capability (yet) of doubling the amount of memory
They handle magnitudes more memory then a 32bit system.
See my previous post. Try running a 22Gb render in 32bit.

> you can actually use, due to hardware limitations in memory management, 
> so the ability of adressing more memory is moot?
> 
> What's the point then? Where I live 64bit systems are incredibly
> expensive, and given the thread I'm sure not making the investment of
> upgrading.
I can't argue your point in costs because I don't know what 64bit systems
cost where you live, but here it's close to a no-brainer.

> Sure, its naieve, stupid, shortsighted or whatever to think 64 
> versus 32 is "twice" anything (my apologies for apparently severely
> offending people for even thinking that) so why use them? If you're not
> going to be cracking cyphers, and there is virtually no benefit at all to
> raytracing on the things instead of on 32 bit systems?
> 
benefits are more speed and more memory
-- 
Ger

Post a reply to this message

Stefan Viljoen <spamnot@ <removethis>polard.com> wrote:
> Given all everybody has said - why the heck use 64bit processors with Pov
> -at all- then?

  Because it removes the limitations of 32-bit systems. For instance
you can use more than 4 gigabytes of memory (which isn't unusual with
POV-Ray) and you can create files larger than 4 gigabytes (a pretty big
image indeed, but conceivable).

> - They're slower, using bigger pointers that take longer to manage

  They are slower only in certain processors where there are no enhancements
in 64-bit mode. And even there you might want the unlimited use of memory
(if you have more than 4 gigabytes of it) even at the very small cost of
slightly slower rendering (we are talking about something like 5% or
less here).
  In the AMD64 a 64-bit binary is actually faster because of the
enhancements that processor provides in 64-bit mode.

> - They don't give much benefit to PovRay - 32 bit processors already have
> enough accuracy

  It's not a question of accuracy. The 64-bit binary will not give you
any more accuracy at all. It's a question of removing the 4GB limit.

> - They don't have the capability (yet) of doubling the amount of memory you
> can actually use, due to hardware limitations in memory management, so the
> ability of adressing more memory is moot?

  I don't understand this one. What do you mean?

  Current 64-bit motherboards certainly allow you to address a huge
amount of memory. Even if they can't address the whole 2^64 bytes
theoretically possible, IIRC it's still in the hundreds of terabytes.

-- 
                                                          - Warp

Post a reply to this message

Mike Sobers <sob### [at] mindspringcom> wrote:
> Well, I don't know.  I'm not an OS programming expert.

  It's not a question of OS. It's a question of processor architecture.

>  Maybe it's not
> possible, but in any case it's probably unlikely that an OS would be
> designed to operate this way,

  In which way?

  A 64-bit processor has 64-bit registers. That's about it. All the
opcodes are still the same (well, mostly).

  I don't know what you think a 64-bit processor is, but it's basically
the exact same thing as a 32-bit processor with the only difference that
registers are 64-bit long instead of 32-bit.

  What does it mean that they are twice as long? It means that you can
make integer calculations with twice as many bits and also that you can
directly access a whole lot more of memory. How this could speed up
anything is beyond me.

> since dual 32-bit processors would be more
> efficient I would think.

  More efficient than what?

>  Mathematically, you could use the upper 32 bits
> of a 64-bit memory allocation simultaneously with the lower 32-bits by
> shifting the information in the registry upward.  That way one 64-bit
> operation could accomplish two 32-bit operations.

  Only if the operation made in the lower half of the register doesn't
overflow or underflow. And it would only work with additions and
substractions, hardly on multiplications and divisions.

  And even then, it would probably be slower to load, shift, load,
calculate, store, shift, store than doing the same thing using two
registers without the shifts. Why you think that adding additional
shifts to basic operations would make anything faster is beyond my
comprehension.

> While 64-bit generally means more
> _precision_ in the calculations,

  No, no more precision (well, except perhaps if you are using fixed-point
arithmetics), just a wider range of values (and more addressable memory).

> a program could utilize the extra memory
> capacity available to each 64-bit operation to accomplish two 32-bit
> operations at the same time.

  With the overhead of additional shift operations? Hardly.

  Besides, as I said, it would only work if there's no overflow nor
underflow and hardly with anything else than additions and substractions
(and in the latter case the result must not be negative in either half
of the register). Hardly useful for anything practical.

  Also take into account that integer math operations are just a small
part of what a program does. A typical program does a whole lot of other
things than just additions and substractions. These things include eg.
reading and writing to memory, jumping around, comparing values (eg.
for a loop) and so on.

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

  It's a mistake to think that 64 bits means "higher precision". It means
larger range of integer values. Integers are integers. They are already
exactly precise. There's no "higher precision" with integers.

  The only exception would be, as I said, if you used fixed-point
arithmetics. However, with current processors it's usually not advantageous
because the FPU is usually equally fast (if not even faster!) than using
fixed point with the CPU. In the era of 386's and 486's fixed point was
indeed faster than the FPU, but not nowadays.

  A 64-bit processor doesn't change how the FPU works. The FPU has used
64-bit (well, with Intel processors actually 80-bit) floating point since
at least the 80386 (if not even earlier).

-- 
                                                          - Warp

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> both 32 and 64 bits CPUs use 64 bits FPUs

  Actually Intel (and compatible) processors use 80-bit floating point
numbers internally. I don't know why, but they just do.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>
>   A 64-bit processor has 64-bit registers. That's about it. All the
> opcodes are still the same (well, mostly).
>
>   I don't know what you think a 64-bit processor is, but it's basically
> the exact same thing as a 32-bit processor with the only difference that
> registers are 64-bit long instead of 32-bit.
>
>   What does it mean that they are twice as long? It means that you can
> make integer calculations with twice as many bits and also that you can
> directly access a whole lot more of memory. How this could speed up
> anything is beyond me.
>

>                                                           - Warp

I wasn't arguing that the 64-bit processors should be twice as fast.  The
answer to that question is clearly no.  I was trying to explain why
reasonably intelligent people might ask the question.  It's because some
integer operations may be doubled up using the extra registry space.  As
you've pointed out, due to all the bit shifting and underflow/overflow
error detection, there is clearly no speed increase, and very few
operations could actually benefit from this approach anyway.  However, I
think it was an excellent question to ask, and the resulting discussion
here has been enlightening.  Hopefully we've all learned a lot more about
how 64-bit computing works, which was the intent to begin with.  Thanks for
your contribution to the discussion (no sarcasm here).

Mike

Post a reply to this message