Haven't you ever heard of porting ? You won't be seeing good development tools either in a very long time so you better get used to this 'p'-word. Actually it is easy and it tends to make you think twice before writing your code... I have my potion of this stuff every day.
What really is costly is the manpower - not the slavelike working CPU's or never forgetting DIMM memory chips. If you start to save money by optimizing your program you will end up in a product that has a very brief lifespan. Optimization tends to make the code kinky. What has been so neat in UT2003 and it's precedessors is the structure of the program - this is why I play UT in the first place. Guys over at Epic could have written it entirely with MASM and make the thing fly in a 386 but luckily they chose the only solution that can withstand the merciless teeth of time. As a programmer (a very old programmer) I know what "oops, I forgot" really means. To me the clarity of code does always come before anything else. Programs written in a straightforward way are easier to port too. There are not too many things you can actually optimize in a program that loves memory and cycles. Todays compilers are very good in doing effective code and there isn't much you can do with the memory either. There are tools that you can use to detect memory leaks etc.. I just wonder what you could possibly squeeze off? I take it as an insult if someone claims me to be a lazy programmer the only argument being too big or too slow program. So you guys are wondering where to develop the 64 bit programs - you can develop them righ now in your 32 bit laptop - just code them in such a manner that the final porting can be done easily - maybe just recompiling the thing and that's it. I don't expect to have all these nice tools like BoundsChecker available for 64 bit platform in the near future. I can also give you a nice sample of what I mean here: I run a site called UTCMS (http://furpile.com/UTCMS/) which is running on a Alpha DS10 (64 bit Alpha processor). This is because I get those boxes cheap and because these seem to be pretty effective. I have developed a great deal of software for that machine with Borland C++ Builder - an ancient tool. I have never had any problems porting the stuff between the server and the developing platforms. Originally I had this server on an Intel 32 bit machine and it clogged often - the reason is my cumbersome way of creating everything on the fly - this 64 bit Alpha has no problems even if the CPU itself is running four times slower than the Pentium. This behaviour (or merely the lack of it) is a direct result of the wider address space - no swapping - no lagging.
Slashdot Mirror
Haven't you ever heard of porting ?
You won't be seeing good development tools either in a very long time so you better get used to this 'p'-word. Actually it is easy and it tends to make you think twice before writing your code... I have my potion of this stuff every day.
What really is costly is the manpower - not the slavelike working CPU's or never forgetting DIMM memory chips. If you start to save money by optimizing your program you will end up in a product that has a very brief lifespan. Optimization tends to make the code kinky.
What has been so neat in UT2003 and it's precedessors is the structure of the program - this is why I play UT in the first place. Guys over at Epic could have written it entirely with MASM and make the thing fly in a 386 but luckily they chose the only solution that can withstand the merciless teeth of time. As a programmer (a very old programmer) I know what "oops, I forgot" really means. To me the clarity of code does always come before anything else. Programs written in a straightforward way are easier to port too.
There are not too many things you can actually optimize in a program that loves memory and cycles. Todays compilers are very good in doing effective code and there isn't much you can do with the memory either. There are tools that you can use to detect memory leaks etc.. I just wonder what you could possibly squeeze off? I take it as an insult if someone claims me to be a lazy programmer the only argument being too big or too slow program.
So you guys are wondering where to develop the 64 bit programs - you can develop them righ now in your 32 bit laptop - just code them in such a manner that the final porting can be done easily - maybe just recompiling the thing and that's it. I don't expect to have all these nice tools like BoundsChecker available for 64 bit platform in the near future.
I can also give you a nice sample of what I mean here: I run a site called UTCMS (http://furpile.com/UTCMS/) which is running on a Alpha DS10 (64 bit Alpha processor). This is because I get those boxes cheap and because these seem to be pretty effective. I have developed a great deal of software for that machine with Borland C++ Builder - an ancient tool. I have never had any problems porting the stuff between the server and the developing platforms. Originally I had this server on an Intel 32 bit machine and it clogged often - the reason is my cumbersome way of creating everything on the fly - this 64 bit Alpha has no problems even if the CPU itself is running four times slower than the Pentium. This behaviour (or merely the lack of it) is a direct result of the wider address space - no swapping - no lagging.