Slashdot Mirror
The Sacrifices of Portablility?
hackwrench asks: "There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused. One example is being able to write a program that purposely uses a combination of 16-bit and 32 bit. I know there are arguments that writing solely in one or the other is a performance advantage, but what are the factors involved? Is the slowness of such a combination inherent in its design or is it a result of current hardware. We are beginning to replace systems and programs designed primarily to run in pure 32-bit mode with systems designed to run in pure 64-bit mode, so I ask: Is such purity really worth it?"
Is the problem that the compiler optimizations are not producing the right outputs? or too much of the code is compiled with debug flags (ie: -g). I would expect the compiler to handle things, but i've found that I rarely have the desire to run the non-debug code as when things do go south it's rare and i'd rather have ease of solving the problem being available to me. There are some cases where I don't do this where performance matters, but that's rare in my experience.. People have done many studies of what compiler optimizes things better, eg: gcc vs intel compiler. gcc vs sun compiler. Generally the one written by the vendor does a slightly better job.
See http://en.wikipedia.org/wiki/64-bit: "A change from a 32-bit to a 64-bit architecture is a fundamental alteration, as most operating systems must be extensively modified to take advantage of the new architecture. Other software must also be ported to use the new capabilities; older software is usually supported through either a hardware compatibility mode (in which the new processors support an older 32-bit instruction set as well as the new modes), through software emulation, or by the actual implementation of a 32-bit processor core within the 64-bit processor die (as with the Itanium2 processors from Intel). One significant exception to this is the AS/400, whose software runs on a virtual ISA which is implemented in low-level software. This software, called TIMI, is all that has to be rewritten to move the entire OS and all software to a new platform, such as when IBM transitioned their line from 32-bit POWER to 64-bit POWER. While 64-bit architectures indisputably make working with huge data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks. Theoretically, some programs could well be faster in 32-bit mode. Instructions for 64-bit computing take up more storage space than the earlier 32-bit ones, so it is possible that some 32-bit programs will fit into the CPU's high-speed cache while equivalent 64-bit programs will not. However, in applications like scientific computing, the data being processed often fits naturally in 64-bit chunks, and will be faster on a 64-bit architecture because the CPU will be designed to process such information directly rather than requiring the program to perform multiple steps. Such assessments are complicated by the fact that in the process of designing the new 64-bit architectures, the instruction set designers have also taken the opportunity to make other changes that address some of the deficiencies in older instruction sets by adding new performance-enhancing facilities (such as the extra registers in the AMD64 design)."
In 32 bit protected mode, 16 bit instructions require a prefix to tell it that the following instruction is 16 bit, wasting a byte and a CPU cycle. In 16 bit real mode, the same is true of 32 bit instructions. But modern processors aren't optimized to preserve 16 bit performance. If they can improve 32 bit performance just a little, they'd be willing to sacrifice a lot of 16 bit performance to do it. Also, if you're mixing 16 and 32 bit variables in C/C++, it'll do a lot of expensive conversions to make it all work. I've done very little with 64 bit though, aside from playing with MMX on one occasion.