Re: 32-bit vs. 64-bit x86 Speed

Jon Forrest wrote:

Here's what I said:

"One thing I've noticed about 64-bit computing in general is that it's
being oversold. The **only** reason for running in 64-bit mode is if
you need the additional address space.

IMO the address space is not serious restriction on 32 bit processors.
It may seem convenient to have more than 4 GB of address space
available, but the limiting factor is the amount of physical RAM,
available at runtime. As soon as a program uses more RAM than
physically present, the system must start swapping from and to disk.

Indeed, for some apps this is
critical and 64-bit computing solves a real problem.

As long as there exists a chance, that large amounts of data cannot be
hold in RAM, a clever data management inside the application will
result in better performance of the program, compared to an
unoptimized ("brute force" ;-) program, that simply makes use of the
full virtual 64 bit address space.

The only important difference between 32 and 64 bit machines is the
crossing of the 4 GB barrier, so that more than 4 GB of RAM *can* be
used. But future must show how the typically *available* amount of RAM
on actual machines really will increase, most actual machines still
are equipped with less than 4GB of RAM. This is more a matter of
memory technology, than of CPU technology. It's no problem to produce
a 128 or 1024 bit CPU with nowadays technology, but the memory
designers are bound to the actually available technology. In so far a
change from 2-D "chip" to 3-D "cube" technology would have an much
bigger impact on computing, than a trivial change from 32 bit to 64
bit registers.


For apps that don't need the extra address space, the benefits of
the additional registers in x86-64 are nearly undone by the need to
move more bits around, so 32-bit and 64-bit modes are pretty much a
push. When you add the additional difficulty of getting 64-bit
drivers and what-not, I don't think it's worth messing with 64-bit
computing for apps that don't need the address space."

It's more a problem of the OS than of the applications. Support for 32
bit programs will decrease in future versions of 64 bit systems, new
features will be built only into the 64 bit OS versions. For some time
we'll have a need for *both* 32 and 64 bit applications, but the need
for the 32 bit programs will decrease with the number of 32 bit systems
still in use.

As outlined above, code should not stupidly rely on the availability of
an huge amount of RAM. Instead the assumed or actually available size of
physical memory should be considered in code, regardless of the
available address space.

Let's say you're a Linux user who never needs to run programs that
don't fit in 32-bits.

Never say never ;-)

Would you run a 32-bit or a 64-bit version of Linux?

Every user will have to move to a 64 bit OS on a future machine, when
support for older systems (drivers!) will vanish.

You compiler people probably have intimate knowledge of the ISA
issues here so I'm interested in what you have to say.

IMO compilers are not affected by the mere move from 32 bit to 64 bit
address space. A compiler can support the creation of 8, 16, 32 and 64
bit code at the same time, from the same source code, and for the same
machine - as far as supported or required by the given target machine.

Compilers instead have to keep abreast of the features of new machines,
which are not bound to the register size. I don't know how much
compilers are affected by the new technology, because some of the new
features may change or disappear as fast as they have appeared. IMO the
impact is almost a matter of optimization and scheduling, for multi-core
and other parallel processing capabilities, which already existed in the
32 bit world. I feel a need for new or extended programming languages,
with explicit support for parallel processing. But I doubt that such
languages will be accepted by the big market :-(

Actually there *exists* a need for 64 bit systems, because machines with
more than 4 GB of memory are feasable and affordable. The placement of
64 bit machines in the consumer market will do the rest, because most
users do not buy what they need, but instead must have whatever is
advertised as the "state of the art" ;-)

DoDi
.

Relevant Pages

  • Re: Stating the obvious...... or a stretch
    ... Non technological factors that can make or break a technology but I am ... If the consequence of us using more intelligent machines is that we ... will support super intelligent computing is a relevant consideration ... convincingly suggest that the likelihood of solving it is low. ...
    (comp.lang.scheme)
  • SNAPSHOT - WORLD WAR TOOLS
    ... WORLD WAR TOOLS ... machines to the recent addition of computer aided manufacturing ... At the end of the tour the engineer whom lead the tour gave ... form of technology based competition compared to the weapon based ...
    (soc.culture.burma)
  • Re: oo2c port for nmos6502
    ... I believe that 1mhz 6502 is fast processor, and 48-64k of ram is a big ... On slow/small machines we need to employ skill ... Needless to say, it runs Native Oberon impressively fast, and a custom ... although that might change if I have to do some more embedded systems work. ...
    (comp.lang.oberon)
  • Re: Choosing a DTP
    ... Computing is just consuming anymore. ... runs on slower machines or emulation and forget that it was originally ... programs with equally new and fresh ideas. ... the need for the permanent and vulnerable registry of Windows. ...
    (comp.sys.acorn.apps)
  • Re: Merging with machines inevitable, scientists say
    ... All the machines we use on a daily basis are just extensions of our body ... a debate about technology, but instead, a debate about human nature - which ... To complex question is what will society think of the machines once we ...
    (comp.ai.philosophy)