Raspbian mudando para o modo de 64 bits

Em desta página , o anúncio oficial RPi3 afirma:

Você precisará de uma imagem NOOBS ou Raspbian recente em nossa página de downloads. No lançamento, estamos usando a mesma área de usuário Raspbian de 32 bits que usamos em outros dispositivos Raspberry Pi; nos próximos meses, investigaremos se há valor em mudar para o modo de 64 bits.

Minha pergunta é, dado que o processador é de 64 bits, não é óbvio que rodar o sistema operacional em 64 bits será melhor em todos os aspectos? o que estou perdendo?

dado que o processador é de 64 bits, não é óbvio que rodar o sistema operacional em 64 bits será melhor em todos os aspectos?

Não, na verdade não é. De certa forma, a execução de um sistema operacional de 64 bits pode deteriorar o desempenho do Raspberry Pi.

Benefícios de 64 bits :

Os dois principais benefícios do uso de um processador / sistema operacional de 64 bits é que o dispositivo pode lidar com mais de 4 GB de RAM e lidar com números inteiros maiores do que 2^32sem a necessidade de uma biblioteca de bignum.

O Raspberry Pi não possui mais de 4 GB de RAM. Com 1 GB de RAM, você perdeu completamente o primeiro dos dois principais benefícios. Quanto ao segundo benefício, que porcentagem de pessoas está realmente usando números gigantes suficientes para fazer sentido para a fundação suportar um segundo sistema operacional inteiro? Como é, o RPi pode usar grandes números por meio de métodos de software, mas parece que se você estiver consistentemente nesse domínio, precisará usar um hardware melhor de qualquer maneira.

Problemas com 64 bits :

A capacidade de armazenar um número maior não é garantida por mágica. Em vez disso, o tamanho dos objetos de memória precisa ser aumentado. Em C (e C ++), isso significa alterar um intpara int64_t. Isso não é feito automaticamente, portanto, os comentários sobre a fundação não desejam manter dois ramos.

Além disso, muitos aplicativos simplesmente não fornecem um benefício (para a maioria dos usuários) quando executados no modo de 64 bits. Observe que a maioria dos navegadores da Web, o MS Office e toda uma série de outros softwares populares ainda são enviados e mantidos de maneira 32 bits. Claro que você pode obter uma versão de 64 bits do MS Office, mas ela raramente é usada.

Se o aplicativo / sistema operacional for gravado para tirar proveito de uma arquitetura de 64 bits, seu aplicativo usará mais memória, simplesmente porque variáveis ​​e ponteiros estão ocupando mais espaço. Geralmente, essa é uma troca relativamente pequena de máquinas que se beneficiarão das vantagens. No nosso caso, temos muito poucas vantagens e muito pouca RAM.

Também de nota :

Só porque você está executando em uma máquina de 64 bits, não significa que o aplicativo não esteja executando em 32 bits. O Windows deixa isso bem claro, com dois caminhos de instalação diferentes, C:\Program Filese C:\Program Files (x86).

Então, a fundação provavelmente fornecerá suporte de 64 bits? :

Estamos de volta ao mesmo ponto de "Algumas pessoas podem ver benefícios, mas a maioria não vê". Você certamente verá outros projetos que oferecem compilações de 64 bits, mas, a menos que a fundação receba muito (imo) flack imerecido, eles provavelmente não irão e não devem (imo). Criar e manter um ramo separado de 64 bits não é um empreendimento pequeno e, honestamente, simplesmente não parece valer a pena.

Vale ressaltar que a situação é diferente para ARM e Intel / AMD. Isso ocorre porque a mudança para x86_64 também foi usada como uma oportunidade para atualizar a arquitetura antiga, basicamente prejudicada por ter apenas 8 registros de uso geral - e dobrou no modo de 64 bits. Portanto, mudar um sistema Intel / AMD para o modo de 64 bits também significa ativar recursos reais que fazem uma diferença significativa no desempenho.

