+1

Foi justamente meu primeiro pensamento...

Realmente, o limite de 4 GB nos SOs 32 bits é técnica, devido ao PAE. Porém, acessar esta parte da memória acima dos 4 GB é mais lento. É algo semelhante ao que ocorria no DOS no modo real 8086. Para acessar mais memória, utilizava-se a EMS (que ficava acima dos 640 KB) e cujo acesso era mais lento.

Agora, nos 64 bits, o endereçamento é plano e, por isso, não precisa destas técnicas para acessar qualquer endereço neste limite de 16 EB. Portanto, é mais rápido.

Tinha escrito um texto muito grande e confuso como resposta, achei melhor fazer um "resumo":
1 - A taxa de transferência necessária para alimentar CPUs e GPUs cresce num ritmo maior que os outros dispositivos conseguem fornecer (dispositivos de E/S e memória RAM). Maneiras de diminuir o problema: paralelizar dispositivos. No caso de memória RAM, esquemas de dual, triple e quad channel são exemplos disso.
2 - No que se refere aos 614 GB, você está pegando o valor agregado de todo o sistema, não a taxa de transferência de um único link. As fabricantes têm o costume de somar as taxas de todos os links, no entanto, um link não ficou mais rápido, continua tendo, por exemplo: 51,2 GB/s nas duas direções no HT 3.1 em 32 bits, como você disse. 25,6 GB/s numa direção será insuficiente daqui um tempo. Pegue como exemplo as placas de vídeo, que, há tempos, têm mais capacidade de processamento paralelo que CPUs de propósito geral. Elas precisam de um banco de memória de 384, 512 bits para alimentar a GPU adequadamente. Só para se ter uma ideia, pegue os processadores da AMD da linha Fusion A10, eles têm uma GPU razoável, mas literalmente fica com fome. A DDR3 não dá conta do tranco de alimentar a CPU dual-core e a GPU.
3 - Uma possível solução seria aumentar ou a largura dos barramentos ou a frequência de operação (o clock). Contudo, você pode perceber que a um tempo estes não sobem tanto. Da mesma forma que a Intel chegou num limite de clock do Pentium 4, no que se refere a barramentos, é difícil criar barramentos largos e/ou com clock muito alto por causa (dentre outras coisas) do clock skew, além de ficar demasiadamente caro projetar uma placa-mãe que tivesse tal barramento.
4 - No que se refere à memória cache, você está certo em dizer que aumenta a complexidade de um sistema, mas eu creio que é mais barato você projetar um sistema com caches maiores do que barramentos externos de altíssima velocidade.
5 - O que eu vejo como solução, então, é ter um pool de memória local de velocidade mais alta que a memória RAM. Contudo, se fosse uma memória "independente", teria que alterar os softwares que rodariam neste sistema. Nisso, é melhor fazer com que ela aja como memória cache. Exemplo é uma variação do Haswell que se chama Cristalwell, que tem 128 MB de memória junto do processador. É um cache L4. Só de ter feito isso, fez com que a placa de vídeo integrada tivesse desempenho de uma GeForce da série 600 (esqueci o modelo correto). Eu creio que veremos chips de memória empilhados nos chips das placas de vídeo nos próximos anos. Pesquise, inclusive, sobre TSV (Through-Silicon Via).
PS: No caso do MacPro, ele até utiliza o QPI, mas não faz muito uso, pois não tem outro soquete. Podia ser até o DMI que eu creio que não seria problema para ele. O QPI neste caso é utilizado apenas para se ligar ao chipset da placa-mãe (o IOH), mas não tem nada ligado ao chipset que tem tamanha capacidade de transferência de dados.
PS2: Eu acho que por DMA você quis dizer DMI, não é? DMA é acesso direto à memória. O DMI é um barramento bem simples que foi criado pela Intel para ligar o extinto MCH (memory controller hub) ao IOH (I/O controller hub). Se não me falha a memória, é uma variação do PCI-e.
PS3: O PCI-e x16 3.0 (que é o utilizado pelas placas de vídeo) possui 128 Gbps de taxa, o que dá 15,75 GB/s. O 4.0 vai dobrar esta taxa. Ainda assim, não possui baixa latência como o QPI e o HT.
PS4: Os Intel Core possui apenas uma única controladora de memória e todos (GPU integrada, núcleos, cache L3, controladora PCI-e integrada e controladora de memória) são ligados num barramento em anel. No fim, os 12 núcleos do Intel Xeon que tem no MacPro está compartilhando um pool de memória. Para não deixar o processador com "fome", colocaram uma controladora quad-channel.

