Perché Java ha primitive per numeri di dimensioni diverse?

In Java esistono tipi primitivi per byte, short, inte longla stessa cosa per la floate double. Perché è necessario impostare una persona su quanti byte utilizzare per un valore di base? La dimensione non potrebbe essere determinata dinamicamente a seconda della grandezza del numero trasmesso?

Ci sono 2 motivi a cui posso pensare:

1. L'impostazione dinamica della dimensione dei dati significherebbe che dovrebbe essere in grado di cambiare anche dinamicamente. Ciò potrebbe potenzialmente causare problemi di prestazioni?
2. Forse il programmatore non vorrebbe che qualcuno fosse in grado di usare un numero maggiore di una certa dimensione e questo gli consente di limitarlo.

Penso ancora che ci sarebbe stato molto da guadagnare semplicemente usando un singolo inte un floattipo, c'era un motivo specifico per cui Java ha deciso di non seguire questa strada?

Come molti aspetti del design del linguaggio, si tratta di un compromesso tra eleganza e performance (per non parlare dell'influenza storica delle lingue precedenti).

alternative

È certamente possibile (e abbastanza semplice) creare un linguaggio di programmazione che ha un solo tipo di numeri naturali nat. Quasi tutti i linguaggi di programmazione utilizzati per lo studio accademico (ad esempio PCF, Sistema F) hanno questo tipo di numero singolo, che è la soluzione più elegante, come hai immaginato. Ma il design del linguaggio in pratica non riguarda solo l'eleganza; dobbiamo anche considerare le prestazioni (la misura in cui le prestazioni sono considerate dipende dall'applicazione prevista della lingua). Le prestazioni comprendono vincoli di tempo e spazio.

Vincoli di spazio

Consentire al programmatore di scegliere il numero di byte in anticipo può risparmiare spazio nei programmi con memoria limitata. Se tutti i tuoi numeri saranno inferiori a 256, puoi usare 8 volte il numero di bytesecondi longo utilizzare la memoria salvata per oggetti più complessi. Lo sviluppatore di applicazioni Java standard non deve preoccuparsi di questi vincoli, ma si presentano.

Efficienza

Anche se ignoriamo lo spazio, siamo ancora vincolati dalla CPU, che ha solo istruzioni che operano su un numero fisso di byte (8 byte su un'architettura a 64 bit). Ciò significa che anche fornire un singolo tipo di 8 byte longrenderebbe l'implementazione del linguaggio significativamente più semplice rispetto ad avere un tipo di numero naturale illimitato, essendo in grado di mappare le operazioni aritmetiche direttamente su una singola CPU sottostante. Se si consente al programmatore di utilizzare numeri arbitrariamente grandi, una singola operazione aritmetica deve essere mappata su una sequenza di istruzioni complesse della macchina, che rallenterebbe il programma. Questo è il punto (1) che hai sollevato.

Tipi a virgola mobile

La discussione finora ha riguardato solo numeri interi. I tipi a virgola mobile sono una bestia complessa, con semantica e casi limite estremamente sottili. Così, anche se si potrebbe facilmente sostituire int, long, short, e bytecon un unico nattipo, non è chiaro quale sia il tipo di numeri a virgola mobile ancora è . Non sono numeri reali, ovviamente, poiché i numeri reali non possono esistere in un linguaggio di programmazione. Non sono nemmeno numeri abbastanza razionali (anche se è semplice creare un tipo razionale se lo si desidera). Fondamentalmente, IEEE ha deciso un modo per fare una sorta di numeri reali approssimativi, e da allora tutti i linguaggi (e programmatori) sono rimasti bloccati.

Infine:

Forse il programmatore non vorrebbe che qualcuno fosse in grado di usare un numero maggiore di una certa dimensione e questo gli consente di limitarlo.

Questo non è un motivo valido. In primo luogo, non riesco a pensare a situazioni in cui i tipi potrebbero codificare naturalmente i limiti numerici, per non parlare delle probabilità che sono astronomicamente basse che i limiti che il programmatore vuole far rispettare corrisponderebbero esattamente alle dimensioni di qualsiasi tipo primitivo.

Il motivo è molto semplice: efficienza . In più modi.

1. Tipi di dati nativi: più i tipi di dati di una lingua si avvicinano ai tipi di dati sottostanti dell'hardware, più efficiente è la lingua considerata. (Non nel senso che i tuoi programmi saranno necessariamente efficienti, ma nel senso che potresti, se sai davvero cosa stai facendo, scrivere codice che funzionerà in modo efficiente quanto l'hardware può eseguirlo.) I tipi di dati offerti da Java corrispondono a byte, parole, doppie parole e quaderni dell'hardware più popolare in circolazione. Questo è il modo più efficiente di andare.

