• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

No Instant Gratification - Ed Stroligo 3/24/05

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

TollhouseFrank

Senior Headphone Guru
Joined
Nov 29, 2004
Location
T3h Intr@tub3z!
http://www.overclockers.com/tips00749/

I think Ed is pretty much on the money here, folks. For those of us that remember going from (even 8-16 bit!) 16-32 bit, it took a long time. That's why we still had 16 bit support even into 98se. ME/NT ended that, pretty much.

However, You can still find support for some of your old favorite 16 bit programs (emulators and whatnot). Even with all the new technology coming, and many of us being early adopters, we have to remember, that the average user doesn't care about latest and greatest. they want something that gets them online, and lets them write up a report in word or whatever word processing program they have..

64 bit support could take a good couple of years to really become strong. Also, in my opinion most technology in the pc-world is entertainment driven in some way or another. Until there is a demand for 64bit entertainment (on a PC), then you shouldn't expect developers to jump on the bandwagon.

There are those that take the 'wait and see' approach, and are always waiting. There are always early adopters. However, with 64Bit Personal Computing still in its relative infancy, it will take time for it to mature and become what 32 bit has become.

But anyways, even though it sounds a bit like Ed is hittin' hard on us who like new technologies, I can see his points about the NEED to adopt now. We dont' need to adopt these new technologies until there is something that makes sense to use it for (like great 64bit support)
 
Last edited:
I have a question: is Ed a programmer?

Imho I think he is not and it shows. The reason it took so long from 16 to 32 bit was the totally different programming model with 32bit: segmented 16 bit real mode and flat 32bit protected mode which finally introduced relatively hard to grasp memory protection and multitasking. The reluctance of programmers using the 16bit protected mode from 286 prompted intel to introduce migration paths like the virtual 8086 mode in the 80386. The 32bit itself wasn't what made it hard, programmers and compiler makers loved to use EAX instead of simple AX in real mode immediately. They just shied away from the complicated switch to protected mode where they would have to write each and every driver, even the OS, for themselves since those just didn't exist.
MS took a long time to port windows to 64bit, but they finally did it. Even a small company like Apple can/could do it.

Linux is fully 64bit on certain hardware for ages now and while there were some bugs when porting to 64bit, stuff like integer overflows und underflows and such, it wasn't a big deal, or niche architectures like alpha and sparc64 would never have gotten the needed amount of work: not cost effective to really rewrite from scratch.

With our current transition there are no real hard parts, mainly that registers are a bit wider like with the 80386 real mode and arrays can be bigger. It's not totally trivial for people like MS to write backwards 32bit compatible APIs, structs which are suddenly twice the size for example. But they have experience in thunking now precisely because they already made the 16->32 bit jump once before and they don't have to implement proper multitasking and memory protection anymore.

Will we totally switch to 64bit in 2-3 years like we will with the AGP->PCIE switch or PATA->SATA? Of course not: as long as not a substantial percentage of the given market for some software has 64bit capable CPUs, a software maker won't port his 32bit software. But there are two things in favour of it: very soon now, any CPU you buy is 64bit capable and the effort to port is magnitudes lower than it was in the 386 days. Basically a recompile is most you need provided you wrote clean code in the first place. So unlike the 16-32bit transition, the needed benefit to make a port worthwhile is much much lower. Technical reasons to go 64bit are a bigger address space and algorithms that are parallelizable: moving 64bit instead of 32 per operation.
How many programs need 2GB or more right now? probably less than 1 percent. Your office program, your browser and almost any other program you have open won't conceivably benefit from 64bit. Pretty much only databases and some multimedia programs dealing with video do right now. The multimedia programs can fairly easily deal with it without many problems usually. so it would be nice but not mandatory unlike databases. But real soon there will be another category which is much bigger and dearer to the heart of the average overclocker: games. We now enter the age of 512MB videocards. Thats not far from the 2GB max per process for main RAM. Since all textures and things in the video ram comes from main ram and directx10 will use techniques like the nvidia 6200 turbo cache by default even for the very high end cards, you will see that 32bit CPUs just won't cut it for very much longer with the best FPS engines out there. Another thing is, videogames are one of the application domains where parallelization is very easy to do, netting big gains: if you push 32bit to the videocard ram per movsd or 64bit (what's the asm mnemonic for movs* for 64bit anyways) is a speed factor of two. Vectors also would benefit from wider registers of course, not to mention the increased amount of registers. Of course there will still be smaller game makers which say "there are still many people with 32bit machines only, so I can't just ignore them" but the biggest and best FPS engines all will have 64bit versions. Makers of Far-Cry, Doom3 and HL2 all recompile their games for 64bit right now apparently: no matter how small the gain of going to 64bit, FPS gamers will want it. But even with 32bit games, as soon as nvidia gives them a full 64bit driver underneath their 32bit games, even they can benefit since the average game spends a LOT of time in that driver instead of its own code. This is a speedup any programmer of games gets for totally free even, no work necessary.

There is one thing however that Ed mentioned which will take ages to make use of, and maybe it won't ever fully used with consumers: multicore CPUs. Multicore means multithreading and that is a big can of worms for every programmer. No one will program multithreaded if he can help it right now and while it's been available for mainstream programmers since at least windows95 it's still a very very hard problem to do it effectively. So while we will soon have the CPUs, utilizing them effectively will be a very long way off for consumer software, especially games.
 
still... remember... when you go from 32 bit to 64 bit, it is more than a few registers on teh chip.... it is MUCH MORE PROGRAM you have to write. 64bit programs are much more complicated than 32 bit programs. Just like a 64 bit game is more complicated than a 32 bit game.
 
still... remember... when you go from 32 bit to 64 bit, it is more than a few registers on teh chip.... it is MUCH MORE PROGRAM you have to write. 64bit programs are much more complicated than 32 bit programs. Just like a 64 bit game is more complicated than a 32 bit game.

Are you serious?
 
if programming for a 64bit OS is ANYTHING like programming for a game, there is more than a few registers that need switched on. They have to program thier software to make USE of the 64 bit environment. Sure, they could still make it '32 bittish'... but it still take more space to store and run.

i may be wrong. Maybe my comparison to game consoles was a bit off mark. but, its the best i can think of as a comparison for programming difficulties when you go up a degree from say, 32 bit to 64bit
 
yes it is off mark. The reason game console were called "N64" and the like was marketing and perhaps because their graphics chip was 64bit. Their CPU was 32bit or even 16bit sometimes. Only the next generation of consoles will have 64bit CPUs: PowerPC 970 derivatives.

Linux Distros like Debian have 64bit versions for years for alpha, sparc64 and mips. It's the same software like x86. All that was needed was a copy of gcc/binutils which generated 64bit binaries and clean,portable source code
 
still though... i think the big fight will be sorta along the lines of what Ed said, and that's proving to 'joe sixpack' that he needs 64bit, and must switch to it.

Could be 3-4 years before a majority of people are on 64bit OS's.... imagine all the messes that is gonna cause software developers!!!
 
TollhouseFrank said:
still though... i think the big fight will be sorta along the lines of what Ed said, and that's proving to 'joe sixpack' that he needs 64bit, and must switch to it.

Could be 3-4 years before a majority of people are on 64bit OS's.... imagine all the messes that is gonna cause software developers!!!

I think 3-4 years is pretty optimistic. Even though most of us probably get a new pc annually most people I know thar aren't geeks get a new pc every 5-7 years.
My Dad came off a Pentium 133 to a P4 2.4 just a few months ago.
 
i know.... like i said, its going to be hard to convince people that they "need" to upgrade thier expensive systems to a 64 bit system just a few months after they got it.
 
Back