Re: WWDC -- MacBook Pro?

In article <nospam.News.Bob-AA9DD8.23461809082006@xxxxxxxxxxxxxxxx>, Bob
Harris <nospam.News.Bob@xxxxxxxxxxxxxxxxxxxxxx> wrote:

And my experience with 64 bit applications is that they are not
twice as big (bigger yes, but not any where near twice as big).

What factor increase do you get?

And that the application's data generally does not change.  A jpeg
images is still a jpeg image.  A database record is still a
database record.

If the data sizes and padding are the same, it does not increase of
course. But then alignment problems could cause a slowdown. Padding is up
to the C compiler to decide.

And one surprise is that some applications compiled for 32 bits
run FASTER than the same applications compiled for 64 bits.  This
is where the application doesn't need 64 bit integers nor 64 bit
pointers for huge memory access.  In this case the 64 bit pointers
used by the 64 bit version of the application and the 64 bit
libraries it links against, consume extra memory and cache
bandwidth (the addresses being twice as wide as the 32 bit
equivalents).  And since the app didn't need 64 bit addresses,
over half of the address is zeros.  So this wasted space is taking
up space in the application memory, taking up space in the CPU
cache causing more cache invalidates, and a when a cache line is
loaded, less of the bits transferred are useful if it contains
addresses, etc...  The end result is that it actually takes longer
for the CPU to do the same unit of work as a more compact 32
version of the program.

Now this is only small (tiny) performance differences, but it is
something that can be measured.

One possible explanations that comes to my mind is that the 64-bit
computer isn't optimized around 32-bit. Data that is packed in to a single
word, so that the CPU has to split it, is slower than unpacked data. So if
the memory is 64-bit and one fits two 32-bit data types into it, it will
be slower than if these two 32-bit data are put into two 64-bit words. And
so if the 'int', which is 32-bits on a 32-bit computer remains 32-bit on
the 64-bit computer, and the C compiler decides that two following int's
should be packed into a 64-bit word, that might cause a slowdown relative
if the compiler decides that the int's should be put into two 64-bit
words.

It is possible to speed up a program by treating such packed data as
unpacked. For example, the C library function 'strcpy' becomes faster if
the character string is copied as int's (on a 32-bit computer) instead of
as char's, because it will be copied word by word, instead of having to
split each word to find each character, and then copying it. Similar
rewrites may speed up the code written for a 32-bit computer on a 64-bit
computer.

On the other hand, an application that uses lots of 64 bit integer
math, or needs huge virtual memory address space (and happens to
have enough real memory to keep page faulting to a minimum) will
out perform a 32 bit app that tries to work around its address
limitations, or perform 64 bit math using 32 bit registers (think
multiple and divide).

The guys in need of such high end number crunching applications are the
ones really benefitting from 64-bit. For others, it has been rumored,
performance benefits may be more modest, at least before the code has been
rewritten to make use of the 64-bit features.

So I'm not trashing 64 bit CPUs.  I'm just saying they they do not
automatically double the memory needs, and that not all 64 bit
applications will be faster.

Let's return to the padding/packing question above. If you compile your
32-bit program for 64-bit, then the int's remain the same size, and
the compiler will probably pack adjacent int's into single 64-bit words.
This gives a small performance loss.

The next step is to profile the code written for the 32-bit computer on
the 64-bit computer. So one discovers, aha, these 32-bit int's slow the
program down. So the next step is to change them to 64-bit long int's.
Now, on a 32-bit computer, a 'long' might be 32-bits just as the 'int'. So
you have introduced a 64/32-bit incompatibility. Now, when programming
continues for awhile on the 64-bit computer, it seems prudent to make use
of the longer integral types. This could be other types, such as 'double',
which are coerced into this 64-bit types. So after awhile, you have code
that can't be easily converted to work on a 32-bit computer.

So the code could, when programming continues for awhile and one is
making special use of the 64-bit features, expand considerably, and would
probably become wholly incompatible with the 32-bit computers.

As this program rewriting happens, the 32-bit computers will die away from
use, as new programs will not run on them anymore.

As for the original real life example that caused so much debate over
whether the code actually doubles: a graphics layouter has a computer, a
PowerBook, in which 1 GB isn't enough, perhaps 2 GB is it, but that is not
for sure. The problem with only 1 GB is that it takes 20 seconds or more
to just switch between applications, which is a typical sign of that the
active program parts are not kept in RAM but constantly paged onto the
hard disk. Suppose something just below 2 GB is enough, and that something
just above 2 GB will be enough when switching to a 64-bit MacBook. The buy
will be 4 GB, not 3 GB, in part because matching memory produces a small
speed increase. Now, if 4 GB is the upper limit for all times on this
computer, the problem is that later versions of these programs may require
more memory for all kinds of reasons, not only rewriting code, but by
adding new features. And in addition, new programs may be required.

Experience has it that the need of RAM will expand rapidly over time. Say
it follows Moore's law, and doubles in 1-2 years. Then the computer will
only last 1-2 years! That is too little time for an investment in such an
expensive computer.

So 4 GB seems to be too little as a limit on those Mac laptops.

--
Hans Aberg
.

Relevant Pages

  • Re: moving data from one place to another in a text file
    ... practical solution - as any solution requiring "memory allocation" canNOT handle ... And, of course, the "read twice method" would be portable to EVERY ANSI/ISO ... >>output the same input file with another name. ...
    (comp.lang.cobol)
  • Re: SLOW typing response time using Mac Office 2008
    ... Anything running on a PPC needs twice the memory of something running on ... Which occupies twice the memory. ... and noticed a marked improvement in the response time, ... But I usually have Safari 3.0.4 running in the background, ...
    (microsoft.public.mac.office.word)
  • Reasons For 64-bit: A Digest
    ... First of all, you are of course, absolutely right about your observation that a 64-bit Pointer is twice the size of a 32-bit pointer. ... I really wish the "64-bit Lobby" had made a digest of our arguments while we were fighting to get a native 64-bit compiler on the Road Map.. ... twice as many registers: double the number of general purpose registers and double the number of XMM registers. ... Expanded address space so instead of being limited to 4 GB of memory you're limited to terabytes of memory. ...
    (borland.public.delphi.non-technical)
  • Re: Real cost of the mini
    ... >> cost of a PC that has double the HD space, twice the CPU power, 4x the video ... >> memory and twice as much ram you will ever need. ... > is a serious memory hog that realistically needs 1GB, ... system B's preconfigured model. ...
    (comp.sys.mac.advocacy)
  • Re: Cached memory never gets released
    ... Stock linux 2.4.26 kernel. ... Due to flash bug 3M of memory gets lost due to font memory getting lost ... The output of "free" cache number steadily grows. ... longer to exhaust all of system memory with the cache. ...
    (Linux-Kernel)