2. Sovraccarico ingiustificato su sistemi a 32 bit: se fosse stata presa la decisione di mappare tutto su una lunghezza a 64 bit di dimensioni fisse, ciò avrebbe imposto un'enorme penalità alle architetture a 32 bit che necessitavano di molti più cicli di clock per eseguire un 64- operazione a bit rispetto a un'operazione a 32 bit.

3. Perdita di memoria: c'è un sacco di hardware là fuori che non è troppo esigente per l'allineamento della memoria (le architetture Intel x86 e x64 ne sono esempi), quindi un array di 100 byte su quell'hardware può occupare solo 100 byte di memoria. Tuttavia, se non si dispone più di un byte e si deve utilizzare un valore long, lo stesso array occuperà un ordine di grandezza in più di memoria. E gli array di byte sono molto comuni.

4. Calcolo delle dimensioni dei numeri: la tua idea di determinare dinamicamente le dimensioni di un numero intero in base alla dimensione del numero passato è troppo semplicistica; non esiste un singolo punto per "passare" un numero; il calcolo di quanto deve essere grande un numero deve essere eseguito in fase di esecuzione, su ogni singola operazione che può richiedere un risultato di dimensioni maggiori: ogni volta che si incrementa un numero, ogni volta che si aggiungono due numeri, ogni volta che si moltiplicano due numeri, ecc.

5. Operazioni su numeri di dimensioni diverse: Successivamente, avere numeri di dimensioni potenzialmente diverse fluttuanti nella memoria complicherebbe tutte le operazioni: anche per confrontare semplicemente due numeri, il runtime dovrebbe prima verificare se entrambi i numeri da confrontare sono uguali dimensione e, in caso contrario, ridimensionare quella più piccola in modo che corrisponda alla dimensione di quella più grande.

6. Operazioni che richiedono dimensioni specifiche dell'operando: alcune operazioni bit per bit si basano sull'intero che ha una dimensione specifica. Non avendo dimensioni specifiche predeterminate, queste operazioni dovrebbero essere emulate.

7. Sovraccarico del polimorfismo: la modifica della dimensione di un numero in fase di esecuzione significa essenzialmente che deve essere polimorfico. Questo a sua volta significa che non può essere una primitiva di dimensioni fisse allocata nello stack, deve essere un oggetto, allocata nell'heap. Questo è terribilmente inefficiente. (Rileggi il numero 1 sopra.)

Per evitare di ripetere i punti discussi in altre risposte, cercherò invece di delineare più prospettive.

Dal punto di vista del design linguistico

