Linked by David Adams on Tue 22nd Feb 2011 19:52 UTC, submitted by estherschindler
General Development Your company is ready to upgrade its custom applications from 32-bit to 64-bit. (Finally.) Here's 10 tips to help you make the transition as painless as possible.
Thread beginning with comment 463735
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: ?
by rexstuff on Wed 23rd Feb 2011 19:39 UTC in reply to "RE: ?"
rexstuff
Member since:
2007-04-06

I find it's less to do with having written perfect software and more to do with the programmers trying to be more clever than they actually are. Trying to do things like custom pointer arithmetic or weird signed operations will break an app in a bad when moving between 32 and 64 bit. The few extra clock cycles you save are in no way worth the portability penalty.

Laziness can also play a part. Assuming 'int' and 'void *) are the same size, instead of using something like uintptr_t.

The moral of the story: don't try to outsmart the compiler. You will regret it, eventually.

Of course, if you're relying on some third-party library, which doesn't have a stable 64-bit version, that's a different story (and raises the question: why are you relying on a poorly supported third party library?)

Reply Parent Score: 1

RE[3]: ?
by saso on Wed 23rd Feb 2011 20:27 in reply to "RE[2]: ?"
saso Member since:
2007-04-18

I find it's less to do with having written perfect software and more to do with the programmers trying to be more clever than they actually are. Trying to do things like custom pointer arithmetic or weird signed operations will break an app in a bad when moving between 32 and 64 bit. The few extra clock cycles you save are in no way worth the portability penalty.


It isn't necessarily as simple as that. Very hot inner loops, particularly in graphics processing software, can necessitate a few dirty tricks to get the maximum performance out of the hardware. However, such occurrences should be few and far between, and should always be clearly marked as such and handled with care. What you describe is what comes out of a programmer doing what exactly Donald Knuth warned against: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil".

Reply Parent Score: 1