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?"
The hardware / software industry (generally speaking) doesn't care about quality, as long as they are so busy competing with eachother in a high pace. Because companies are competing they will seek some features others haven't and most fo the time the relevancy of those features is very small, especially if the company has become very big (exceptions of course are always there). The crowd isn't very picky either, though it is clear open source has put value to the development of portable software. People buy a amd64 (not only because of the price, ofcourse some geeks also for the 64 bit feature) but the majority runs still 32 bit binary windows software on it. So most people don't care so much I would say. They just buy something because it's cheap, to play games on and do things like patience, free cell and the basic things like word etc. There is so much technology to know about that at some point people don't care anymore. The next day there will always be newer and faster hardware.. Even when you only wanted to make a simple document. But then you have to use Vista (for some) so then you would need a faster computer.. Portabillity is only useful for people who don't want to keep buying software and are fed up with it. A very few of them make their hands dirty and migrate to open/free source software or start to write alternatives themselves. To those people these thing really matter. They want to make something durable and it simply takes time for software to mature. Portabillity of code really matters if there are more open source/ free software users and developers. Then people will experience the benefits of portable code.
that this transition isn't all that painful.
My personal experience with this was Linux on Alpha, where certain programs assumed a 32-bit environment, rather than querying the system they were built on for size of int, pointer, etc. As a result many programs were funky on the Alpha, and the 'pc-isms' (what we once would have called Vaxocentrisms) caused great waste of time as they had to be tracked down an eliminated.
Your code, if you've been worrying about anything other than 32-bit PCs, should already be 64-bit clean, as you've had 15 years of Alpha, SGI, Power, Itanium, and Sun 64-bit systems to support. If it isn't, hopefully it's something such as user interface which will still run in the 32-bit environment, though not necessarily optimally.
Personally, I think that writing robust, portable, code is worth the effort. Unless you're talking about running on an embedded system where every byte counts, it doesn't hurt you at all to design clean algorithms and data structures, and put in checks to actually determine the size of ints, longs, pointers, etc, rather than just assuming that everyone will run x86 (or MIPS-64 or whatever) from now until the end of time. I have research programs that were written in the 70s (in their original form), on Cyber 205 and similar long-gone architectures, which still work because they were written in a mostly portable manner, with only the most critical nasty bits tied specifically to that machine. Your code is going to be in use longer than you think; be nice to your successors and make it portable now.
the more accurate the calculations became, the more the concepts tended to vanish into thin air. R. S. Mulliken
Does "hackwrench" even know how to program? Does he know anything about Computer Architecture? "Hennesy" or "Patterson" ring a bell? Sounds like "Cliff" likes to feed trolls. Maybe "hackwrench" will choke while digesting this one:
What is the inherent "slowness" of "16 bit code" WTF is "16 bit code" anyway? Sounds like has been duped by the marketing droids...
So-called "32-bit" processors are typically designed to perform (up to) 32-bit arithmetic efficiently. For integer operations, 8bit, 16bit and 32bit arithemetic usually each take the same amount of time (8bit add = 16bit add != 16 bit multiply) .
Because "32-bit" processors can do "32-bit" arithemtic efficiently, it makes sense for them to use (up to) 32 bits for addressing. Arithmetic involving addresses comes up more often than you would think... (Branch/Jump instructions, memory operations, and even the basic updating of the program counter). Since these processors data paths are (typically) 32-bits wide, instructions are typically coded using up to 32-bits. (In a 32-bit RISC processor, most of the instruction bits are reserved to allow large immediate operands for memory offsets, jump targets, and arithmetic/logic operations).
The only thing a "32 bit" processor typically isn't good for is "64 bit" arithemtic. (And any arithmetic over 32 bits for that matter). Which means on these, a "64 bit" addition could be performed using 3 "32-bit" additions and a branch. "64-bit" multiplications get even worse...
But if a program doesn't access much memory ( packed arithmetic whereby it can treat a 32-bit integers as a pair of 16 bit integers and a single operation can calculate both results... But this by itself is hardly justification alone for using such a processor.
So guess what folks: There will likely never be a "1024bit" processor. (At least not for general purpose computing). I'm not trying to sound like Bill Gates with his "640k is enough" quote, but I don't see why processors will ever use much more than 64 or 128bit addressing. (Keep in mind that EACH BIT *doubles* the range of integer numbers/addresses the procesor can handle efficiently).
Yes we now can have 2^32 bytes of memory in computers (4GB). But WTF is anyone going to do with 2^64 bytes of ram? Thats probably many orders of magnitude greater than the total capacity of all electronic devices ever produced from the 1950s until now...
In conclusion, WTF? Mod Editor Down!
A lot of people are writing responses that tend to assume it is impossible to write code that is portable, and also optimised for a specific platform. I recently read a book called "Vector Game Math Processors" (everybody needs a hobby, right?). Looking at how the examples were coded in that book sort of shifted my assumptions about how I should do things.
Basically, the book covers the major vector instruction sets: Altivec, PS2, SSE, etc. Naturally, a program written with hand optimised SSE assembly won't run very well on a PowerMac G4. So, the approach the author used was to start by coding a vector math function in plain C. He only calls this function by a function pointer. So, instead of calling sw_vector_foo directly, he calls vector_foo. He then goes on to write altivec_foo, and sse_foo, and gamecube_foo. With some simple #ifdefs at compile time, the function pointer is assigned to the most optimal code path for the platform.
So, the result is that by thinking about portability going in, he doesn't have to do hardly any work to have fairly optimal hand-tuned vector routines for a new architecture.
In general, code written to be portable is also much cleaner, and better commented, and whatnot, just because the author was forced tos pend an extra few minutes thinking about how things ought to be put together. I really can't think of any normal case where portability shouldn't be a consideration. On some obscure embedded systems, you might really want to optimise to a super specific piece of hardware, but it is seldom worth it.
Think about writing GUI apps for a Palm pilot before the switch to ARM CPU's. A programmer could have said, "hey, I'm using the Palm OS API's, and they only run on Coldfire CPU's, so I have no reason to make anything portable." Then, a little while later, Palms OS starts running on ARM. If he had invested a smidgen of extra effort to write his code in a portable way, he could easily start to take advantage of the ARM stuff right away. Since most of the issues of portability are in the planning phase, and get handled at compile time, the difference in memory footprint need not be appreciably larger. (Like a bunch of hand coded ASM for a different platform, which get's #ifdef'd away, or sizeof() operators...)