O ARM não tem esse problema (embora o AArch64 adicione registradores, as arquiteturas de 32 bits não estavam famintas por eles), então os benefícios são basicamente mais memória endereçável diretamente e suporte inteiro grande nativo - muito menos negócio, e talvez neutralizado pela desvantagem (mais memória usada para tudo).

(Por outro lado, por esse motivo, houve algum trabalho na criação de uma abi "x32" para Intel / AMD Linux , mantendo os aprimoramentos da CPU, mas usando ponteiros de 32 bits.)

Tenho certeza de que já existem pessoas executando o Debian Aarch64 (ARMv8) no Pi 3; certamente não seria tão difícil para muitas pessoas ( veja aqui algumas dicas sobre o que pode funcionar) ^1, embora para a maioria dos usuários seja provavelmente um pouco exagerado.

No entanto, se o Raspbian e / ou a Foundation não lançarem uma versão de 64 bits, você verá cada vez mais pessoas com blogs etc., explicando como executar um e ainda obter os presentes necessários.

Agora existe uma versão do Fedora aarch64 para o Pi 3.

^{1. Haverá algumas complicações com o /opt/vcmaterial de 32 bits , não tenho certeza do quanto isso é superável; costumava haver bibliotecas compatíveis de 32 bits para x86-64, mas Aarch64 ... talvez não.}

Como parte da publicidade de lançamento, mencionei que uma preocupação é o esforço necessário para manter duas bases de código separadas (32 e 64 bits). o vídeo Adafruit PI3 Launch também mencionou que a mudança para um processador de 64 bits foi mais sobre a velocidade do clock que o novo chip fornecido do que sobre o modo de 64 bits.

O endereçamento de 64 bits pode ser útil mesmo se você não tiver mais de 1 GB de memória.

Permite mapear arquivos grandes na memória, para que você tenha um ponteiro e deixe o sistema operacional executar a E / S de forma transparente. Apenas outra maneira de fazer E / S. Você precisa de um endereçamento de 64 bits para fazer isso em arquivos grandes.

Outro exemplo em que vejo que pode ser útil é permitir que os processos tenham mais de 2 GB de espaço de endereço, usando espaço de troca. Recentemente, tive um problema em um NAS de 32 bits com muito armazenamento e um sistema de arquivos danificado. O processo fsck ficou sem memória, mesmo com as opções de cache ativadas. A adição de espaço de troca não conseguiu resolver o problema; o espaço de endereço de 32 bits era o limite rígido lá. Portanto, não havia como executar o fsck neste grande sistema de arquivos danificado com um binário de 32 bits. Com um binário de 64 bits e algum espaço de troca, ele seria executado.

Dirigindo-me à afirmação de que os programas nativos de 64 bits são maiores (mais memória para dados e ponteiros) e que não há benefícios perceptíveis para um SO de 64 x 32 bits no ARMv8 com menos de 4 GB de RAM, desejo aumentar alguns pontos.

Existem algumas diferenças significativas na maneira como as coisas são feitas no ARMv7 (e antes) e no ARMv8, arquitetonicamente, que tornam a execução do ARMv8 mais eficiente. Parte disso é proveniente dos caminhos de dados internos mais amplos, parte é a eliminação de casos especiais e um pipeline muito mais profundo). Essas mesmas alterações tornam o ARMv8 melhor na execução do código ARMv7 (32 bits).

Os aplicativos nativos de 64 bits usam ponteiros de 64 bits e 'size_t' é de 64 bits; portanto, os elementos que os utilizam ficam maiores. O restante dos dados tenderá a permanecer do mesmo tamanho. O significado disso é menor, no entanto, para o tamanho das imagens executáveis.

Onde o nativo de 64 bits realmente brilha (se você não se importa com grandes números inteiros e com ponto flutuante) está tendo um espaço de endereço virtual maior:

• O sistema operacional é capaz de dividir o espaço de endereço virtual em seções cada vez maiores, permitindo um gerenciamento mais fácil de recursos compartilhados, alternâncias de contexto mais simplificadas entre diferentes níveis de privilégios e assim por diante.
• Se você ativou a troca, pode executar processos cada vez maiores, excedendo os limites de memória física (isso também é verdade em 32 bits, mas você é menos limitado em 64 bits)

