What exactly are the real world benefits?

I'm supposing it doesn't render twice as fast, but you can address more RAM
(double the address size limit?), thus allowing for bigger and more complex
renders?

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? Seeing (if I'm
not wrong, as usual) that the size of the processing "bites" you can take
at one given instant is twice as large as on a 32-bit architecture? Or is
this illusionary (the bus on most of these systems not being 64 bits wide?
Or not?)
-- 
Stefan Viljoen
Software Support Technician / Programmer
Polar Design Solutions

Post a reply to this message

Stefan Viljoen wrote:

> What exactly are the real world benefits?
> 
> I'm supposing it doesn't render twice as fast, but you can address more
> RAM (double the address size limit?), thus allowing for bigger and more
> complex renders?

About 20-30% speed increase should be typical but having said that I know
I'm gonna get my head slapped because those figures depend heavily on what
you're rendering.

Under 32bit OS your max-mem is 3Gb, under 64bit it's 2^64 which is huge.
I have run renders as large as 22Gb. (With 4Gb internal memory)

> 
> 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? Seeing (if
> I'm not wrong, as usual) that the size of the processing "bites" you can
> take at one given instant is twice as large as on a 32-bit architecture?
> Or is this illusionary (the bus on most of these systems not being 64 bits
> wide? Or not?)

-- 
Ger

Post a reply to this message

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.

Post a reply to this message

Ger wrote:
> About 20-30% speed increase should be typical

   Should be typical on which processor?

   A 64-bit binary in a Sun Sparc is not faster than a 32-bit binary.
The same is probably true in a Macintosh.
   In the AMD64 there's a speedup when running 64-bit binaries, but
that speedup has basically nothing to do with the amount of bits.

> Under 32bit OS your max-mem is 3Gb

   This is based on what? Which OS?

> under 64bit it's 2^64 which is huge.

   Current hardware probably puts a limit and 2^64 bytes of RAM
is (in current hardware) not possible.

Post a reply to this message

Stefan Viljoen <spamnot@ wrote:
> Would have been nice if it rendered twice as fast, though...

   Think about it for a moment. Exactly *what* would be the thing
in a 64-bit binary which could possibly make it twice as fast compared
to a 32-bit binary?
   Would adding two numbers together be twice as fast in a 64-bit
binary than in a 32-bit one? Why would it? What would 64-bitness
have to do with the speed at which eg. additions are made? You can
naturally have twice the precision in the (integer) addition, but
what exactly could make it *faster*?

   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?
   In fact, eg. the Sun UltraSparc processors run 64-bit binaries
slightly slower than 32-bit binaries. This is because pointers are
twice as big and the data cache of the processor fills faster. This
slowdown isn't big, though; something like 5% or so.

   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). This is why it is quite
recommended to run a 64-bit OS and 64-bit binaries on an AMD64 in
order to get full performance.

Post a reply to this message

Warp wrote:

> Ger wrote:
>> About 20-30% speed increase should be typical
> 
>    Should be typical on which processor?

Like I said, "I will get my head slapped" :)
But on my setup, which is an AMD64 X2 3800+ , the measured differences were
in that range.

> 
>    A 64-bit binary in a Sun Sparc is not faster than a 32-bit binary.
> The same is probably true in a Macintosh.
>    In the AMD64 there's a speedup when running 64-bit binaries, but
> that speedup has basically nothing to do with the amount of bits.

Running 64bit Suse here and then there's a definite difference between
the "stock" 32bit binary and a self compiled 64bit version

> 
>> Under 32bit OS your max-mem is 3Gb
> 
>    This is based on what? Which OS?

The only comparisons that I can make are between the various Linux versions
I have running here.

> 
>> under 64bit it's 2^64 which is huge.
> 
>    Current hardware probably puts a limit and 2^64 bytes of RAM
> is (in current hardware) not possible.