• È certamente possibile progettare e implementare un linguaggio di programmazione e il suo ambiente di esecuzione che accolgano automaticamente i risultati delle operazioni di numeri interi che non si adattano alla larghezza della macchina.
• È la scelta del progettista del linguaggio se fare in modo che tali numeri interi di larghezza dinamica siano il tipo intero predefinito per questo linguaggio.
• Tuttavia, il progettista della lingua deve considerare i seguenti svantaggi:
  • La CPU dovrà eseguire più codice, il che richiede più tempo. Tuttavia, è possibile ottimizzare per il caso più frequente in cui l'intero si adatta a una singola parola macchina. Vedi rappresentazione puntatore con tag .
  • La dimensione di quell'intero diventa dinamica.
  • La lettura di un numero intero a larghezza dinamica dalla memoria può richiedere più di un viaggio.
  • Le strutture (oggetti) e le matrici che contengono numeri interi di larghezza dinamica all'interno dei loro campi / elementi avranno una dimensione totale (occupata) che è anche dinamica.

Ragioni storiche

Questo è già stato discusso nell'articolo di Wikipedia sulla storia di Java, ed è anche brevemente discusso nella risposta di Marco13 .

Vorrei sottolineare che:

• I progettisti linguistici devono destreggiarsi tra un'estetica e una mentalità pragmatica. La mentalità estetica vuole progettare un linguaggio che non sia soggetto a problemi noti, come traboccamenti di numeri interi. La mentalità pragmatica ricorda al progettista che il linguaggio di programmazione deve essere abbastanza buono per implementare utili applicazioni software e per interagire con altre parti software che sono implementate in linguaggi diversi.
• I linguaggi di programmazione che intendono acquisire quote di mercato dai vecchi linguaggi di programmazione potrebbero essere più propensi a essere pragmatici. Una possibile conseguenza è che sono più disposti a incorporare o prendere in prestito costrutti e stili di programmazione esistenti da quelle lingue più vecchie.

Ragioni di efficienza

Quando conta l'efficienza?

• Quando si intende pubblicizzare un linguaggio di programmazione adatto allo sviluppo di applicazioni su larga scala.
• Quando devi lavorare su milioni e miliardi di piccoli oggetti, in cui si aggiunge ogni bit di efficienza.
• Quando devi competere con un altro linguaggio di programmazione, il tuo linguaggio deve funzionare decentemente - non deve essere il migliore, ma sicuramente aiuta a rimanere vicino alle migliori prestazioni.

Efficienza di archiviazione (in memoria o su disco)

• La memoria del computer era una volta una risorsa scarsa. Ai vecchi tempi, la dimensione dei dati dell'applicazione che potevano essere elaborati da un computer era limitata dalla quantità di memoria del computer, sebbene ciò potesse probabilmente essere aggirato usando una programmazione intelligente (che costerebbe di più da implementare).

