32 to 64bit aint a big leap, why?

[metalmackey]

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

 

[Cob]

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?

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

Oh, and how did 8bit CPUs handle large numbers?

Slowly

 

[michael baxter]

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



Slowly

You don't know what you are talking about, it's not because software developers aren't prepared to put effort in.

 

[Cob]

Very informative

 

[michael baxter]

Very informative

Ask me, and I will tell!

 

[Cob]

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

 

[wjfcomputers]

Ask me, and I will tell!

The OP already asked. Stop being a plank.

 

[james.miller]

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.

 

[michael baxter]

The OP already asked. Stop being a plank.

Name calling and all that!

James Miller has answered the question with aplomb!

 

[metalmackey]

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.

Thanks, cisnt more data being processed at once, which will be faster?

 

[james.miller]

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.

 

[metalmackey]

So its not possible for a 64bit cpu to process say 3 16bit numbers at the same time (1 cycle)?

 

[BillytheImpaler]

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.

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.

 

[NathanE]

You don't know what you are talking about, it's not because software developers aren't prepared to put effort in.

That's not true though is it. The problem has many factors and lazy software developers is quite high up the list of reasons.

 

[james.miller]

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.

 

[metalmackey]

So will 64bit be the max and only clock speeds and more cores going up? As 128bit CPUs will seem pretty useless.

 

[NathanE]

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.

 

[metalmackey]

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.

 

[qwerty07]

One word: Software

 

[BillytheImpaler]

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.