Agreed, hardware limits how far you can go. The OS however doesn't cut you
short on how far you can take it.
-- 
Ger

Post a reply to this message

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

Except that case does; you spend less time turning pages... ;)

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Tim Cook <z99### [at] bellsouthnet> wrote:
> Warp 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.
>
> Except that case does; you spend less time turning pages... ;)
>
> --
> Tim Cook
> http://home.bellsouth.net/p/PWP-empyrean
>

And if you can speed read, m’ Lord

Stephen

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Stefan Viljoen <spamnot@ wrote:
> > Would have been nice if it rendered twice as fast, though...
>
>    Think about it for a moment. Exactly *what* would be the thing
> in a 64-bit binary which could possibly make it twice as fast compared
> to a 32-bit binary?
>
>    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.
>

If a 64-bit processor could run two 32-bit programs at the same time, or if
a 64-bit binary ran two equivalent 32-bit processes simultaneously, then it
would make sense that it could be twice as fast.  But, that's only true if
it takes the same amount of time to perform a 64-bit operation as a 32-bit
operation (which isn't the case).

Mike

Post a reply to this message

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?

Post a reply to this message

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

On a side note, there are a few applications which truely benefit from
a 64-bit architecture and would be much slower in 32-bit ones.

  One excellent example are computer chess programs. The best chess
computers in the world have always been 64-bit, and for a good reason:

  Bitmasks of the chess board are an efficient technique to speed up
calculations. For instance, one bitmask could tell to which squares
a certain piece can move. Performing a logical and of this bitmask and
another telling the location of another piece tells the program really
fast (in 1 clock cycle or less, depending on the processor) whether the
latter can be captured by the former. This technique is used a lot in
the best chess software out there.

  Now, a bitmask of the chess board requires, naturally, 64 bits (because
that's the amount of squares in the board). In a 64-bit processor it's
the size of a register, and thus performing operations on these bitmasks
is really fast. In 32-bit processors 2 registers (and thusly two operations)
would have to be used for each bitmask and each operation done to them,
making it considerably slower.

  Unfortunately these special cases are rather rare, and for example
POV-Ray is not a program which would benefit much from 64-bit integers
(except for the added address space if there's more than 4 gigabytes
of memory in the computer).

-- 
                                                          - Warp

Post a reply to this message

So what's all the hubbub over 32-bit processors?  Aren't they slower 
than 16-bit CPUs in exactly the same way as 64s are to 32s?  It just 
take longer to assign anything and nothing needs the precision other 
than some specialized applications.  Besides, nobody needs more than 640 
kB of RAM...

*wink*

-- 
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

Mike Sobers spake:


> 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

Hi Mike

Thanks, that's a rational view. It seems like sometimes in here stupid
people (like me) aren't allowed to ask stupid questions about stuff they
don't understand, because they promptly get beaten over the head with their
own question. :)

I've always liked the Pov group, cause you get so few elitist and "you're
stupid for even asking that! How can you even -think- that? Explain your
stupidity RIGHT NOW!" type answers in here. Guess that's changing.

But then, that's the POINT of asking a question - why ask a question (or
answer them) if you are omniscent and already know everything about
everything? Must be boring knowing everything about everything - nothing
new to learn or discover...

I just thought 64 is twice 32 , so it's got to be good for -something- and
do -something- better than a 32 bit processor. As you point out, it seemed
logical that -something- is twice -something- else - ok, its the register
sizes. So what? Now I know. No harm done.

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

Post a reply to this message

Stefan Viljoen <spamnot@ <removethis>polard.com> wrote:
> Thanks, that's a rational view. It seems like sometimes in here stupid
> people (like me) aren't allowed to ask stupid questions about stuff they
> don't understand, because they promptly get beaten over the head with their
> own question. :)

  I was just asking, out of curiosity, what is it that makes some people
believe that a 64-bit system should/might be twice as fast (or just faster
by some degrees) than an equivalent 32-bit system.

  It just feels that people never stop to think rationally about these
