Será que um tem que saber a arquitetura da máquina de escrever código?

Question

Vamos dizer que eu estou programando em Java ou Python ou C ++ para um problema simples, poderia ser a construção de um servidor TCP / UDP echo ou cálculo do fatorial. Eu tenho que se preocupar com os detalhes da arquitetura, ou seja, se é 32 ou 64 bits?

IMHO, a menos que eu estou programando algo a ver com bastante material de baixo nível, então eu não ter que se preocupar se o seu 32 ou 64 bits. Onde eu estou errando? Ou eu sou correto ???

Answer 1

correto para a maioria das circunstâncias

O tempo de execução / idioma / compilador abstrato esses detalhes, a menos que você está lidando diretamente com tamanhos de texto ou binário em um nível baixo.

Mesmo byteorder é captada pela pilha NIC / rede no kernel. É traduzida para você. Ao programar tomadas em C, você às vezes tem que lidar com ordenação de bytes para a rede ao enviar dados ... mas isso não diz respeito a 32 ou 64 diferenças bits.

Ao lidar com bolhas de dados binários, mapeando-os de uma arquitetura para outra (como uma sobreposição a um struct C, por exemplo) pode causar problemas como os outros, mas é por isso que nós desenvolvemos arquitetura protocolos independentes baseados em personagens e assim por diante.

No fato-coisas como correr Java em uma máquina virtual que Abstracts da máquina mais um passo!

Conhecendo um pouco sobre o conjunto de instruções da arquitetura, e como a sintaxe é compilado para que podem ajudar você a entender a plataforma e gravação mais limpa, código mais apertado. Eu sei que eu careta em algum código C de idade, depois de estudar compiladores!

Answer 2

Sabendo como as coisas funcionam, seja como funciona a máquina virtual, e como ele funciona em sua plataforma, ou como certas C ++ construções são transformadas em conjunto sempre vai fazer você um programador melhor, porque você vai entender por que as coisas devem ser feitas do jeito que são.

Você precisa entender coisas como a memória para saber o que de cache-acidentes são e por aqueles que podem afetar seu programa. Você deve saber como certas coisas são implementadas, mesmo que você só pode usar uma forma de interface ou de alto nível para chegar a ela, sabendo como funciona irá certificar-se que você está fazendo isso da melhor maneira.

Para o trabalho de pacotes, você precisa entender como os dados são armazenados em plataformas e como o envio de que através da rede para uma plataforma diferente pode mudar a forma como os dados são lidos (endian-ness).

O seu compilador irá fazer o melhor uso da plataforma que você está compilando em, por isso, enquanto você ficar com normas e código bem, você pode ignorar a maioria das coisas e assumir o compilador irá sacar o que é melhor.

Assim, em breve, não. Você não precisa saber as coisas de baixo nível, mas nunca é demais saber .

Answer 3

A última vez que olhei para a especificação da linguagem Java, que continha uma pegadinha ridículo na seção sobre boxe inteiro.

Integer a = 100;
Integer b = 100;

System.out.println(a == b);

Isso é garantido para imprimir true.

Integer a = 300;
Integer b = 300;

System.out.println(a == b);

Isso não é garantido para imprimir true. Depende do tempo de execução. A especificação deixou completamente aberto. É porque o boxe um int entre -128 e 127 retornos "internado" objetos (semelhante à forma como strings literais estão internados), mas o implementador do tempo de execução linguagem é incentivado a elevar esse limite se o desejarem.

Eu, pessoalmente, considero isso como uma decisão insana, e espero que eles fixa-lo uma vez que (write once, run anywhere?)

Answer 4

Às vezes você deve se preocupar.

Você pode ser surpreendido quando estes detalhes de baixo nível, de repente saltar e mordê-lo. Por exemplo, Java padronizado double a ser de 64 bits. No entanto, Linux JVM usa o modo "estendido precisão", quando o casal é de 80 bit, enquanto ele está no registro CPU. Isto significa que o seguinte código pode falhar:

double x = fun1();
double y = x;

System.out.println(fun2(x));

assert( y == x );

Simplesmente porque y é forçado a sair do registo na memória e truncado de 80 para 64 bits.

Answer 5

Em Java e Python, arquitetura detalhes são abstraídos de modo que é na verdade mais ou menos impossível código dependente de arquitetura de escrita.

Com C ++, este é um assunto completamente diferente - você pode código certamente gravação que não depende de detalhes da arquitetura, mas você tem o cuidado de evitar armadilhas, especificamente sobre os tipos de dados básicos que são todos dependentes da arquitetura, como int .

Answer 6

Enquanto você faz as coisas corretamente, você quase nunca precisa saber para a maioria dos idiomas. Em muitos, você nunca precisa saber, como o comportamento linguagem não varia (Java, por exemplo, especifica o comportamento de tempo de execução precisamente).

Em C ++ e C, fazendo as coisas corretamente inclui não fazer suposições sobre int. Faça ponteiros não colocar em int, e quando você está fazendo qualquer coisa com tamanhos de memória ou endereços usar size_t e ptrdiff_t. Não conte com o tamanho dos tipos de dados: int deve ser de pelo menos 16 bits, quase sempre é de 32, e pode ser de 64 em algumas arquiteturas. Não presuma que aritmética de ponto flutuante será feito exatamente da mesma maneira em máquinas diferentes (os padrões IEEE tem alguma margem de manobra neles).

Praticamente todos os sistemas operacionais que suporte de rede vai lhe dar alguma maneira de lidar com possíveis problemas endianness. Usa-os. Use serviços linguísticos como isalpha () para caracteres classificar, em vez de operações aritméticas em caracteres (que pode ser algo estranho como EBCDIC). (Claro, agora é mais usual usar wchar_t como tipo de personagem, e usar Unicode internamente.)

Answer 7

Se você estiver programando em Python ou Java, o intérprete ea máquina virtual respectivamente abstrato esta camada da arquitetura. então você não precisa se preocupar se ele está sendo executado em uma arquitetura de 32 ou 64 bits.

Não é o mesmo pode ser dito para C ++, no qual você vai ter que perguntar a si mesmo, por vezes, se você estiver executando em uma máquina de 32 ou 64 bits

Answer 8

Você vai precisar se preocupar com "endian-ness" somente se você enviar e receber estruturas C-primas sobre o fio como

ret = send(socket, &myStruct, sizeof(myStruct));

No entanto, esta não é uma prática recomendada.

É recomendável que você definir um protocolo entre as partes, tal não importa das partes da máquina arquiteturas.

Answer 9

Em C ++, você tem que ter muito cuidado se você quiser escrever código que funciona com indiferença em 32 ou 64 bits. Muitas pessoas, erradamente, que int pode armazenar um ponteiro, por exemplo.

Answer 10

Com java e .net você realmente não tem que se preocupar com ele, a menos que você está fazendo coisas muito baixo nível como pedaços girando. Se você estiver usando C, C ++, Fortran que você pode obter por mas eu realmente recomendo usar coisas como "stdint.h" onde você usa definitiva declara como uint64_t e uint32_t de modo a ser explícito. Além disso, você vai precisar para construir com nomeadamente as bibliotecas, dependendo de como você está ligando, por exemplo, um sistema de 64 bits pode usar gcc em um modo padrão de 64 bits de compilação.

Answer 11

A máquina de 32 bits permitirá que você ter um máximo de 4 GB de memória virtual endereçável. (Na prática, é ainda menos do que isso, geralmente 2 GB ou 3 GB, dependendo das opções de vinculador do sistema operacional e vários.) Em uma máquina de 64 bits, você pode ter um enorme espaço virtual endereço (em qualquer sentido prático, limitado apenas pela disco ) e um muito muito grande RAM.

Então, se você está esperando conjuntos de dados 6GB por algum computação (digamos algo que precisa de acesso incoerente e não pode simplesmente ser transmitido um pouco de cada vez), em uma arquitetura de 64 bits você poderia apenas lê-lo na memória RAM e fazer seu material, enquanto que em uma arquitetura de 32 bits, você precisa de uma forma fundamentalmente diferente de abordá-lo, desde que você simplesmente não têm a opção de manter todo o residente conjunto de dados.