Boostrapping limita la velocità raggiungibile del nuovo compilatore?

2

Ho una buona conoscenza di come Il compilatore C è stato boomerato da sé e come deve essere stato molto efficiente, dal momento che la prima versione pre-bootstrapping è stata scritta in assembler, che è il livello più basso che puoi ottenere.

MA oggi abbiamo una situazione molto diversa, con le lingue scritte per la prima volta su altri linguaggi di livello relativamente elevato (ad esempio Clojure).

Domanda 1: Ho difficoltà a immaginare che il compilatore bootstrap possa essere più veloce in qualcosa che non sia la sua controparte non-bootstrapped. È possibile?

Domanda 2: Soprattutto una volta che hai fatto il passo in cui scrivi la nuova versione del tuo compilatore nella tua nuova lingua: È possibile correggere eventuali inefficienze esistenti nel codice non sottoposto a boot o la generazione del codice del nuovo compilatore è perseguitata da quelle per sempre? Questo è ancora più importante in quanto non è facile tornare indietro e correggerle successivamente !

    
posta Profpatsch 15.01.2014 - 19:27
fonte

4 risposte

8

Penso che il modo più semplice per risolvere questo problema, mentalmente, è solo rendersi conto che tutto finisce come codice macchina comunque. Come è finito come codice macchina è la storia , e la storia ha certamente un significato per noi come persone, ma ai computer non importa quale sia la storia del codice macchina . Fanno solo ciò che il set di istruzioni di livello più basso dice loro di fare.

Mentalmente, potremmo pensare in questo modo:

  1. Qualcuno ha scritto il codice macchina appropriato per consentire, ad esempio, C.
  2. C è stato usato per scrivere C-Plus-Classes
  3. C ++ si abitua a creare un'implementazione, per esempio, di Java.

Pertanto, giustifichiamo la convinzione che qualsiasi cosa in Java debba essere più lenta di qualsiasi altra cosa, per esempio, in Assembler. Ma ... non è così che funziona davvero!

Come funziona davvero oggigiorno

  1. Il computer esegue il codice macchina.

Oppure, per coloro che vogliono prendere in considerazione bytecode:

  1. Il codice macchina (JIT) trasforma bytecode in codice macchina. (il tempo di avvio è più lento, forse)
  2. Il computer esegue il codice macchina.

Tutto il codice finisce nello stesso posto, quindi il lungo percorso che ci è voluto per arrivarci non influisce necessariamente sul modo in cui viene eseguito.

A volte c'è un livello extra, come con JavaScript che non viene mai compilato sul codice macchina prima di essere eseguito, ma il codice macchina trasforma anche quella roba in codice macchina. Tutto finisce nello stesso posto, nella CPU e nella RAM. Qualche codice macchina non è efficiente come un altro codice macchina, ma il modo in cui quel codice è stato scritto non ha molta importanza: a volte il codice macchina scrive il miglior codice macchina e, a volte, una scrittura umana lo avrebbe fatto diversamente e in quel modo sarebbe stato meglio. Ora, grazie ad alcuni umani molto intelligenti, è davvero una cosa rara, e le differenze sono in genere troppo piccole per cui preoccuparsi.

Quindi, indipendentemente dal fatto che il compilatore fosse o meno avviato, e che la compilazione avvenga in ritardo, o in anticipo, o appena in tempo, o solo tramite il servizio di posta con un SASE in Bangladesh, il risultato non è necessariamente limitato dal il percorso ha preso la stessa destinazione.

    
risposta data 15.01.2014 - 20:25
fonte
7
  1. I compilatori moderni (in particolare JIT) hanno algoritmi di ottimizzazione che esistono al di fuori del dominio delle lingue di origine. Ciò invalida la premessa originale, ovvero che un compilatore bootstrap non può essere più veloce di un compilatore "nativo" perché è costruito su un sottoinsieme della lingua di origine.

  2. I programmatori sono notoriamente cattivi nel predire dove il codice si esibirà in modo subottimale. L'unico buon modo per sapere è misurare le prestazioni con un profiler.

  3. Al giorno d'oggi, un buon compilatore ottimizzante può spesso produrre codice oggetto o codice binario più veloce dell'assemblaggio codificato a mano, a condizione che il codice sorgente sia scritto in modo da non vanificare le ottimizzazioni del compilatore.

risposta data 15.01.2014 - 19:33
fonte
2
  1. linguaggio di progettazione A.
  2. Scrivi prima il compilatore A nella lingua B.
  3. Compilare il primo compilatore A usando qualsiasi compilatore B.
  4. Scrivi il secondo compilatore A nella lingua A.
  5. Compilare il secondo compilatore A usando l'eseguibile ottenuto nel passaggio 3.
  6. Compilare il secondo compilatore A usando l'eseguibile ottenuto nel passaggio 5.

Supponiamo che tutti i compilatori coinvolti (il compilatore B e entrambi i compilatori A) siano corretti. Quindi gli eseguibili ottenuti nei passaggi 5 e 6 corrispondono al codice sorgente scritto nel passaggio 3, in particolare, analizzano un codice, lo ottimizzano e generano il codice esattamente come specificato durante il passaggio 4, indipendentemente da ciò che è accaduto durante il passaggio 2.

Inoltre, l'eseguibile del passo 6 contiene esattamente il codice che il compilatore secondo dovrebbe emettere, indipendentemente dal tipo di codice che il primo compilatore emesso durante il passaggio 5 ( di nuovo, purché fosse corretto dato il codice sorgente).

Ripeti questo processo se necessario. Qualsiasi compilatore, indipendentemente da quanto complicato sia il suo processo di origine e di bootstrap, può essere fatto per entrambi

  1. corri il più velocemente possibile con il miglior compilatore A o B.
  2. emette un codice efficiente quanto il codice più efficiente di qualsiasi compilatore A.

Tieni presente che si tratta di due metriche molto diverse, ho incluso entrambi perché non era chiaro di quale stavi parlando.

    
risposta data 15.01.2014 - 20:00
fonte
0

Una ragione per cui (i compilatori bootstrap) possono essere più veloci perché in un linguaggio di basso livello, le cose funzionano, ma probabilmente non ti preoccuperai di implementare un comportamento complesso. Nel linguaggio di alto livello è molto più facile. IOW, le ottimizzazioni (a livello di algoritmo e struttura dei dati) sono spesso più facili da fare nella lingua superiore rispetto all'assemblatore.

    
risposta data 15.01.2014 - 19:42
fonte

Leggi altre domande sui tag