things. "What does it actually mean that it's a 64-bit system?" After
one thinks about that question and comes to a rational answer then one
should/may perhaps realize that there's no logical reason why a 64-bit
system should be twice as fast as a 32-bit system.

  Perhaps one reason might be that the popularization of 64-bit desktop
systems (64-bitness has always been something only popular in obscure
big servers until now) as well as the popularization of dual-core desktop
systems (again, multiple processors have been something only used in
obscure big servers until now) have coincided, and thus people might
get those two things mixed up and think that they are somewhat related
(even though they really aren't; their popularization in desktop systems
at the same time is just coincidence).

  Most people are also probably too young to remember the shift from
16-bit systems to 32-bit systems in Intel-based computers and have never
experienced first-hand the speed difference between a 16-bit binary
compared to a 32-bit binary (if they do the same thing there's basically
no speed difference except when big amounts of memory are needed or if
32-bit arithmetic is a very relevant part of the program's calculations).

> I just thought 64 is twice 32

  Did you stop to think *what* is it that is "twice"? What it could
possibly be?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

> Stefan Viljoen <spamnot@ <removethis>polard.com> wrote:
>> Thanks, that's a rational view. It seems like sometimes in here stupid
>> people (like me) aren't allowed to ask stupid questions about stuff they
>> don't understand, because they promptly get beaten over the head with
>> their own question. :)
> 
>   I was just asking, out of curiosity, what is it that makes some people
> believe that a 64-bit system should/might be twice as fast (or just faster
> by some degrees) than an equivalent 32-bit system.
> 
>   It just feels that people never stop to think rationally about these
> things. "What does it actually mean that it's a 64-bit system?" After
> one thinks about that question and comes to a rational answer then one
> should/may perhaps realize that there's no logical reason why a 64-bit
> system should be twice as fast as a 32-bit system.
> 
>   Perhaps one reason might be that the popularization of 64-bit desktop
> systems (64-bitness has always been something only popular in obscure
> big servers until now) as well as the popularization of dual-core desktop
> systems (again, multiple processors have been something only used in
> obscure big servers until now) have coincided, and thus people might
> get those two things mixed up and think that they are somewhat related
> (even though they really aren't; their popularization in desktop systems
> at the same time is just coincidence).
> 
>   Most people are also probably too young to remember the shift from
> 16-bit systems to 32-bit systems in Intel-based computers and have never
> experienced first-hand the speed difference between a 16-bit binary
> compared to a 32-bit binary (if they do the same thing there's basically
> no speed difference except when big amounts of memory are needed or if
> 32-bit arithmetic is a very relevant part of the program's calculations).
> 
>> I just thought 64 is twice 32
> 
>   Did you stop to think *what* is it that is "twice"? What it could
> possibly be?
> 

On the other hand, did you stop to think that not everybody is familiar with
the inner workings of a computer? That there are actually very few people,
compared to the numbers that use them, that are knowlegable about the inner
workings?
Looking back I can see the validity in Stefan's reasoning.
-- 
Ger

Post a reply to this message

Warp a écrit :
> Perhaps one reason might be that the popularization of 64-bit desktop
>  systems (64-bitness has always been something only popular in
> obscure big servers until now) as well as the popularization of
> dual-core desktop systems (again, multiple processors have been
> something only used in obscure big servers until now) have coincided,
> and thus people might get those two things mixed up and think that
> they are somewhat related (even though they really aren't; their
> popularization in desktop systems at the same time is just
> coincidence).
> 

Implying that 64-bits systems are generally better or faster than
32-bits ones might also be related to the habit of measuring the
performance, or rather generation, of game consoles in terms of bits. I
remember clearly the time when every review was speaking of 8-bits,
16-bits, 32-bits, etc. Hey, I even think the first time I heard of bits
was actually in this context :-)
Roughly each generation was doubling the "bits", so it was in the end
associated with performance. Maybe some remnants of that habit among the
people who played consoles explain the misunderstanding...