Pode ser ignorância minha, mas nunca ouvi falar de barramento que atinja 200 GB/s...

Os mais rápidos que já ouvi falar são o Intel QPI e o AMD Hypertransport, que são ponto-a-ponto (e, tecnicamente não são "barramentos" justamente por serem ponto-a-ponto, enfim....) e transferem 25,6 GB/s. Ainda por cima, são 25,6 GB/s de ida e volta, pois consegue transferir dados nos dois sentidos simultaneamente. É a mesma coisa que dizer que estou a 200 KM/h, quando, na verdade, estou a 100 KM/h e outro carro vem na minha direção a 100 KM/h.

Estes números altos eu só vi em duas situações: em largura de banda agregada, como em sistemas multi-socket e, nisso, eles pegam este 25,6 GB/s pela quantidade de links HT ou QPI no sistema ou em placas de vídeo que possuem memória GDDR5 com barramento de 256, 384 ou 512 bits, mas para barramentos de processador, eu nunca ouvi falar.

Bem, eu não acho que soluções dual-, triple- e quad-channel sejam gambiarras e, além do mais, creio que o futuro da computação (no médio prazo) está em empilhar pastilhas de memória RAM na CPU (ou na GPU, que seja) com largura de banda absurda, agindo como memória cache L4 ou L5. Empilhando, fica barato colocar memórias de 512, 1024 ou até quem sabe 2048 bits de largura de barramento. Põe 1 GB de RAM com 1024 bits de barramento e os computadores serão muito mais rápidos.

Aliás, vejo este empilhamento da RAM na CPU como a única alternativa, visto que é muito difícil e caro projetar um barramento de alta velocidade. Um dos problemas é o clock skew. Saímos das interfaces paralelas para seriais (como do IDE para SATA, PCI para PCIe) justamente por esta dificuldade. A gente terá barramentos paralelos entre chips empilhados (ou no mesmo substrato) e, saindo da CPU e da GPU, barramentos seriais.

Se não me engano, o XOne já vem com memória de alta velocidade junto do processador, para compensar a baixa capacidade da DDR3, que é usada como RAM. Creio que esteja agindo como cache. No PS4, usa-se a GDDR5 direto como memória RAM, que parece não ser apropriada para CPU, pois tem latência maior que a DDR3...

Mas diga aí Wallacy, eu talvez não saiba de alguma coisa nova por aí!

To no terceiro. Quem usa um computador com SSD, nunca mais volta pro HD para armazernar SO e programas...

Quanto ao Wine rodar no Nexus, não será possivel, pelo que sei. Ele so emula apenas a camada de sistema operacional, nao o conjunto de instrucoes. O Wine so funciona em Sistemas operacionais unix-like em processadores x86, como é o caso do Linux e do MacOS X.

Vem sim. Eh que agora ele fica no "fontes de software", alguma coisa assim. Sinceramente, nao sei o quê que tem a ver fontes de software com drivers de dispositivos....

Sim, cairia muito. ARM, por ora, já não possui desempenho dos x86 e ainda rodar aplicações emuladas... xii...

Eu me lembro de ter usado alguns applicativos para PowerPC durante a transição da Apple desta arquitetura para o x86. Os mac x86 eram mais potentes do que os PPC. Ainda assim, era perceptível a diferença entre um aplicativo nativo e outro emulado pelo Rosetta.

Nao adianta o hypervisor ser recompilado para ARM, se o SO convidado nao for feito para rodar em ARM. Nao vai funcionar. Quando envolve conjuntos de instrucoes diferentes, precisa de um emulador, nao apenas um virtualizador, como o colega disse acima.

Eu li n'outro site que o consumo de energia é basicamente o mesmo. Não vi diferença significante. Por outro lado, o desempenho subiu muito.

Tá acontecendo com os ARM o mesmo que aconteceu com os x86 uns tempos atrás: o desempenho subiu muito, mas, mais para frente, vai chegar no que se chama IPC wall, que já aconteceu com muitas famílias de processadores, incluindo os x86.