As 64-bit PowerPC processors become more widely available, it becomes desirable to make applications run in the 64-bit computation mode, providing access to larger address space and faster 64-bit arithmetic. This excerpt from a longer Technical Library article covers some of the issues faced when porting existing 32-bit code to the new computing model — or when embarking on new 64-bit development.
Making the transition to 64 bits
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
While the article mention the PowerPC, the summary let understand the documentation is processor generic. However it is really PowerPC oriented except for the first part, which deal with storage size of data issues.
This first part is really fast covered, and it is interesting to note they encourage the storage of pointer into long. Wouldn’t it be the occasion to suggest to code on an arch independent way instead of using assumptions about storage size?
There’ve been some articles about 64bit processors on osnews. I’d like to make some things clear:
1. The larger address space isn’t of use for current applications. 4GB aren’t enough on clusters, maybe, but I’ve never seen a single program using more than maybe 2G of RAM. The larger _virtual_ address space doesn’t matter for current applications – 3GB (under Linux, 1G for kernel). The larger physical address space comes in handy for clusters and servers or graphic workstations, though no single application alone will use more than 3GB, it will most likely start different processes. Nearly all current computers that have more than 4GB RAM are SMP systems which justify the need for more RAM because they simply got more applications/processes running that make extensive use of the RAM.
2. Computing DOES NOT become faster because these processors got 64bit registers. Integers on 64bit boxes are still 32bits wide – at least all compilers I know use this size for integers (and 64bits for longs). Second, even if they were bigger, this wouldn’t make computation faster. Floating point operations still depend on the FPU or, if you use a good compiler or special compiler labels in your code, SSE(2,3) – independent of wether your processor is a 32bit or a 64bit one. The reason why the AMD64 architecture outperforms a lot of 32bit processors is simply their great design – their instruction prefetching algorithms, the hyper transport connection of the integrated memory controller, their large cache size etc. Especially Opteron-SMPs with their way of dividing the total amounnt of RAM between the single processors (the OS doesn’t realize this) are a very good alternative to e. g. Xeon based SMPs. But don’t say 64bit processors are faster because of they got a 64bit arch.
The larger address space isn’t of use for current applications.
The larger _virtual_ address space doesn’t matter for current applications
Both of these matter for databases and fileservers. With only 4GB of virtual address space, that means you can only mmap() a theoretical maximum 4GB of files per process. This is simply unacceptable for most fileservers and databases.
It also puts a ceiling of 4GB (or more typically 2GB) on database query results.
2. Computing DOES NOT become faster because these processors got 64bit registers. Integers on 64bit boxes are still 32bits wide – at least all compilers I know use this size for integers (and 64bits for longs). Second, even if they were bigger, this wouldn’t make computation faster.
This certainly does for anything which uses 64-bit integers or indices, most notably the 64-bit VFS layers of all modern operating systems.
AMD64 architecture outperforms a lot of 32bit processors is simply their great design – their instruction prefetching algorithms, the hyper transport connection of the integrated memory controller, their large cache size etc. Especially Opteron-SMPs with their way of dividing the total amounnt of RAM between the single processors (the OS doesn’t realize this) are a very good alternative to e. g. Xeon based SMPs. But don’t say 64bit processors are faster because of they got a 64bit arch.
That’s not to mention that AMD64 gives you a 30% performance boost thanks to extra registers and other niceities added to the instruction set.
You know, I remember reading similar arguements in the past when we were transitioning between 8 and 16 bits, and then again when we were transitioning to 32 bits. Nothing ever changes, does it? 😉
The larger address space isn’t of use for current applications. 4GB aren’t enough on clusters, maybe, but I’ve never seen a single program using more than maybe 2G of RAM.
Sorry dude but I’m frequently running into memory size issues with scientific applications. Being able to address over 4GB of RAM for doing any type of geographic analysis with large blocks of high resolution terrain and imagery or large sets of geodatabase elements is required, if not making it much less painful. While I agree that your run of the mill word processor or web browser doesn’t need the extra address space, the ability to work on bigger parts of images, movies or to do bigger engineering problems in scientific computing are loving the new 64-bit addressing.
“he ability to work on bigger parts of images, movies or to do bigger engineering problems in scientific computing are loving the new 64-bit addressing.”
NEW 64-bit addressing? Where have you been? This has been available for well over a decade on the desktop!
1) This whole article is an advertisement for IBM. PowerPC is especially non-special in its 64-bitness, courtesy of UltraSPARC, Opteron, MIPS, PA-RISC, Alpha, and Itanium.
2) I’ve been using 64-bit processors since 1995 or thereabouts, and I can count the number of times I _really_ needed 64-bit addressing on one hand. I just never had a program or a problem that required it. I basically run 32-bit programs on a 64-bit kernel all the time.
3) For consumer-level apps, a next-generation video game will most likely be the first program people use that requires 64-bit addressing. Either that, or Microsoft will really out-do themselves with the next version of Office.
I predict that the first ‘consumer’ app to really use 64 bits will be the next version of Windows Movie Maker, or similiar (for all those reasons that Bascule noted for fileservers and databases).
Of course VFS layers will be pleased first; although the user will never really know, I guess.
Discussion on OSNEWS about programming for architectures is very welcome in my book.
We do scientific computations as our main job and we run into memory problems when we want to postprocess our simulations. Since we bought a dual opteron with 12GB of memory, we have reduced our postprocess time A LOT, since no swapping happens now.
But we are interested in knowing, if the 64bit architecture also speeds up 64bit floating operations. Normally, 32bit floating operations are faster than 64bit ones on Pentium III, IV, etc.
AFAIK, nothing in the C nor the C++ standard guarantee that long will be able to hold a pointer value. For example, the C/C++ compiler from Microsoft use 32 bits integers for long even on x86-64.
The most portable solution I’ve found to get a 32 bits integer when on a 32 bits computer and a 64 bits integer when on a 64 bits computer is to use size_t.
By definition size_t is the type returned by sizeof() and will be able to hold the size of the largest object you’ll ever be able to put in memory.
Thus if you can address memory in 64 bits, size_t will be a 64 bits unsigned it.
The C standard (ISO C99) has a type intptr_t, which is useful for these cases. intptr_t is an integer type large enough to hold a pointer to any type of object.
@Bascule: I haven’t seen database applications yet that mmap 4G into one process’ virtual memory. Most commonly, there are several processes; one process handling B-Tree structures that take more than 4GB doesn’t seem very realistic to me. However, I’m not an expert on large database systems.
64bit-arithmetic in the VFS: I can’t believe that 64bit arithmetic leads to any feelable improvements when you got slow I/O devices like tertiary storage, network mounts etc. in the background. Additionally, there’s not much arithmetic done in the VFS, this is the job of the underlying file systems. Concerning the file systems, how many 64bit calculations have to be performed to access a file of say 10MB on an ext2 system? This doesn’t count much in comparison to the actual access time and throughput of the underlying device.
@Hank: I haven’t been working with things like geographical analisys yet, guess you have a point 🙂
@Miguel: Right, I didn’t think about preprocessors, postprocessors and solvers, but those are kind of rare applications which have been using SGI workstations or AIX/Blade Clusters for the last ten or twenty years, anyway.
In general, I’m not an opponent of 64bit architectures. I liked the Itanium design very much, I like the quad-Opteron cluster we are using to perform e. g. electromagnetical simulations, and yes, 4G of RAM haven’t been enough on the old Xeon cluster. There’ve been some good points in the forum against my opinion, thanks.
The reason why postet my opinion was because imho the title of the article was dumb and there’s a lot of hype about 64bit architectures from people which just don’t know enough about the whole topic. Most of you have been working in very special environments like scientific computing, large databases, CAD/simulations. These “extreme” areas have been using 64bit architectures for quite some time. Pretty much everything apart from these examples (very large enterprises, scientifc computing) doesn’t make use of the advantages of a 64bit architecture.
Although these comments and indeed the article are a bit over my head its nice to see comments that actually add to the article rather than just the usual comments that can’t be summed up as “this sucks” or “this rules”.
Surpirsing given that this article relates to an architecture found in Apple macs as those article have a habbit of inducing such comments. I guess its still early…
for what its worth these comments are very interesting indeed.
“…its nice to see comments that actually add to the article rather than just the usual comments that can’t be summed up as “this sucks” or “this rules”.”
Sorry about that. How about this classic: “UNIX sucks, but everything else sucks more.”
“Although these comments and indeed the article are a bit over my head its nice to see comments that actually add to the article rather than just the usual comments that can’t be summed up as “this sucks” or “this rules” …”
You know why there are not such comments here? Because OSNews rooolz! Buhahaha! And this doesn’t suck!