On a related note, I wonder if raster graphics are sped up when there
are more bits in the registers ? The evolution of game consoles would
suggest so, but I'm not sure of where GPUs are in terms of bitness, they
could be working in a different bitness than the processor...

In the light of this discussion, one has to wonder why would the average
desktop user need a 64-bit system anyway. Are we going to eat up 4GB of
RAM using word processors and browsing the web ? Talk about bloat :-)

-- 
Vincent

Post a reply to this message

Warp  wrote in message <44cfee79@news.povray.org>:
> (except for the added address space if there's more than 4 gigabytes
> of memory in the computer).

Actually, you do not need more than 4GB of physical memory to get the
advantages of 64bit addressing: it is enough to have more than 4GB
(actually, 3 or so, on most modern operating systems, because the kernel
keeps some address space for itself) of _virtual_ memory.

Sometimes, it is faster to let the system handle swapping on a few page
faults than put tests and indirections everywhere in the program to check
for the availability of such or such data structure.

Sometimes, it is much slower, agreed. This depends completely on the shape
of the memory access of the program, and it is something very hard to
predict. But it is always much _simpler_ to rely on the system's virtual
memory.

Post a reply to this message

Nicolas George <nicolas$george@salle-s.org> wrote:
> Sometimes, it is faster to let the system handle swapping on a few page
> faults than put tests and indirections everywhere in the program to check
> for the availability of such or such data structure.

  I didn't understand this. What "such or such data structure" are you
talking about, and what does virtual memory has to do with that?

-- 
                                                          - Warp

Post a reply to this message

Vincent Le Chevalier <gal### [at] libertyallsurfspamfr> wrote:
> In the light of this discussion, one has to wonder why would the average
> desktop user need a 64-bit system anyway. Are we going to eat up 4GB of
> RAM using word processors and browsing the web ? Talk about bloat :-)

  Remember the time when a 100MB hard disk was HUGE? Probably many thought
back then "why would the average user need such a huge hard disk?"
  This was probably the case with every major developement in computers.
And history shows us that even though we *now* can't think of anything
really necessary, there *will* be something. Resources create the needs.

-- 
                                                          - Warp

Post a reply to this message

Warp  wrote in message <44d09d1b@news.povray.org>:
>   I didn't understand this. What "such or such data structure" are you
> talking about, and what does virtual memory has to do with that?

Let us take a simple case: assume you have a simple but big list of big
objects. First, let us assume that all the objects fit in memory. Then, you
only have to use a big array of pointers to the objects, and everything is
said.

But if all the objects do not fit in memory, you will need to store some of
them on hard disk while you do not use them. For each object, either the
pointer is not null, and gives the address of the object, or it is null, and
the object is not present in memory, but saved in a file called
objXXXXXXXX.swap (where XXXXXXXX is the number of the object). Each time you
want to access an object, you have to check if the pointer is null; if it is
null, you have to pick another object and save it to disk to make room, and
load the object you want.

Saving and loading objects is a painful task. Checking for null pointers
everywhere makes your code more complex and slower. Furthermore, if your
data structure is more complex than an array of big objects, you have to
somehow store the status of each swappable part so it is always available,
which means using a pointer to pointer-or-null instead of a direct pointer.
Last of all, if your program is multithreaded, you have to lock even
read-only data structures to prevent it from being swapped out by another
thread. And you also need to make statistics usage of your object, to avoid
swapping out an object you will need a few milliseconds later.

Good news: all this is in fact built in the modern processors and operating
systems. For all memory references, processors are able to use the address
not as a direct reference to physical memory, but as a reference to a
translation table; they can suspend the course of the program and start a
specific processing if the translation table shows that the target is not
available; they can also maintain very basic statistics about access to
these references. Operating systems use these facilities, filling the
translation table and handling unavailable references, to provide to its
processes a virtual memory potentially much bigger than the physical memory
of the computer.

