Processor architecture
Is this very little necessary when you are dealing with large numbers? The current memory address space available for 64-bit is far superior to what any machine can handle for at least a few years ... and besides, this is probably more than any desktop will hold for quite some time ...
Yes, desktop memory will continue to grow, but 4 billion times what it is now? It will take a while ... of course we will get to 128-bit unless the entire current model is selected before that, which I see equally.
Also, it's worth noting that upgrading anything from 32-bit to 64-bit input right away in most scenarios results in a performance hit (this is the main reason Visual Studio 2010 remains 32-bit only). The same will happen with 64-bit and 128-bit. The smaller the objects you have, the more pointers, which are now twice as large , that more data needs to be traversed to do the same, especially if you don't need that much memory address space.
source to share
When we talk about n-bit architecture, we often combine two rather different things:
(1) n-bit addressing eg. CPU with 32-bit address registers and 32-bit address bus can address 4 GB of physical memory
(2) the size of internal CPU data paths and general registers, for example. a processor with a 32-bit internal architecture has 32-bit registers, 32-bit integer ALUs, 32-bit internal data paths, etc.
In many cases (1) and (2) are the same, but there are many exceptions and this can become more and more common, for example. we may not need more than 64-bit addressing for the foreseeable future, but we may want> 64 bits for registers and data paths (this already happens with many SIMD-enabled processors).
So, in short, you need to be careful when you say for example. "64-bit processor" - This can mean different things in different contexts.
source to share
Cost. Also, do you think you will get a 128 bit architecture? Implementing memory and so on, but to manage it efficiently needs higher bandwidth buses and basically some new instruction languages that handle it. 64-bit is more than enough for addressing (18446744073709551616 bytes).
Hard drives still have something to catch up with RAM and such. I think they will still be the bottleneck in IO. In addition, the newer chips simply support more cores rather than making significant changes to the language.
source to share
Well, I happen to be a professional computer architect (my inventions are probably in the computer you're reading this on) and while I haven't been paid to work on any processor over 64-bit yet, I know some of my friends who were.
And I've been playing around with 128-bit architectures for fun for decades.
those. this is already happening.
Actually, this has already happened to a limited extent. The HP Precision architecture, Intel Itanium, and higher versions of the IBM Power line have what I call stacked virtual memory. I have described this elsewhere, for example. see comp.arch posts for some details, http://groups.google.com/group/comp.arch/browse_thread/thread/53a7396f56860e17/f62404dd5782f309?lnk=gst&q=folded+virtual+memory#f62404dd5782f309
I need to create a wiki file compi-arch.net for them.
But you can get manuals for these processors and read them yourself.
eg. you can start with a 64-bit virtual user address. The top 8 bits can be used to index the region table, which returns the top 24 bits, which are combined with the remaining 64-8 = 56 bits to create an 80-bit extended virtual address. Which is then translated by TLB and page tables and hash lookups, as usual, to any of your physical addresses.
Why go from 64-> 80?
One of the reasons is the shared library. You may want the shared libraries to remain at the same extended virtual address across all processors so that you can share TLBs. But you may need to use your language tools to move them to different custom virtual addresses. Stacked virtual addresses allow this.
Folded virtual addresses are not true> 64-bit virtual addresses used by the user.
There are many suggestions for> 64 bit pointers in this regard: eg. I was working on where the pointer consisted of a 64-bit address and 64-bit lower and upper bounds and metadata, for a total of 128 bits. Checking boundaries. But, while they have> 64-bit pointers or capabilities, they are not really> 64-bit virtual addresses.
Linus reports 128-bit virtual addresses at http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=103574&threadid=103545&roomid=2
source to share
I would also like to suggest to a computer architect why 128bit is not practical at the moment:
-
Energy cost. See Bill Dally's presentations on how most of the energy in processors today is spent moving data around (dissipated in wires). However, since the most significant bits of a 128-bit computation should change slightly, it should mitigate this problem.
-
Most arithmetic operations have a non-linear size of the wrt operand:
and. The tree multiplier has a spatial complexity of n ^ 2, wrt is the number of bits.
b. The delay in the hierarchical carry looks like this: Log [n] wrt the number of bits (I think). Thus, a 128-bit adder will be slower than a 64-bit one. Can someone give some hard numbers (Log [n] seems very cheap)?
-
Few programs use 128 bit integers or even parity floating point numbers, and when they do, there are efficient ways to link them with 32 or 64 bit operations.
source to share
The next big thing in processor architecture will be quantum computing. Instead of just being 0 or 1, qbit has a chance of being 0 or 1.
This will lead to huge improvements in the performance of the algorithm (for example, it will be very easy to crack any RSA private / public key).
Check http://en.wikipedia.org/wiki/Quantum_computer for more information and see you 15 years from now; -)
source to share
The basic need for a 64-bit processor is to address more memory - and this is the driving force behind the 64-bit switch. On 32 bit systems you can really only access 4GB of RAM, at least the process. 4Gb is not much.
64 bits gives you a few petabytes of address space. (although many current 64-bit hardware can only address "48 bits" - that's still enough to support 256 terabytes of memory, though).
Increasing natural integer sizes for a processor does not automatically make it "better". There are trade-offs. With 128 bits, you'll need twice as much storage (registers / ram / caches / etc.) Compared to 64-bit for generic datatypes - with all the drawbacks it might have - more bar needed to store data, more data to transmissions = slower, wider buses may require more physical space / possibly more power, etc.
source to share