Efficienza di esecuzione (all'interno della CPU o tra CPU e memoria)

• Già discusso nella risposta di gardenhead .
• Se un programma deve elaborare array molto grandi di piccoli numeri memorizzati consecutivamente, l'efficienza della rappresentazione in memoria ha un effetto diretto sulle sue prestazioni di esecuzione, poiché la grande quantità di dati fa sì che il throughput tra CPU e memoria diventi un collo di bottiglia. In questo caso, impacchettare i dati in modo più denso significa che un singolo recupero della riga della cache può recuperare più pezzi di dati.
• Tuttavia, questo ragionamento non si applica se i dati non vengono archiviati o elaborati consecutivamente.

La necessità che i linguaggi di programmazione forniscano un'astrazione per piccoli numeri interi, anche se limitati a contesti specifici

• Queste esigenze sorgono spesso nello sviluppo di librerie software, comprese le librerie standard del linguaggio. Di seguito sono riportati alcuni di questi casi.

interoperabilità

• Spesso, i linguaggi di programmazione di livello superiore devono interagire con il sistema operativo o pezzi di software (librerie) scritti in altri linguaggi di livello inferiore. Questi linguaggi di livello inferiore spesso comunicano usando "struct" , che è una specifica rigida del layout di memoria di un record costituito da campi di diversi tipi.
• Ad esempio, potrebbe essere necessario che una lingua di livello superiore specifichi che una determinata funzione esterna accetta un chararray di dimensioni 256. (Esempio.)
• Alcune astrazioni utilizzate dai sistemi operativi e dai file system richiedono l'uso di flussi di byte.
• Alcuni linguaggi di programmazione scelgono di fornire funzioni di utilità (ad esempio BitConverter) per aiutare l'imballaggio e il disimballaggio di interi stretti in flussi di bit e flussi di byte.
• In questi casi, i tipi interi più stretti non devono necessariamente essere un tipo primitivo incorporato nel linguaggio. Al contrario, possono essere forniti come tipo di libreria.

Gestione delle stringhe

• Esistono applicazioni i cui principali scopi di progettazione sono manipolare le stringhe. Pertanto, l'efficienza della gestione delle stringhe è importante per questi tipi di applicazioni.

Gestione del formato file

• Molti formati di file sono stati progettati con una mentalità simile al C. Come tale, era prevalente l'uso di campi di larghezza ridotta.

Desiderabilità, qualità del software e responsabilità del programmatore

• Per molti tipi di applicazioni, l'allargamento automatico degli interi non è in realtà una caratteristica desiderabile. Né è saturazione né avvolgimento (modulo).
• Molti tipi di applicazioni trarranno vantaggio dalla specifica esplicita del programmatore dei più grandi valori consentiti in vari punti critici del software, come a livello di API.

Considera il seguente scenario.

• Un'API software accetta una richiesta JSON. La richiesta contiene una matrice di richieste figlio. L'intera richiesta JSON può essere compressa con l'algoritmo Deflate.
• Un utente malintenzionato crea una richiesta JSON contenente un miliardo di richieste figlio. Tutte le richieste figlio sono identiche; l'utente malintenzionato intende che il sistema masterizzi alcuni cicli della CPU facendo un lavoro inutile. A causa della compressione, queste richieste figlio identiche vengono compresse in dimensioni totali molto ridotte.
• È ovvio che un limite predefinito sulla dimensione compressa dei dati non è sufficiente. Invece, l'API deve imporre un limite predefinito al numero di richieste figlio che possono essere contenute in esso e / o un limite predefinito alla dimensione sgonfia dei dati.

Spesso, un software in grado di scalare in sicurezza molti ordini di grandezza deve essere progettato a tale scopo, con crescente complessità. Non viene automaticamente anche se il problema di overflow dei numeri interi viene eliminato. Questo arriva a un cerchio completo che risponde alla prospettiva di progettazione del linguaggio: spesso, il software che rifiuta di eseguire un lavoro quando si verifica un overflow di numeri interi non intenzionale (generando un errore o un'eccezione) è meglio del software che si conforma automaticamente a operazioni astronomiche di grandi dimensioni.

Ciò significa che la prospettiva del PO,

Perché è necessario impostare una persona su quanti byte utilizzare per un valore di base?

non è corretto. Al programmatore dovrebbe essere permesso, e talvolta richiesto, di specificare la grandezza massima che può assumere un valore intero, nelle parti critiche del software. Come sottolinea la risposta di gardenhead , i limiti naturali imposti dai tipi primitivi non sono utili a questo scopo; la lingua deve fornire ai programmatori modi per dichiarare la grandezza e applicare tali limiti.

Tutto viene dall'hardware.

Un byte è la più piccola unità di memoria indirizzabile sulla maggior parte dell'hardware.

Ogni tipo che hai appena citato è costruito da alcuni multipli di byte.

Un byte è 8 bit. Con ciò potresti esprimere 8 booleani ma non puoi cercare solo uno alla volta. Indirizzo 1, indirizzo a tutti 8.

Ed era così semplice, ma poi siamo passati da un bus a 8 bit a un bus a 16, 32 e ora a 64 bit.

Ciò significa che mentre possiamo ancora indirizzarci a livello di byte, non possiamo più recuperare un singolo byte dalla memoria senza ottenere i byte vicini.

Di fronte a questo hardware, i progettisti del linguaggio hanno scelto di permetterci di scegliere i tipi che ci hanno permesso di scegliere i tipi che si adattano all'hardware.

Puoi affermare che un tale dettaglio può e deve essere sottratto soprattutto in un linguaggio che mira a funzionare su qualsiasi hardware. Ciò avrebbe problemi di prestazioni nascosti ma potresti avere ragione. Non è successo in quel modo.

Java in realtà cerca di farlo. I byte vengono automaticamente promossi in Ints. Un fatto che ti farà impazzire la prima volta che provi a fare qualche serio lavoro di spostamento.

Quindi perché non ha funzionato bene?

Il grande punto di forza di Java nel passato era che si poteva sedere con un noto algoritmo C, digitarlo in Java e con lievi modifiche avrebbe funzionato. E C è molto vicino all'hardware.

Mantenere quella dimensione e sottrarre dimensioni ai tipi integrali non ha funzionato insieme.

Quindi avrebbero potuto. Semplicemente no.

Forse il programmatore non vorrebbe che qualcuno fosse in grado di usare un numero maggiore di una certa dimensione e questo gli consente di limitarlo.

Questo è un pensiero valido. Ci sono metodi per farlo. La funzione di bloccaggio per uno. Una lingua potrebbe arrivare al punto di creare limiti arbitrari nei loro tipi. E quando quei limiti sono noti al momento della compilazione, ciò consentirebbe l'ottimizzazione del modo in cui quei numeri sono memorizzati.

Java non è proprio quella lingua.

Probabilmente, un motivo importante per cui questi tipi esistono in Java è semplice e angosciantemente non tecnico:

Anche C e C ++ avevano questi tipi!

Sebbene sia difficile fornire una prova del fatto che questo sia il motivo, esistono almeno alcune prove concrete: The Oak Language Specification (Versione 0.2) contiene il seguente passaggio:

3.1 Tipi di numeri interi

I numeri interi nel linguaggio Oak sono simili a quelli in C e C ++, con due eccezioni: tutti i tipi di numeri interi sono indipendenti dalla macchina e alcune definizioni tradizionali sono state modificate per riflettere i cambiamenti nel mondo da quando è stata introdotta la C. I quattro tipi interi hanno larghezze di 8, 16, 32 e 64 bit e sono firmati a meno che non siano prefissati dal unsignedmodificatore.

Quindi la domanda potrebbe ridursi a:

Perché sono stati inventati short, int e long in C?

Non sono sicuro che la risposta alla domanda sulla lettera sia soddisfacente nel contesto della domanda che è stata posta qui. Ma in combinazione con le altre risposte qui, potrebbe essere chiaro che può essere utile avere questi tipi (indipendentemente dal fatto che la loro esistenza in Java sia solo un lascito di C / C ++).

Le ragioni più importanti che mi vengono in mente sono

• Un byte è la più piccola unità di memoria indirizzabile (come già menzionato CandiedOrange). A byteè il blocco elementare di dati che può essere letto da un file o sulla rete. Alcuni rappresentazione esplicita di questo dovrebbe esistere (ed esiste nella maggior parte delle lingue, anche quando si tratta a volte sotto mentite spoglie).

• È vero che, in pratica, avrebbe senso rappresentare tutti i campi e le variabili locali usando un solo tipo e chiamarlo int. C'è una domanda correlata a riguardo su StackOverflow: Perché l'API Java utilizza int anziché short o byte? . Come ho già detto nella mia risposta, una giustificazione per avere i tipi più piccoli ( bytee short) è che è possibile creare array di questi tipi: Java ha una rappresentazione di array che è ancora piuttosto "vicina all'hardware". A differenza di altri linguaggi (e in contrasto con le matrici di oggetti, come una Integer[n]matrice), una int[n]matrice non è una raccolta di riferimenti in cui i valori sono sparsi in tutto l'heap. Invece lo faràin pratica si tratta di un blocco consecutivo di n*4byte - un blocco di memoria con dimensioni e layout dei dati noti. Quando si ha la scelta di memorizzare 1000 byte in una raccolta di oggetti di valore intero di dimensioni arbitrarie o in un byte[1000](che richiede 1000 byte), quest'ultimo potrebbe effettivamente risparmiare un po 'di memoria. (Alcuni altri vantaggi di questo possono essere più sottili, e diventano evidenti solo quando si interfaccia Java con le librerie native)

Per quanto riguarda i punti che hai specificamente chiesto:

La dimensione non potrebbe essere determinata dinamicamente a seconda della grandezza del numero trasmesso?

L'impostazione dinamica della dimensione dei dati significherebbe che dovrebbe essere in grado di cambiare anche dinamicamente. Ciò potrebbe potenzialmente causare problemi di prestazioni?

Sarebbe probabilmente possibile impostare dinamicamente la dimensione delle variabili, se si considerasse di progettare da zero un linguaggio di programmazione completamente nuovo. Non sono un esperto nella costruzione di compilatori, ma penso che sarebbe difficile controllare sensibilmente raccolte di tipi che cambiano dinamicamente, in particolare quando si ha un linguaggio fortemente tipizzato. Quindi probabilmente si ridurrebbe a tutti i numeri memorizzati in un "tipo di dati numerico di precisione arbitrario generico", che avrebbe sicuramente un impatto sulle prestazioni. Certo, ci sono linguaggi di programmazione fortemente tipizzati e / o che offrono tipi di numeri di dimensioni arbitrarie, ma non credo che esista un vero linguaggio di programmazione per scopi generali.

Note a margine:

• Potresti esserti chiesto del unsignedmodificatore menzionato nelle specifiche di Oak. In realtà, contiene anche un'osservazione: " unsignednon è ancora implementato; potrebbe non esserlo mai". . E avevano ragione.

• Oltre a chiederti perché C / C ++ avesse questi diversi tipi di numeri interi, potresti chiederti perché li hanno incasinati così orribilmente da non sapere mai quanti bit intha. Le giustificazioni per questo sono di solito legate alle prestazioni e possono essere cercate altrove.

Indica certamente che non si è ancora insegnato su prestazioni e architetture.

• Innanzitutto, non tutti i processori sono in grado di gestire i grandi tipi, quindi è necessario conoscere i limiti e lavorare con quello.
• In secondo luogo, tipi più piccoli significano maggiori prestazioni quando si eseguono operazioni.
• Inoltre, le dimensioni contano, se devi archiviare i dati in un file o in un database, le dimensioni influenzeranno sia le prestazioni che la dimensione finale di tutti i dati, ad esempio, supponiamo che tu abbia una tabella con 15 colonne e finisca con diverse milioni di dischi. La differenza tra la scelta di una piccola dimensione necessaria per ogni colonna o la scelta del tipo più grande sarà una differenza di possibili concerti di dati e tempo nell'esecuzione delle operazioni.
• Inoltre, si applica a calcoli complessi, in cui la dimensione dei dati elaborati avrà un grande impatto, come ad esempio nei giochi.

Ignorando l'importanza della dimensione dei dati influisce sempre sulle prestazioni, è necessario utilizzare tutte le risorse necessarie, ma non di più, sempre!

Questa è la differenza tra un programma o un sistema che fa cose davvero semplici ed è incredibilmente inefficiente che richiede molte risorse e rende l'uso di quel sistema davvero costoso; o un sistema che fa molto, ma funziona più velocemente degli altri ed è davvero economico da eseguire.

Ci sono un paio di buoni motivi

(1) mentre l'archiviazione di una variabile di byte rispetto a una lunga è insignificante, l'archiviazione di milioni in un array è molto significativa.

(2) L'aritmetica "nativa dell'hardware" basata su dimensioni intere particolari può essere molto più efficiente e, per alcuni algoritmi su alcune piattaforme, può essere importante.