• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

32 to 64bit aint a big leap, why?

metalmackey

metalmackey

metalmackey

Associate
Joined
28 Jun 2005
Posts
2,174
Location
Behind you
Hi guys,

I was just wondering why going from 32bit to 64bit CPUs doesnt seem that much better compared to going from 8bit to 16bit or 16bit to 32bit, where there was a big difference. Most 64bit CPUs are still running in 32bit mode, is it because software hasn't taken advantage of 64bit yet, or is it because we dont need 64bits yet?

Oh, and how did 8bit CPUs handle large numbers?
Thanks
 
metalmackey said:
Hi guys,

I was just wondering why going from 32bit to 64bit CPUs doesnt seem that much better compared to going from 8bit to 16bit or 16bit to 32bit, where there was a big difference. Most 64bit CPUs are still running in 32bit mode, is it because software hasn't taken advantage of 64bit yet, or is it because we dont need 64bits yet?
Click to expand...

It's all because the software developers won't put the effort into x64 yet.

metalmackey said:
Oh, and how did 8bit CPUs handle large numbers?
Click to expand...

Slowly :p
 
The OP asked already.

And I'd like a explaination other than the usual software companies response of "there's no market for it yet".
 
tell first and people wont have to ask you

64bit isnt much faster because, put rather simply, it olny really allows bigger numbers to be used without having to split them up - which slows the process down conciderably becuase you have to process the larger numbers in seperate chunks.

With the transition from 8 to 16 bit you see an increase in the biggest number you can store as a whole from 255 to 65,535. moving to 32bit that increased again to 4,294,967,295.

As you can imagine a 64bit number it pretty damn large (18,446,744,073,709,551,615), and there arent many uses for numbers with that many digits which is why a lot of programs wont benifit from 64bit *as they are* unless totally rewritten with some heavy optimisation.

what it does do is overcome the memory limitation for 32bit cpus which is roughly 4gb. I'm sure that'll be useful sooner or later lol.
 
Last edited:
james.miller said:
tell first and people wont have to ask you

64bit isnt much faster because, put rather simply, it olny really allows bigger numbers to be used without having to split them up - which slows the process down conciderably becuase you have to process the larger numbers in seperate chunks.

With the transition from 8 to 16 bit you see an increase in the biggest number you can store as a whole from 255 to 65,535. moving to 32bit that increased again to 4,294,967,295.

As you can imagine a 64bit number it pretty damn large (18,446,744,073,709,551,615), and there arent many uses for numbers with that many digits which is why a lot of programs wont benifit from 64bit *as they are* unless totally rewritten with some heavy optimisation.

what it does do is overcome the memory limitation for 32bit cpus which is roughly 4gb. I'm sure that'll be useful sooner or later lol.
Click to expand...
Thanks, cisnt more data being processed at once, which will be faster?
 
not really. Its more complcated than just talking about the size of numbers due to modern cpu optimisations (which are also out of my depth) but basically it would take a 64bit cpu the same time to process a value of 200 as an 8bit cpu - 1 cycle. the difference being when they are asked to process a large number where the 8bit cpu might split it in to two chunks or even 3 and so take more cycles to process the same number.
 
james.miller said:
not really. Its more complcated than just talking about the size of numbers due to modern cpu optimisations (which are also out of my depth) but basically it would take a 64bit cpu the same time to process a value of 200 as an 8bit cpu - 1 cycle. the difference being when they are asked to process a large number where the 8bit cpu might split it in to two chunks or even 3 and so take more cycles to process the same number.
Click to expand...
Indeed. Remember too that all this bit discussion is for integers. Floats are best when optimized for SSE (or AltiVec depending on architecture ;)). SSE provided four registers for 64-bit floats back with Katmai. SSE2 brought 128-bit operations to the table with even more registers.
 
michael baxter said:
You don't know what you are talking about, it's not because software developers aren't prepared to put effort in.
Click to expand...
That's not true though is it. The problem has many factors and lazy software developers is quite high up the list of reasons.
 
thats right. cpu's these days are very advanced, but it does require optimisation of code from the programmers to get the most out of them. So yes, a lot of it is down to lazy programmers.
 
128-bit general registers will arrive some day, but not in the foreseeable future. It's going to take a long long time before developers start feeling constrained by 64-bit.
 
Seems like developers have got it easy now, back in the 8bit days they had toovercome the limits. Now with all the SDKs like DirectX and 32/64bit big limits, a lot of the work is done for them.
 
Hey qwerty, welcome to the forums. You might want to make yourself familiar with the FAQ. Your sig, if it's going to be text, has to be fewer than 4 lines of regular sized text.

Enjoy yourself. :)

EDIT: I meant to say that it has to be 4 lines or fewer. Perhaps I should go re-read the FAQ. ;) :D
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom