Si dovrebbe conoscere l'architettura della macchina per scrivere il codice?

Question

Diciamo che sto programmando in Java o Python o C ++ per un semplice problema, potrebbe essere quello di costruire un server echo TCP / UDP o il calcolo fattoriale. Devo preoccuparmi dei dettagli dell'architettura, ovvero se è a 32 o 64 bit?

IMHO, a meno che non stia programmando qualcosa a che fare con cose di livello abbastanza basso, allora non devo preoccuparmi se è a 32 o 64 bit. Dove sto sbagliando? O ho ragione ???

Answer 1

corretto per la maggior parte delle circostanze

Il runtime / linguaggio / compilatore sottrarrà quei dettagli a meno che non si tratti direttamente di dimensioni delle parole o binario a basso livello.

Anche il byteorder viene estratto dallo stack NIC / Network nel kernel. È tradotto per te. Quando si programmano socket in C, a volte è necessario occuparsi dell'ordinamento dei byte per la rete quando si inviano dati ... ma ciò non riguarda le differenze a 32 o 64 bit.

Quando si ha a che fare con BLOB di dati binari, mapparli da un'architettura all'altra (come ad esempio una sovrapposizione a una struttura C) può causare problemi come altri hanno già detto, ma è per questo che sviluppiamo protocolli indipendenti dall'architettura basati su caratteri e così via.

In effetti cose come Java funzionano in una macchina virtuale che estrae la macchina un altro passo!

Conoscere un po ' il set di istruzioni dell'architettura e come viene compilata la sintassi che può aiutarti a capire la piattaforma e scrivere codice più pulito e più stretto. So di fare una smorfia ad un vecchio codice C dopo aver studiato i compilatori!

Answer 2

Sapere come funzionano le cose, sia come funziona la macchina virtuale e come funziona sulla tua piattaforma, o come alcuni costrutti C ++ vengono trasformati in assembly ti renderà sempre un programmatore migliore, perché capirai perché le cose dovrebbero essere fatte così come sono.

Devi sapere cose come la memoria per sapere quali sono i cache-mancati e perché potrebbero influenzare il tuo programma. Dovresti sapere come vengono implementate determinate cose, anche se potresti usare solo un'interfaccia o un modo di alto livello per raggiungerlo, sapendo come funziona assicurerai che lo stai facendo nel migliore dei modi.

Per il funzionamento dei pacchetti, è necessario comprendere il modo in cui i dati vengono archiviati su piattaforme e in che modo l'invio attraverso la rete a una piattaforma diversa potrebbe modificare la modalità di lettura dei dati (endian-ness).

Il tuo compilatore utilizzerà al meglio la piattaforma su cui stai compilando, quindi finché ti atterrai agli standard e al codice bene, puoi ignorare la maggior parte delle cose e presumere che il compilatore tirerà fuori ciò che è meglio.

Quindi in breve, no. Non è necessario conoscere le cose di basso livello, ma non fa mai male sapere .

Answer 3

L'ultima volta che ho visto le specifiche del linguaggio Java, conteneva un ridicolo gotcha nella sezione sulla boxe integer.

Integer a = 100;
Integer b = 100;

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

Questo è garantito per stampare true.

Integer a = 300;
Integer b = 300;

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

Non è garantito per la stampa <=>. Dipende dal tempo di esecuzione. Le specifiche lo hanno lasciato completamente aperto. È perché la boxe di un int tra -128 e 127 restituisce & Quot; interned & Quot; oggetti (analogo al modo in cui i letterali delle stringhe sono internati), ma l'implementatore del runtime della lingua è incoraggiato ad alzare quel limite se lo desiderano.

Personalmente lo considero una decisione folle e spero che da allora l'hanno risolto (scrivere una volta, correre ovunque?)

Answer 4

A volte devi preoccuparti.

Puoi essere sorpreso quando questi dettagli di basso livello saltano fuori improvvisamente e ti mordono. Ad esempio, Java standardizzato double è 64 bit. Tuttavia, JVM Linux utilizza il & Quot; estensione di precisione & Quot; modalità, quando il doppio è 80 bit finché è nel registro della CPU. Ciò significa che il seguente codice potrebbe non riuscire:

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

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

assert( y == x );

Semplicemente perché y viene forzato a uscire dal registro in memoria e troncato da 80 a 64 bit.

Answer 5

In Java and Python, architecture details are abstracted away so that it is in fact more or less impossible to write architecture-dependant code.

With C++, this is an entirely different matter - you can certainly write code that does not depend on architecture details, but you have be careful to avoid pitfalls, specifically concerning basic data types that are are architecture-dependant, such as int.

Answer 6

As long as you do things correctly, you almost never need to know for most languages. On many, you never need to know, as the language behavior doesn't vary (Java, for example, specifies the runtime behavior precisely).

In C++ and C, doing things correctly includes not making assumptions about int. Don't put pointers in int, and when you're doing anything with memory sizes or addresses use size_t and ptrdiff_t. Don't count on the size of data types: int must be at least 16 bits, almost always is 32, and may be 64 on some architectures. Don't assume that floating-point arithmetic will be done in exactly the same way on different machines (the IEEE standards have some leeway in them).

Pretty much all OSes that support networking will give you some way to deal with possible endianness problems. Use them. Use language facilities like isalpha() to classify characters, rather than arithmetic operations on characters (which might be something weird like EBCDIC). (Of course, it's now more usual to use wchar_t as character type, and use Unicode internally.)

Answer 7

If you are programming in Python or in Java, the interpreter and the virtual machine respectively abstract this layer of the architecture. You then need not to worry if it's running on a 32 or 64 bits architecture.

The same cannot be said for C++, in which you'll have to ask yourself sometimes if you are running on a 32 or 64 bits machine

Answer 8

You will need to care about "endian-ness" only if you send and receive raw C structs over the wire like

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

However this is not a recommended practice.

It's recommended that you define a protocol between the parties such it doesn't matter the parties' machine architectures.

Answer 9

In C++, you have to be very careful if you want to write code that works indifferently on 32 or 64 bits. Many people wrongly assume that int can store a pointer, for example.

Answer 10

With java and .net you don't really have to bother with it unless you are doing very low level stuff like twiddling bits. If you are using c, c++, fortran you might get by but I would actually recommend using things like "stdint.h" where you use definitive declares like uint64_t and uint32_t so as to be explicit. Also, you will need to build with particularly libraries depending on how you are linking, for example a 64 bit system might use gcc in a default 64 bit compile mode.

Answer 11

A 32 bit machine will allow you to have a maximum of 4 GB of addressable virtual memory. (In practice, it's even less than that, usually 2 GB or 3 GB depending on the OS and various linker options.) On a 64 bit machine, you can have a HUGE virtual address space (in any practical sense, limited only by disk) and a pretty damn big RAM.

So if you are expecting 6GB data sets for some computation (let's say something that needs incoherent access and can't just be streamed a bit at a time), on a 64 bit architecture you could just read it into RAM and do your stuff, whereas on a 32 bit architecture you need a fundamentally different way to approach it, since you simply do not have the option of keeping the entire data set resident.