Lingue e VMs:Caratteristiche che sono difficili da ottimizzare e perché

Question

Sto facendo un sondaggio di funzionalità in preparazione per un progetto di ricerca.

Nome mainstream lingua o lingua caratteristica che è difficile da ottimizzare, e perché la funzione è o non vale il prezzo pagato, o, invece, solo sfatare il mio teorie sotto con le prove aneddotiche.Prima che qualcuno flag questo soggettiva, io sto chiedendo per esempi specifici di lingue o caratteristiche, e le idee per l'ottimizzazione di queste caratteristiche o caratteristiche importanti che non ho considerato.Inoltre, tutti i riferimenti a implementazioni di dimostrare le mie teorie giuste o sbagliate.

In alto sulla mia lista di duro per ottimizzare la funzionalità e le mie teorie (alcune delle mie teorie sono testati e sono basate su esperimenti di pensiero):

1) Runtime l'overload del metodo (aka multi-metodo di spedizione o di firma a base di spedizione).È difficile ottimizzare quando combinato con funzionalità che consentono di runtime ricompilazione o metodo di aggiunta.O è solo difficile, comunque?Sito di chiamata cache è un comune di ottimizzazione per molti sistemi di runtime, ma multi-metodi di aggiungere ulteriore complessità e rende meno pratico metodi inline.

2) Tipo di morphing / varianti (aka valore tipizzazione anziché variabile in base) Tradizionale ottimizzazioni semplicemente non può essere applicato quando non sai se il tipo di qualcosa può cambiare in un blocco di base.Combinato con multi-metodi, allineamento deve essere fatto con attenzione se non a tutti, e probabilmente solo per una determinata soglia di dimensione del chiamato.ie.è facile considerare l'inline di proprietà semplice recupera (getter / setter), ma l'inline di complessi metodi possono causare codice bloat.L'altro problema è che non posso assegnare una variante di un registro e JIT materna istruzioni perché devo portare in giro il tipo di informazioni o ogni variabile ha bisogno di 2 registri invece di 1.IA-32 questo è scomodo, anche se migliorato con x64 extra registri.Questo è probabilmente il mio preferito caratteristica dei linguaggi dinamici, che semplifica molte cose dal punto di vista del programmatore.

3) Prima classe continuazioni - Ci sono diversi modi per la loro attuazione, e l'ho fatto in entrambi gli approcci più comuni, di cui uno stack di copia e l'altra come implementare il runtime di utilizzare continuazione passando stile, cactus pile, copy-on-write stack frame, e la raccolta dei rifiuti.Prima classe continuazioni hanno problemi di gestione delle risorse, vale a dire.dobbiamo salvare il tutto, nel caso in cui il seguito è ripreso, e io non sono a conoscenza se tutte le lingue il supporto di lasciare una continuazione con "l'intento" (ie."Io non sono venuta qui dietro, in modo che si può scartare questa copia del mondo").Avendo programmato il modello di threading e la contination modello, so che entrambi possono fare la stessa cosa, ma continuazioni' eleganza impone un notevole complessità di runtime e può anche influenzare la cache efficienty (località pila cambia più con l'uso di continuazioni e co-routine).L'altro problema è che semplicemente non mappa di hardware.Ottimizzazione continuazioni è l'ottimizzazione per i casi più comuni, e come sappiamo, il caso dovrebbe essere veloce, e meno comuni i casi dovrebbero essere corrette.

4) Aritmetica dei puntatori e la capacità di mascherare i puntatori (memorizzazione dei numeri interi, etc.) Dovuto buttare questo, ma ho potuto vivere senza questo abbastanza facilmente.

Le mie sensazioni sono che molte delle funzioni di alto livello, in particolare nei linguaggi dinamici basta non mappa di hardware.Microprocessore implementazioni sono miliardi di dollari di ricerca dietro le ottimizzazioni sul chip, ma la sua scelta di funzionalità del linguaggio(s) può emarginare molte di queste funzioni (come la memorizzazione nella cache, aliasing cima della pila di registro, di istruzione, di parallelismo, l'indirizzo di ritorno buffer, ciclo di buffer e di branch prediction).Macro-applicazioni di micro-caratteristiche non necessariamente pan come alcuni sviluppatori piace pensare, e l'implementazione di molte lingue in una VM finisce la mappatura nativa op nelle chiamate di funzione (ie.il più dinamico di una lingua è la più dobbiamo di ricerca/cache in fase di runtime, nulla può essere assunto, in modo che la nostra istruzione mix è fatto di una maggiore percentuale di non-locale ramificazione di quelli tradizionali, in modo statico il codice compilato) e l'unica cosa che possiamo davvero JIT bene è la valutazione dell'espressione di non-dinamica tipi e le operazioni in costante immediato o tipi.È la mia sensazione che il bytecode macchine virtuali e JIT core sono, forse, non sempre giustificato per alcune lingue, a causa di questo.

Accolgo con favore le vostre risposte.

Answer 1

Un paio di commenti:

• Tutti i linguaggi dinamici con l'invio, anche sulla base di un singolo oggetto, sembra piuttosto difficile da attuare in modo efficiente.Guarda tutto lo sforzo che è andato in run-time di ottimizzazione di Sé (o, più recentemente, JavaScript, con SpiderMonkey).

• Da non trascurare delimitato continuazioni.La giuria è ancora fuori, ma sono molto più facile ottimizzare il classico di undelimited continuazioni.Leggere la carta da Gasbichler e Sperber.

Answer 2

È la mia sensazione che il bytecode macchine virtuali e JIT core forse non è sempre giustificata per alcune lingue, a causa di questo.

Non IronPython scritti per dimostrare che una macchina virtuale non potrebbe fare così come l'implementazione nativa della lingua (Python).E poi l'autore di IronPython ha ottenuto piuttosto uno shock quando hanno scoperto che IronPython fatto molto bene per un linguaggio dinamico in un bytecode VM?

Proprietari di Microsoft .Nette interne di gruppo sono su record come affermando che pensano che, in definitiva, il JITter superare un "normale" del compilatore/linker (per dire C/C++).

Penso che la giuria è ancora fuori su questo.Difficile chiamare in entrambi i modi.Scegli la lingua che meglio si adatta al lavoro...