Why I dont think that 64 bit will be enough „for a long time“

At the moment, there seems to be a trend to managed code. Microsoft pushes its .NET-Framework, scientific and functional languages are built on top of the JVM, Apple developes LLVM. Not really surprising, since Runtime Speed and Memory is not really a bottleneck anymore in most cases, while there is a huge necessity for enhanced security, reusability, maintainability and portability of code.

Surprisingly enough that x86-based architectures are still spread around vitally all computers, even though for managed code a RISC-Architecture would be more convenient. But thats another story.

Meanwhile, the x86_64 architectures are spreadig, and seems that 32 bit architectures will be deprecated soon. That is a good thing. Anyway, one could already think of „x86_128“, an 128-bit-architecture. I have heard by many people till now, that 64 bit will be „enough for many years“. But actually, I dont see why.

Having a 128 bit bus size can get you double speed when handling huge amounts of data – which is one bottleneck, as far as I know. Mostly its not a problem to store data, or to work with it as soon as you have it, but its a problem to get it quickly from one place to the other.

Having more registers – a consequence of an 128 bit architecture, at least I hope so – is also a good thing. As far as I know, registers are still a lot faster than accessing the memory-cache. Algorithms for media compression or encryption often handle with many local values that are changed often, which can be perfectly optimized when having many registers. And garbage collectors can also profit from this, as far as I know.

Talking about garbage collectors, there is another way they – and memory management in general – can profit from. Having an adress-space that is much wider than the actual physical memory makes it possible to divide the memory into scopes of different purposes. You can divide it into struct-sizes, for example, or into object-spaces, etc., and therefore can distinguish objects according to the pointers on them (a strategy which is used for example in SBCL).

And I think also the increased complexity for the operating system managing multiple processor cores (which seems to be a trend, also) could also be accomplished in a better way.

So I dont really think that something like „x86_128“ will not evolve and spread in the next 10 years, even for consumer-pcs.

2 Antworten zu Why I dont think that 64 bit will be enough „for a long time“

  1. I don’t disagree with your overall statement, but here are some comments on things you wrote:

    /Having a 128 bit bus size can get you double speed when handling huge amounts of data – which is one bottleneck, as far as I know. Mostly its not a problem to store data, or to work with it as soon as you have it, but its a problem to get it quickly from one place to the other./

    This is true but not necessarily a problem any more. We have SIMD instructions.

    /Having more registers – a consequence of an 128 bit architecture, at least I hope so – is also a good thing./

    It’s true that the x86_64 has more registers compared to its 32 bit companion. But why do you think the number of registers is related to their width?

    /You can divide it into struct-sizes, for example, or into object-spaces, etc., and therefore can distinguish objects according to the pointers on them (a strategy which is used for example in SBCL)./

    No. SBCL stores the type of objects either in a portion of their value (e.g. fixnums) or in a memory box (e.g. floats, objects).

    /And I think also the increased complexity for the operating system managing multiple processor cores (which seems to be a trend, also) could also be accomplished in a better way./

    How would a processor with wider registers provide parallel execution of task (and thus a 2x speed-up in the ideal case)?

    Leslie

  2. dasuxullebt sagt:

    Hm. Well, I am not an expert, thats why I often use the term „I think“.

    @SIMD: Honestly, I heard of the concept „SIMD“, but didnt really know it. And still, there are algorithms which cannot profit from that. And still, most algorithms profit from more registers. Putting local variables in registers, for example. Or putting function arguments into registers (fastcalling).

    @Registers: As far as I know, registers can always be separated in High- and Low-Parts. You can use a 32 bit register as 4 one-byte-registers. So at least with larger registers you will get twice as much registers of the old width. On the other hand, as far as I know – but as I said I am not an expert – the complexity of accessing multiple registers is somehow related to the word-length of the processor, and so, if you have 128 bit, it doesnt cost you really more to put more registers into the processor, which is afaik the reason why always the number of registers increased with architectures with a wider bus-width.

    @SBCL: I thought the first 2 bits of a pointer indicates their type somehow. But seems like you are right. I was mistaken.

    @multicore: A processor with wider registers couldnt provide parallel execution. What I meant was, if you have multiple cores, it is more complicated for the operating system to manage them. Having wider registers to save state-information could make that easier.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: