|
My customers have been wanting this for some time (most are working with memory footprints of 8-10GB and using Linux & other Unix boxes for the moment). However, in porting our SW to 64bit Windows, we found that even for small memory footprints the code runs about 30% faster. The prevailing thinking is that the increase in register count really cuts down on the number of memory accesses (even though many of our structures have much larger memory footprints now). Whatever the cause, our benchmarks still show significant improvement
over 32bit executables (using the same MS compiler).
|
|
|
|
|
Right now I am stuck to memory mapping a file no more than 1.9GB in size (unless of course you do /3GB, but having a customer do that is painful). 3+GB data files are not uncommon, and it would be great to be able to memory map them.
Drew
|
|
|
|
|
We have an application that's been using the AWE extensions for some time now. For lack of a better description, we use the 4Gb+ memory on these machines as bitmap buffers for print data. I can see where 64 bit address space might improve performance a bit. We've got custom hardware involved (DMA and all that), so I'm not sure.
Software Zen: delete this;
|
|
|
|
|
With a choice of 32 bit in front and after the decimal point (or 16:48, or ...) will you convert to fix-point numbers or stay with floats?
Wolfgang Reichl
|
|
|
|
|
64 bit integers don't buy you anything as far as general purpose real number arithmetic goes. The C/C++ float type is (usually) 32 bits, and a double is 64 bits.
BTW: 64 bit integer operations have been available in Intel/AMD CPU's for some time now; this thread is discussing the 64 bit address space support that's coming.
Software Zen: delete this;
|
|
|
|
|
<quote>
BTW: 64 bit integer operations have been available in Intel/AMD CPU's for some time now; this thread is discussing the 64 bit address space support that's coming.
<\quote>
Oh my god  ! So it's a bit off topic. But with 64 bit mem-space 64 bit arithmetic will be standard, supported with lots of registers, and fast.
<quote>
64 bit integers don't buy you anything as far as general purpose real number arithmetic goes. The C/C++ float type is (usually) 32 bits, and a double is 64 bits.
<\quote>
I meant fixed point arithmetic (I may have been more explicit about that). 32 bit fixed point arithetic was somewhat confined to special cases for its lack of dynamics. (e.g.I use fixed point arithmetic for angles, [0..0xff...ff] maps to [0 .. 0.9999...] interpreted as 0..360 degrees, and I get the modulo for free, plus fast table lookup when I need them (difficult with floats), cheap normalization, cheap conversions)
64 bit can be used for most any calculation used in common programming (you may want to exclude cosmo physicists trying to express the size of the universe in multiples of a superstring extent in the fifth dimension).
But you can now express any country's accumulated state deficit for the next ten years at milli-cent precision.
Fixed point arithmetic does have its advantages.
The question was:
Will anybody convert to fixed point because of 64 bits?
Wolfgang Reichl
|
|
|
|
|
I would stay with floats the FPU is pretty fast these days anyway. The main overhead is generally in saving the FPU state between threads but not all threads will be using it anyway.
The fixed point math has a problem in which precision is an issue. If you perhaps are writing a game and precision is not really that much of an issue it could be fine. However if you're dealing with finanical data, how much more speed would you attempt to gain? The FPU on the x86 is actually manipulating data using 80 bits of precision. While the storage is truncated to 64 bits (double) or 32 bits (float) which in the end loses some of this precision, operations that occur are able to use this extra space to be more accurate. Also, I would trust that IEEE has implemented a method of allowing for greater precision than you could simply using a fixed point notation.
My last arguement would be that since you physically have to go out of your way to implement fixed point, why not use an SIMD technology which allows you to perform floating point operations faster by processing multiple operations in a single instruction?
A note to the other post that says "64 bit has always been around" which is not nessecarily true. It's true in the same sense that 128 bit or 1024 bit has always been around. The compiler itself handles breaking up a 64 bit location and implementing operations as multiple instructions.
However, yes we have had an 80 bit FPU which did support 32 and 64 bit operations in a single instruction. The significance of 64 bit processor is the ability to process 64 bit integers and memory locations in a single instruction.
However, I believe that 64 bit address space will be extremely useful however, allowing kernel space to expand and user mode processes to expand their address spaces and allow us to make use of cheaper memory. Right now memory is a bottle neck with many applications, image a large database or multi-user server. They hit memory limiations and it would be a lot cheaper to throw some more RAM into a machine rather than buy more servers to get around this memory limitation.
|
|
|
|
|
some of my code is hardcoded to read a fixed lenght 32bit data. (i know i am lazy). i hope introduce 64bit one will not crack my program.
|
|
|
|
|
A thought experiment.
As an absolute upper bound, assume you could store one bit of RAM in a single silicon atom, without risk of losing data by stray cosmic rays. Also assume that no connections need to be made to the atoms, and there are no issues with heat dissipation, etc. (this is so unrealistic that the analysis remains valid when more than one bit can be stored per atom).
Then, based on the atomic radius, a memory chip to store 2^64 bytes would be a cube 0.2mm x 0.2mm x 0.2mm.
That is still small enough that it could fit inside a SIMM; but it wouldn't require many non-storage atoms to make it impossible to fit inside a conventional computer.
It won't happen in our lifetimes.
A chip to store 2^128 bytes would be (absolute lower bound) 600m x 600m x 600m.
The Star Trek computer on the Enterprise might have a 128 bit address bus, but it would not need a 256 bit address bus.
Somewhere around 512 or 1024 bits, you're exceeding the number of protons in the visible universe.
So, the next time address buses double, we will be in Star Trek territory. Of course, there are no limits on how wide a data bus can be.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