For example, on a host with 16 MB of memory and more than 2 GB of hard
drive, a process could run as if it had 2 GB of memory, the OS copying
chunks of memory to and from hard drive as needed. Depending on the pattern
of the memory accesses of the process, the result can be almost as fast as
if the computer actually had 2 GB of memory, or awfully slow.

In the cases where the result is bad, doing the swapping "by hand" as I
described earlier may give better results, because it is possible to use a
knowledge of the algorithm to better select parts of the data structure to
swap out or pre-fetch. But most of the time it will not do much good,
because some algorithms just can not be swapped. Thus, it is often better to
just let the OS do its work.

Anyway, such a mechanism is limited by the size of the input to the
translation mapping, compared to the size of the target objects. When it is
done explicitly, those can be chosen to match exactly the needs of the
program. On the other hand, when relying on the processor facilities,
everything is limited by the pointer size. So on a 32 bit processor, a
process can never see more than 4 GB of (virtual) memory at once. Everything
beyond must be done explicitly.

In a time when a computer with 32 GB of memory and 4 GB of hard drive was a
very powerful computer, that was quite ok. But in a time when any
supermarket computer has 1 GB of memory and 200 GB of hard drive, it is time
to step forward.

Post a reply to this message

Warp wrote:
>   I was just asking, out of curiosity, what is it that makes some people
> believe that a 64-bit system should/might be twice as fast (or just faster
> by some degrees) than an equivalent 32-bit system.

Analogies with other things that work that way, like a V-8 engine having 
twice the acceleration than a 4-banger.

>   It just feels that people never stop to think rationally about these
> things. "What does it actually mean that it's a 64-bit system?"

And some folks don't even know that much, before they ask. Some people 
learn this stuff from the top down, as it were. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     This octopus isn't tasty. Too many
     tentacles, not enough chops.

Post a reply to this message

Warp wrote:
> 
>   Most people are also probably too young to remember the shift from
> 16-bit systems to 32-bit systems in Intel-based computers and have never
> experienced first-hand the speed difference between a 16-bit binary
> compared to a 32-bit binary (if they do the same thing there's basically
> no speed difference except when big amounts of memory are needed or if
> 32-bit arithmetic is a very relevant part of the program's calculations).
> 
I even remember the shift from 8 to 16 bit systems.   :-)
I started with an Altair -- anybody remember them???
8080 processor running at 2Mhz.  It even started with a whopping 1K of 
memory!

      -=- Larry -=-

Post a reply to this message

"Ger" <No.### [at] ThankYou> schreef in bericht 
news:44d0700e@news.povray.org...
>
> On the other hand, did you stop to think that not everybody is familiar 
> with
> the inner workings of a computer? That there are actually very few people,
> compared to the numbers that use them, that are knowlegable about the 
> inner
> workings?
> Looking back I can see the validity in Stefan's reasoning.
> -- 

I totally agree!!!
Myself, I have not the slightest idea how that box to my left works. But as 
long as it does what I ask it to do, I am fine :-)
To tell the truth, beyond a basic knowledge, I don't want to know about the 
inner machinery.

Thomas

Post a reply to this message

Thomas de Groot <t.d### [at] internlnet> wrote:
> To tell the truth, beyond a basic knowledge, I don't want to know about the 
> inner machinery.

  You don't *want* to know? Why? Some weird principle?

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schreef in bericht 
news:44d30822@news.povray.org...
> Thomas de Groot <t.d### [at] internlnet> wrote:
>> To tell the truth, beyond a basic knowledge, I don't want to know about 
>> the
>> inner machinery.
>
>  You don't *want* to know? Why? Some weird principle?
>

Well, just because I feel it is a waste of time for me.

