|
Your estimates are a bit conservative!
Each atom has several electrons, each of which can be put into several excited states. The nucleus consists of protons and neutrons (a whole bunsch of them) consisting in turn of quarks held together by lots of gluons.
Since gluons are charged paticles they themselves produce a load of other particles.
So much for the word 'never'.
Apart from that, you yourself state that 2^64 is (if not realistic) at least thinkable. If I need 2^64 + 1 Byte, I need 128-Bit adress space (assuming that the doubling of address space is the only operation known to processor developers).
Wolfgang Reichl
|
|
|
|
|
You're right, I was being extremely conservative
Actually, I only used the word 'never' in the title, and qualified that in my post by saying that a 128 bit address bus is physically possible, but puts us into Star Trek territory.
I would include gluon engineering in the same category.
So, I guess it would be possible for the Star Trek computer to exceed 128 bits if it did those kinds of tricks.
I think it's an extremely safe bet, though, that we won't need to go through another change of sizeof(void *) in our lifetimes.
I'm much more interested in 64 bit data, myself.
mov rcx, 0
slowloop:
inc rcx
jnz slowloop
; if the loop executes at 10GHz,
; we don't get here for 100 years!
I started off on an 8-bit 6502 -- 64 bits is seriously cool.
Tschüss,
-Don
|
|
|
|
|
So ... the answer to the question:
Why do you need 128 bit addresses?
could be
to boldy go where no data has gone before!
or even better ...
to boldy store... where no data had stored before
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Well, the current limit on Windows of 2GB of addressable memory per process is not so hard to reach no? 64bit addressing allows us to go beyond that limit, that's already extremely useful. Don't worry about having 2^64 bytes of physical RAM just yet, we'll see about that in time... For now, I really love to be able to actually use the 16GB of RAM my server has.
|
|
|
|
|
That's the key distinction a lot of people seem to be missing - we're talking address space, not physical RAM. Regardless of how much RAM or free disk space you have, with a 32-bit address space one process can only access up to 4Gb of 'memory' tops, and in practice the OS restricts this because the kernel tends to need to stay addressable at all times (Windows cuts it down to 2Gb, with a 3Gb option in 2k3/XP I think; Linux is 3Gb I believe).
For example, you could argue that in a virtual memory environment with plenty of disk space, memory fragmentation is not an issue because any wasted memory will eventually just get paged out to disk and stay there. However, it's really easy to run out of address space, which means the OS can't give you any more memory because you've run out of pointer values to point at it.
Simple things like this will run out of address space on Windows long before actually allocating 2Gb of RAM:
vector<int *> vec;
do {
vec.push_back(new int);
} while(1);
Not because of allocating all the ints, but because of all the holes left behind as the vector gets resized continually.
|
|
|
|
|
The numbers I process range from 0 to 0xff. So I have the choice of seeing the compiler wrap my (intended) code with masking ops or run into loads of cache misses when using int-arrays.
64-bit ops just make things worse.
This seduces me into processing several Bytes (4 currently, 8 in future) in parallel, which does great things to code readability . But since I would kill for an eightfold increase in speed, it doesn't really matter anymore .
I want 8/16 bit instuctions back (if that came with a dozen 8-bit ALUs, a hundred small registers, I wouldn't mind either ).
Don't get me wrong. I love memory, lots of it, more if possible. But don't force me to do everything in 64 bit .
Wolfgang Reichl
|
|
|
|
|
I think Windows desperately needs it... just imagine installing 17,179,869,184GB (2^64 bits /1024/1024/1024 GB) or 16,777,216TB of RAM in your workstation. No more page file/virtual memory and all that needed. Yippee. Install 4 "simms" of 4096 Penta Bytes each and you set.
|
|
|
|
|
|
You've just finished the week long process of setting up your computer just how you like it when a building firm cuts through the mains power line outside your office. You sit watching, sweating, as the battery on the UPS slowly drains... the alarm starts beeping, the lights start getting dimmer and one by one the fans cut out. Finally with one last "whelp" the whole machine has gone.
I would rather have an instant hard drive failure than a slow, drawn-out death like that. I'm a big fan of torturing users so they know their place but even that is too cruel for them.
Die Freiheit spielt auf allen Geigen
|
|
|
|
|
|
Anonymous wrote:
16,777,216TB of RAM
It's much easier just to say 16EB (Exabytes).
Jeremy Falcon
|
|
|
|
|
|
Very interesting read, thanks for the links
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it! Honoured as one of The Most Helpful Members of 2004
|
|
|
|
|
|
wow, now a days i am so out of touch with computer technology (hardware), this is the first time i heard something called 64 bit memory address space availablity .
Well, since i didnt know that 64bit memory is in the market, so i dont know wheather i need it or not.;P
Support the police, bribe one today.
|
|
|
|
|
I believe 64 bit processors will have a 64 bit address bus which gives you 64 bits for representing an address. And all your registers become 64 bits too.
So it's pretty useful if you have a habit of using EAX to store your stuff all the time
Nish
|
|
|
|
|
I wouldn't say it's useless to store your stuff in EAX. EAX is still used (at least on the AMD 64-bit CPUs). It's like saying you can't use AX or AL/AH anymore because of EAX.
I think the biggest advantage of 64-bit CPUs, is that you're no longer limited to 4GB RAM. Which is excellent for servers and databases. If you calculate 2^64, and divide the result 3 times by 1024, you get 17.179.869.184 GB. I don't think we'll need more than that in the near future.
---
tommy online: http://users.telenet.be/tommycarlier
|
|
|
|
|
One big speed improvement of the x86-64 platform is that it supports more CPU registers.
There will be R7-R15 and that will make many push commands needless.
The RAM support for more than 4GB is not the most important thing for personal computers at the moment I think.
Don't try it, just do it! ![Wink | ;-)](https://www.codeproject.com/script/Forums/Images/smiley_wink.gif)
|
|
|
|
|
MS Office 2020 will probably require that much RAM.
|
|
|
|
|
Tommy Carlier wrote:
I don't think we'll need more than [17.179.869.184 GB] in the near future.
Ha! I will bet money* that if you installed MS Exchange Server on a machine with x amount of RAM and leave it for a few hours then you will find it using x-1 GB of it.
* do you take IOUs?
Die Freiheit spielt auf allen Geigen
|
|
|
|
|
Tommy Carlier wrote:
I think the biggest advantage of 64-bit CPUs, is that you're no longer limited to 4GB RAM. Which is excellent for servers and databases.
Gee, I ran out of RAM yesterday at 2.6Gb. There are other things besides servers and databases that use lotsa RAM. CAD is one of them. FEA is another. Both engineering applications.
|
|
|
|
|
Since return values of functions are stored mostly in the EAX register, wouldn't that make 64 bit memory address space usefull for everybody?
I also got the blogging virus..[^]
|
|
|
|
|
If AX is the 16-bit version and EAX is the 32-bit version, what are we supposed to call the 64-bit version by -- EEAX?
Jeremy Falcon
|
|
|
|
|
RAX
Don't try it, just do it! ![Wink | ;-)](https://www.codeproject.com/script/Forums/Images/smiley_wink.gif)
|
|
|
|
|
Maybe I'm slow today (it happens ), but is that the real label or a joke I didn't get?
Jeremy Falcon
|
|
|
|