Quali sono le avvertenze sull'implementazione dei tipi fondamentali (come int) come classi?

Nella progettazione e implenting un linguaggio di programmazione orientato agli oggetti, ad un certo punto si deve fare una scelta circa l'attuazione di tipi fondamentali (come int, float, doubleo equivalenti) come classi o qualcos'altro. Chiaramente, i linguaggi della famiglia C hanno la tendenza a non definirli come classi (Java ha tipi primitivi speciali, C # li implementa come strutture immutabili, ecc.).

Posso pensare a un vantaggio molto importante quando i tipi fondamentali sono implementati come classi (in un sistema di tipi con una gerarchia unificata): questi tipi possono essere sottotipi di Liskov del tipo root. Pertanto, evitiamo di complicare la lingua con boxe / unboxing (esplicito o implicito), tipi di wrapper, regole speciali di varianza, comportamento speciale, ecc.

Naturalmente, posso parzialmente capire perché i progettisti del linguaggio decidono il loro modo di fare: le istanze di classe tendono ad avere un sovraccarico spaziale (perché le istanze possono contenere una vtable o altri metadati nel loro layout di memoria), che le primitive / le strutture non devono avere (se la lingua non consente l'ereditarietà su quelli).

L'efficienza spaziale (e una migliore localizzazione spaziale, specialmente in array di grandi dimensioni) è l'unica ragione per cui i tipi fondamentali non sono spesso classi?

In genere ho ipotizzato che la risposta fosse sì, ma i compilatori hanno algoritmi di analisi di escape e quindi possono dedurre se possono (selettivamente) omettere l'overhead spaziale quando un'istanza (qualsiasi istanza, non solo un tipo fondamentale) si dimostra rigorosamente Locale.

Quanto sopra è sbagliato o c'è qualcos'altro che mi manca?

Sì, si riduce praticamente all'efficienza. Ma sembra sottovalutare l'impatto (o sopravvalutare il modo in cui funzionano varie ottimizzazioni).

Innanzitutto, non si tratta solo di "spese generali spaziali". Realizzare le primitive inscatolate / allocate in heap comporta anche costi di prestazione. C'è la pressione aggiuntiva sul GC per allocare e raccogliere quegli oggetti. Ciò vale doppiamente se gli "oggetti primitivi" sono immutabili, come dovrebbero essere. Quindi ci sono più errori nella cache (sia a causa della direzione indiretta sia perché meno dati si inseriscono in una determinata quantità di cache). Inoltre il semplice fatto che "carica l'indirizzo di un oggetto, quindi carica il valore effettivo da quell'indirizzo" richiede più istruzioni di "carica direttamente il valore".

In secondo luogo, l'analisi dell'evasione non è polvere fatata più veloce. Si applica solo ai valori che, beh, non sfuggono. È certamente bello ottimizzare i calcoli locali (come contatori di loop e risultati intermedi dei calcoli) e offrirà benefici misurabili. Ma una maggioranza molto più ampia di valori vive nei campi di oggetti e matrici. Certo, quelli possono essere soggetti all'analisi di escape da soli, ma poiché di solito sono tipi di riferimento mutabili, qualsiasi aliasing di essi presenta una sfida significativa all'analisi di escape, che ora deve dimostrare che quegli alias (1) non scappano neanche e (2) non fanno differenza allo scopo di eliminare le allocazioni.

Dato che chiamare qualsiasi metodo (compresi i getter) o passare un oggetto come argomento a qualsiasi altro metodo può aiutare l'oggetto a fuggire, avrai bisogno di analisi interprocedurali in tutti tranne i casi più banali. Questo è molto più costoso e complicato.

E poi ci sono casi in cui le cose sfuggono davvero e non possono essere ragionevolmente ottimizzate. Molti di loro, in realtà, se si considera la frequenza con cui i programmatori C affrontano il problema dell'allocazione delle cose. Quando un oggetto contenente un int fuoriesce, l'analisi di escape cessa di applicarsi anche all'int. Dì addio a campi primitivi efficienti .

Questo si collega a un altro punto: le analisi e le ottimizzazioni richieste sono seriamente complicate e un'area attiva di ricerca. È discutibile se qualsiasi implementazione del linguaggio abbia mai raggiunto il grado di ottimizzazione che suggerisci e, anche se così, è stato uno sforzo raro ed erculeo. Sicuramente stare sulle spalle di questi giganti è più facile che essere un gigante, ma è ancora tutt'altro che banale. Non aspettarti prestazioni competitive in qualsiasi momento nei primi anni, se mai.

Ciò non significa che tali lingue non possano essere praticabili. Chiaramente lo sono. Non dare per scontato che sarà line-to-line veloce come le lingue con primitive dedicate. In altre parole, non illuderti con le visioni di un compilatore sufficientemente intelligente .

L'efficienza spaziale (e una migliore localizzazione spaziale, specialmente in array di grandi dimensioni) è l'unica ragione per cui i tipi fondamentali non sono spesso classi?

No.

L'altro problema è che i tipi fondamentali tendono ad essere utilizzati da operazioni fondamentali. Il compilatore deve sapere che int + intnon verrà compilato per una chiamata di funzione, ma per alcune istruzioni CPU elementari (o codice byte equivalente). A quel punto, se hai intcome oggetto normale, dovrai comunque decomprimere efficacemente la cosa.

Anche questo tipo di operazioni non funziona davvero bene con il sottotipo. Non è possibile inviare un'istruzione CPU. Non è possibile inviare da un'istruzione CPU. Voglio dire, l'intero punto del sottotipo è che puoi usare un punto Ddove puoi B. Le istruzioni della CPU non sono polimorfiche. Per fare in modo che le primitive lo facciano, devi concludere le loro operazioni con la logica di invio che costa più volte la quantità di operazioni come semplice aggiunta (o qualsiasi altra cosa). Il vantaggio di intfar parte della gerarchia dei tipi diventa un po 'controverso quando è sigillato / finale. E questo ignora tutti i mal di testa con la logica di invio per gli operatori binari ...

In sostanza, i tipi primitivi avrebbero bisogno di avere un sacco di regole speciali in giro come il compilatore maniglie loro, e ciò che l'utente può fare con i loro tipi in ogni caso , per cui è spesso più semplice per trattarli proprio come completamente distinti.

Ci sono solo pochissimi casi in cui è necessario che i "tipi fondamentali" siano oggetti completi (qui, un oggetto sono dati che contengono un puntatore a un meccanismo di invio o sono etichettati con un tipo che può essere utilizzato da un meccanismo di invio):

• Desideri che i tipi definiti dall'utente siano in grado di ereditare dai tipi fondamentali. Questo di solito non è voluto in quanto introduce mal di testa legati alle prestazioni e alla sicurezza. È un problema di prestazioni perché la compilazione non può presumere che intavrà una dimensione fissa specifica o che non sia stato ignorato alcun metodo ed è un problema di sicurezza perché la semantica di ints potrebbe essere sovvertita (considerare un numero intero uguale a qualsiasi numero, oppure che cambia il suo valore anziché essere immutabile).

• I tuoi tipi primitivi hanno supertipi e vuoi avere variabili con tipo di un supertipo di tipo primitivo. Ad esempio, supponiamo intche lo siano Hashablee che si desidera dichiarare una funzione che accetta un Hashableparametro che potrebbe ricevere oggetti regolari ma anche ints.

  Questo può essere "risolto" rendendo illegali questi tipi: sbarazzarsi del sottotipo e decidere che le interfacce non sono tipi ma vincoli di tipo. Ovviamente ciò riduce l'espressività del sistema di tipi e tale sistema di tipi non verrebbe più definito orientato agli oggetti. Vedi Haskell per un linguaggio che utilizza questa strategia. Il C ++ è a metà strada perché i tipi primitivi non hanno supertipi.

  L'alternativa è il pugilato completo o parziale di tipi fondamentali. Non è necessario che il tipo di boxe sia visibile all'utente. In sostanza, si definisce un tipo boxed interno per ogni tipo fondamentale e conversioni implicite tra il tipo boxed e fondamentale. Questo può diventare imbarazzante se i tipi inscatolati hanno una semantica diversa. Java presenta due problemi: i tipi boxed hanno un concetto di identità mentre i primitivi hanno solo un concetto di equivalenza di valore, ei tipi boxed sono nullable mentre i primitivi sono sempre validi. Questi problemi sono completamente evitabili non offrendo un concetto di identità per i tipi di valore, offrendo un sovraccarico dell'operatore e non rendendo tutti gli oggetti nulli per impostazione predefinita.

• Non hai la digitazione statica. Una variabile può contenere qualsiasi valore, inclusi tipi o oggetti primitivi. Pertanto, tutti i tipi primitivi devono essere sempre inscatolati per garantire una digitazione forte.

Le lingue che hanno la tipizzazione statica fanno bene a usare i tipi primitivi ove possibile e ricorrono ai tipi boxati come ultima risorsa. Mentre molti programmi non sono incredibilmente sensibili alle prestazioni, ci sono casi in cui le dimensioni e la composizione dei tipi primitivi sono estremamente rilevanti: pensate allo scricchiolio dei numeri su larga scala in cui è necessario adattare miliardi di punti dati nella memoria. Passare da doubleafloatpotrebbe essere una strategia di ottimizzazione dello spazio praticabile in C, ma non avrebbe praticamente alcun effetto se tutti i tipi numerici fossero sempre inscatolati (e quindi sprecasse almeno metà della loro memoria per un puntatore del meccanismo di invio). Quando i tipi primitivi inscatolati sono usati localmente, è abbastanza semplice rimuovere la boxe attraverso l'uso di intrinseci del compilatore, ma sarebbe miope scommettere le prestazioni complessive della tua lingua su un "compilatore sufficientemente avanzato".

La maggior parte delle implementazioni di cui sono a conoscenza impone tre restrizioni a tali classi che consentono al compilatore di utilizzare in modo efficiente i tipi primitivi come rappresentazione sottostante la maggior parte delle volte. Queste restrizioni sono:

• Immutabilità
• Finalità (impossibile derivarne)
• Digitazione statica

Le situazioni in cui un compilatore deve inserire una primitiva in un oggetto nella rappresentazione sottostante sono relativamente rare, come quando un Objectriferimento lo punta.

Questo aggiunge un bel po 'di gestione dei casi speciali nel compilatore, ma non si limita solo a un mitico compilatore super-avanzato. Tale ottimizzazione è nei compilatori di produzione reali nelle principali lingue. Scala consente persino di definire le proprie classi di valore.

In Smalltalk tutti (int, float, ecc.) Sono oggetti di prima classe. L' unico caso speciale è che SmallInteger è codificato e trattato in modo diverso dalla Macchina Virtuale per motivi di efficienza, e quindi la classe SmallInteger non ammetterà le sottoclassi (che non è una limitazione pratica). Nota che questo non richiede alcuna considerazione speciale da parte del programmatore poiché la distinzione è circoscritta a routine automatiche come la generazione di codice o la garbage collection.

Sia il compilatore Smalltalk (codice sorgente -> bytecode VM) che il nativizer VM (bytecodes -> codice macchina) ottimizzano il codice generato (JIT) in modo da ridurre la penalità delle operazioni elementari con questi oggetti di base.

Stavo progettando una lingua OO e un runtime (questo non è riuscito per una serie completamente diversa di motivi).

Non c'è nulla di intrinsecamente sbagliato nel creare cose come le classi vere int; in effetti ciò semplifica la progettazione del GC in quanto ora esistono solo 2 tipi di intestazioni di heap (classe e matrice) anziché 3 (classe, matrice e primitiva) [il fatto che possiamo unire classe e matrice dopo ciò non è rilevante ].

Il vero caso importante che i tipi primitivi dovrebbero avere per lo più metodi finali / sigillati (+ conta davvero, ToString non tanto). Ciò consente al compilatore di risolvere staticamente quasi tutte le chiamate alle funzioni stesse e incorporarle. Nella maggior parte dei casi questo non ha importanza come comportamento di copia (ho scelto di rendere disponibile l'incorporamento a livello di lingua [come ha fatto .NET]), ma in alcuni casi se i metodi non sono sigillati il ​​compilatore sarà costretto a generare la chiamata a la funzione utilizzata per implementare int + int.