I have a PC for doing things I want it to do, I don't need nor want to know 
(most of the time) why or how it does it. I just don't have the basic 
knowledge and, frankly speaking, I have more interesting things to do.

This said however, I am always curious about what is said on the matter in 
the ng's by those who are more knowledgeable :-) just gleaning here and 
there a little bit of information that I may need some day.

I am fairly certain that there are a lot of people like me around here.

Thomas

Post a reply to this message

Thomas de Groot wrote:
> 
> Well, just because I feel it is a waste of time for me.
> 
> I have a PC for doing things I want it to do, I don't need nor want to
> know (most of the time) why or how it does it. I just don't have the basic
> knowledge and, frankly speaking, I have more interesting things to do.
> 
> This said however, I am always curious about what is said on the matter in
> the ng's by those who are more knowledgeable :-) just gleaning here and
> there a little bit of information that I may need some day.
> 
> I am fairly certain that there are a lot of people like me around here.
> 

Compare the number of people that know how a car functions to the number of
people driving a car. Same thing goes for computers. In the end they are
nothing but a tool to get something done.
-- 
Ger

Post a reply to this message

"Ger" <No.### [at] ThankYou> schreef in bericht 
news:44d34855@news.povray.org...
>
> Compare the number of people that know how a car functions to the number 
> of
> people driving a car. Same thing goes for computers. In the end they are
> nothing but a tool to get something done.
> -- 

Exactly my point.

Thomas

Post a reply to this message

Larry Hudson <org### [at] yahoocom> wrote:
> Warp wrote:
> >
> >   Most people are also probably too young to remember the shift from
> > 16-bit systems to 32-bit systems in Intel-based computers and have never
> > experienced first-hand the speed difference between a 16-bit binary
> > compared to a 32-bit binary (if they do the same thing there's basically
> > no speed difference except when big amounts of memory are needed or if
> > 32-bit arithmetic is a very relevant part of the program's calculations).
> >
> I even remember the shift from 8 to 16 bit systems.   :-)
> I started with an Altair -- anybody remember them???
> 8080 processor running at 2Mhz.  It even started with a whopping 1K of
> memory!
>
>       -=- Larry -=-

I remember the shift to 8 bit from 4 bit. In fact I’ve got a “4 bit” Casio
calculator hiding some where. Now that my job does not depend on it like
Thomas I don’t care what’s under the bonnet (hood) as long as it goes and
goes fast enough.

Stephen

Post a reply to this message

I've run benchmarks on my computer comparing 64-bit povray vs. 32-bit
povray. See for yourself:

sempron 1.6 GHz 32-bit kernel, 32-bit povray, sse2
Total Time:    0 hours 34 minutes  41.0 seconds (2081 seconds)

sempron 1.6 GHz 64-bit kernel, 32-bit povray
Total Time:    0 hours 36 minutes 41 seconds (2201 seconds)

sempron 1.6 GHz 64-bit kernel, 64-bit povray gcc 3.4
Total Time:    0 hours 29 minutes 27 seconds (1767 seconds)

duron 1.6 GHz
Total Time:    0 hours 40 minutes  46.0 seconds (2446 seconds)

So there you go: a 17.7% increase in rendering time on the benchmark scene.
Of course, as others have pointed out, there probably won't be a speedup on
architectures that were 64-bit to begin with.

Post a reply to this message

Warp wrote:
> 
>   I was just asking, out of curiosity, what is it that makes some people
> believe that a 64-bit system should/might be twice as fast (or just faster
> by some degrees) than an equivalent 32-bit system.
> 

It has lately been common to explain that the CPU MHz doesn't actually
tell the speed of the computer, but just part of it. While most PC-users
has never heard of eg. Sun Ultrasparcs, the AMD64 is the first 64-bit
system to them. And like you said, it has a bunch of features to run
faster. Optimizing in 64-bit mode, yes, but also eg. the integrated
memory controller. Opteron handles memory a _lot_ faster than same aged
Xeon.

