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?"

Comments

It depends

[sfcat]

There are many factors that go into deciding how to write code. Portability is just one consideration of many. I would say that it is worth it if speed is of critical importantance and development expenses are of no concequence.

For instance, consider a video game. The faster it is the more likely it is that players will like it. But there are many more important factors including is the game just plain fun. So in video games, there is really a basic threshold of speed that needs to be met and after that is met, other factors are more important.

Next consider a real time system for trading stocks. This system is all about speed and reliability. You can control the deployment hardware and it is economically worthwhile to spent a lot in development if it makes more money in the long run. So coding your own memory pooler that uses the size of the pointer and a specific struct to make the code allocate and deallocate memory in constant time (it is very possible) is worthwhile because it can save alot of time per transaction.

But all of these issues come down to what exactly you are writing and both the technical and business requirements of your project. Without knowning those in advance, we can't really answer your question.

Does it matter?

[Jah-Wren Ryel]

It used to be that computers were expensive and people were relatively cheap. Nowadays, the reverse is generally true.

So, unless these systems have performance critical portions, like high-speed digital signal processing where every FLOP counts, it really isn't worth the extra effort to optimize your code for the platform - you'll just end up having to hand-tweak (or even worse, un-tweak) it again on the next hardware upgrade.

Re:Does it matter?

[richg74]

It used to be that computers were expensive and people were relatively cheap. Nowadays, the reverse is generall

For most applications, the potential performance gains from hand optimization for a specific platform aren't enough to matter. (And, as I think Brian Kernighan said, trying to outsmart the compiler defeats the purpose of using one.) Big performance gains come, in most cases, from figuring out a better way (~algorithm) to solve the problem, not from tweaks.

There's another aspect of portability that doesn't get mentioned too much: the portability of the programmer. If you are in the habit of writing portable code, it's much easier to shift to working on a different platform. (I'd also say, from my own experience, that it makes your work less error-prone.) That versatility is potentially of significant value to your employer, and of course is of value to you personally.

This is the compiler's job.

[stienman]

There is lots of talk about writing portable programs, but this pursuit has resulted in a lot of processor features going unused.

This is the compiler's job. If your compiler targets a particular processor poorly, get a better compiler.

There is no such thing as portable code:

• There is code that is written according to the language specification (Ansi C, Java, etc), which is what one normally considers "portable" only because standards compliant compilers exist for several platforms.
• There is code that uses processor/platform/OS/compiler specific extensions, which is normally considered unportable because libraries don't exist for all platforms.

When most developers talk about portability they are talking about OS portability. The portable-to-other-processors debate has long since left the building largely due to incredible speed increases in processors. There's no reason, apart from esoteric algorithm tweaking, to code something in a processor specific manner.

Code porting to another OS is only an issue because operating systems and the hardware they run on are still changing at a dramatic pace. There is no standardized language that covers all the common aspects of a modern operating system, because they are aiming at a moving target. Even the ultra-portable Java has to be extended outside of the official specification to cover serial ports, complex sound, complex graphics, etc.

Portability hasn't been about processor speed for a very long time, and at this point it shouldn't be - a better compiler or a faster processor is a *ton* cheaper (time, money) than writing processor specific code in all but a few extraordinary cases.

-Adam

The performance question

[be-fan]

A couple of points about optimization.

1) Premature optimization is evil. Everybody says this, but so many people do not take it to heart. I'd rather have software that works, than software that is fast but crashes. As a programmer, its nice to work on non-buggy software, even if its not as fast as it could be.

2) Target-specific optimization is generally evil, unless you're sure your code will not live very long (eg: a game). The thing is that micro-optimizations generally tune for a particular processor, and actually pessimizes the code in the long run. In comparison, if you write good general code, it'll still be fast ten years from now when processors look very different.

3) The bottlenecks that people, especially C/C++ programmers worry about, are usually not the bottlenecks that usually matter. If you worry that your code could be faster/more memory efficient if you use a 16-bit field here or there instead of a 32-bit one, your algorithms better be absolutely perfect. Most code does not use perfect algorithms. That's why so much software is still so slow. Most programmers just don't get the time to use the best algorithms, much less get down to the level of micro-optimizations.

That's why I always find language performance debates entertaining. C/C++ programmers will freak out if you tell them language X is very productive, but is maybe two-thirds as fast as C (something that is true of a number of high-level, but compiled, languages). Meanwhile, they will write code that runs at maybe 1/3 of what the machine is capable of, because they spend so much time writing the code they have little time to optimize it.

Re:Detailed Reponse to Cliff and HackWrench

[Anonymous Brave Guy]

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?

I don't know. Then again, ten years ago, if you'd told me that an e-mail client or web browser would require tens of megabytes of memory just to load, or it would require over 100MB just to store the quick start-up code for an office application, I'd have laughed. Right now, that's exactly what Firefox, Thunderbird and OpenOffice 2.0 are claiming on the PC where I'm writing this.

Actually, I'm still laughing, because that says more than words about the design of those applications and the tools used to compile them. But the applications have expanded to fill the space nevertheless.

Re:Ideally, your code is clean enough

[Taladar]

If you have to test it on another architecture you are not writing portable code. Portability is less about specific architectures and more about "don't assume anything that might not be true on other architectures" like endianess, sizeof(int),...