Se o SO atualmente tira vantagem disso ou não, isso fará a diferença à medida que o mainstream se afasta dos 32 bits.

Eu acho que o melhor argumento para mudar para um kernel AArch64 nativo de 64 bits é a portabilidade: a área de trabalho principal mudou-se para processadores principalmente de 64 bits, e estou vendo mais pacotes que assumem 64 bits e é mais difícil portar esse código de volta para 32 bits. do que portar de 32 a 64 bits. No espaço do usuário, você pode executar aplicativos de 32 bits e aplicativos de 64 bits lado a lado, supondo que você tenha instalado as bibliotecas de vários arcos; portanto, não é necessário portar de 32 a 64 bits, caso contrário importam. Um sistema operacional de 64 bits simplesmente oferece uma seleção maior de software.

Não estou dizendo que produzir um kernel de 64 bits para o Raspberry PI 3 é fácil - existem diferenças significativas que exigem alterações em um nível baixo, nem todos os drivers de dispositivo estão limpos em 64 bits (especialmente drivers para GPUs específicas para ARM). Pode ser que o Raspberian continue sendo um sistema operacional de 32 bits, mas acredito que (a longo prazo) ele míope.

Uma única mídia de inicialização (cartão SD, por exemplo) pode conter versões de 64 e 32 bits do sistema operacional, e o software de inicialização secundária (inicialização por u, inicialização por arm e outros) pode determinar qual carregar. A parte mais difícil é a terra do usuário - o sistema de arquivos teria que ser multi-arch, mesmo em sistemas de 32 bits onde o material de 64 bits será inútil. Eu abordaria isso com um script ou utilitário que poderia ser executado após a inicialização inicial para remover as bibliotecas e programas executáveis ​​desnecessários em sistemas apenas de 32 bits.

As respostas existentes cobrem muito bem os problemas de um arco de 64 bits, mas não estou vendo muitas vantagens declaradas da atualização. Então, aqui estão duas que eu descobri recentemente:

• Quando o PHP lida com registros de data e hora do Unix, o tamanho inteiro em um arco de 32 bits define um limite superior nas datas, de forma que eles não possam ir além de um dia específico em 2038 . Espero que esse seja um problema para todos os idiomas que lidam com carimbos de data e hora. (Felizmente, a maioria dos subsistemas de manipulação de data que não usam carimbos de data / hora Unix, como o DateTime do PHP, foram projetados especificamente para não serem limitados por esse problema, mesmo em CPUs mais antigas).

• O Mongo está limitado a bancos de dados com tamanho 2G neste arco, e as compilações de 32 bits serão preteridas em breve. Do manual :

  A partir do MongoDB 3.2, os binários de 32 bits foram descontinuados e ficarão indisponíveis em versões futuras.

  Embora as compilações de 32 bits existam para Linux e Windows, elas não são adequadas para implantações de produção. Compilações de 32 bits também não suportam o mecanismo de armazenamento WiredTiger.

Penso sobre isso: Embora eu não saiba exatamente como um processador ARM endereça a memória, posso dizer isso a partir de várias arquiteturas de CPU anteriores em que programei (SPARC / Alpha / i386 / AMD64 / X86_64): ao usar memória e endereçamento compartilhados pelo seu ponteiro de endereço virtual "real", a mudança para 64 bits não é trivial. Embora o memcpy faça o que deve ser feito, é necessário levar em consideração que em 64 bits os dados são armazenados assim (um pouco para trás):

HGFEDCBA
HGFEDCBA
HGFEDCBA

no entanto, em 32 bits, fica assim:

ABCD
ABCD
ABCD

Portanto, em 32 bits quando você armazena um jpeg na RAM, você pode ler os bytes do cabeçalho ou fazer a detecção de bordas, sem nenhum problema de maneira linear * digamos, avançando byte a byte. Mas em uma arquitetura de 64 bits, isso muda:

32bit:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64 bits:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}