That's one thing to make 64bit faster than 32bit - in people's mind.
Just my 2 cents.


-- 
Eero "Aero" Ahonen
   http://www.zbxt.net
      aer### [at] removethiszbxtnetinvalid

Post a reply to this message

Darren New wrote:
> 
> Analogies with other things that work that way, like a V-8 engine having
> twice the acceleration than a 4-banger.

Which is also poop ;).

-- 
Eero "Aero" Ahonen
   http://www.zbxt.net
      aer### [at] removethiszbxtnetinvalid

Post a reply to this message

Thomas de Groot <t.d### [at] internlnet> wrote:
> Well, just because I feel it is a waste of time for me.

  Information is never a waste of time.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Thomas de Groot <t.d### [at] internlnet> wrote:
> 
>>Well, just because I feel it is a waste of time for me.
> 
> 
>   Information is never a waste of time.
> 

It also may be a waste of other resources, too.

-- 
Eero "Aero" Ahonen
   http://www.zbxt.net
      aer### [at] removethiszbxtnetinvalid

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schreef in bericht 
news:44d60ead@news.povray.org...
> Thomas de Groot <t.d### [at] internlnet> wrote:
>> Well, just because I feel it is a waste of time for me.
>
>  Information is never a waste of time.
>

True. I agree. But if you lack the knowledge to appreciate particular 
information, then it becomes random noise so to speak :-)

What I mean is that instead of spending (precious) time struggling through 
information I do not really understand, I prefer to concentrate upon what I 
need to do. Time is short...

Thomas

Post a reply to this message

Thomas de Groot <t.d### [at] internlnet> wrote:
> What I mean is that instead of spending (precious) time struggling through 
> information I do not really understand, I prefer to concentrate upon what I 
> need to do. Time is short...

  And then, when you don't have even the most basic information, you make
all kinds of wrong assumptions, mistakes and, in the worst case, a fool
of yourself.

  Basic information is never useless.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> schreef in bericht 
news:44d725db@news.povray.org...
>
>  And then, when you don't have even the most basic information, you make
> all kinds of wrong assumptions, mistakes and, in the worst case, a fool
> of yourself.
>
>  Basic information is never useless.
>

That also is true. Except for the fool, as I believe that one should not 
peremptorily offer advice about things one does not know anything about. But 
asking questions or even making wrong assumptions is never foolish.

Still, I do not want to know how my car does what it does (I mean: 
transporting me from A to B and back again)... :-)

Thomas

Post a reply to this message

Warp nous apporta ses lumieres en ce 01/08/2006 17:31:
> 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.
> 
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. Would be good if you 
could preserve those extra 16 bits. This would open up double and half precision 
FP numbers.

-- 
Alain
-------------------------------------------------
SHOPPING MATH
A man will pay $20 for a $10 item he needs.
A woman will pay $10 for a $20 item that she doesn't need.

Post a reply to this message

Tim Cook nous apporta ses lumieres en ce 02/08/2006 00:49:
> So what's all the hubbub over 32-bit processors?  Aren't they slower 
> than 16-bit CPUs in exactly the same way as 64s are to 32s?  It just 
> take longer to assign anything and nothing needs the precision other 
> than some specialized applications.  Besides, nobody needs more than 640 
> kB of RAM...
> 
> *wink*
> 
The early 32 bit processors where indead a bit slower than contemporary 16 bit 
ones. Also, early 32 bit programms where almost always slower than 16 bit 
versions when running on the same 32 bit processor. It's worth noting that 
almost all 16 bit processors had at least 20 bit address bus, up to maybe 32 for 
the latest. Also, ALL 8 bit CPU had 16 bit address path before the 8086 (20 bit 
address space).

-- 
Alain
-------------------------------------------------
You can go anywhere you want if you look serious and carry a clipboard.

Post a reply to this message

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