I principi di progettazione dei linguaggi di programmazione funzionale e dell'hardware corrente (macchine di registro) sono contrari?

3

I linguaggi funzionali cercano di minimizzare lo stato accidentale (computazionalmente conveniente ma logicamente non necessario dipendenze dei dati ) approvando i costrutti più granulosamente modulari, matematicamente non ambigui . Tuttavia, le macchine per registri di uso generico raggiungono la massima efficienza in termini di tempo / spazio grazie alla massimizzazione delle dipendenze dei dati , poiché ciò consente alla CPU di utilizzare i dati a disposizione piuttosto che pagare il costo di un ulteriore switch di contesto per la procedura estratta.

Per trasformare la minimizzazione delle dipendenze dei dati in un vantaggio in termini di prestazioni, si dovrebbero usare queste garanzie aggiuntive per perseguire un parallelismo maggiore senza punire l'estrazione di piccole procedure anonime come in stack- (qui e qui ) o in base alla coda ( qui e qui ) architetture. Il design del chip non è ancora andato in queste direzioni perché la legge di Moore e il ridimensionamento di Dennard hanno storicamente reso la parallelizzazione un gioco perdente dal punto di vista economico (anche se potrebbe presto cambiare).

I linguaggi funzionali come Haskell (o Kitten ) superano il mainstream quando lo spettacolo > I vantaggi che sono progettati per offrire sono così in disaccordo con le priorità dei produttori di hardware?

    
posta Typist 01.07.2018 - 04:33
fonte

1 risposta

4

La programmazione funzionale non è intrinsecamente inefficiente. Non c'è motivo per cui la semantica del linguaggio debba corrispondere strettamente al modello di esecuzione sottostante, anche se una corrispondenza più stretta rende sicuramente più facile la compilazione.

Ad esempio, Haskell è già in grado di fornire buone prestazioni in questo momento, ma l'ottimizzazione è un problema da non perdere: è difficile scrivere il codice Haskell che verrà compilato in modo affidabile con codice macchina ben ottimizzato. Il problema non è che Haskell sia un linguaggio funzionale , ma che Haskell abbia una semantica abbastanza complessa e di alto livello, in particolare caratteristiche insolite come la valutazione pigra. Altri linguaggi funzionali sono molto dinamici e non dispongono di un sistema di tipi che consentirebbe la generazione di codice efficiente, ad esempio JavaScript.

Ma i linguaggi FP non dispongono di quelle semantiche complesse , ad es. la famiglia linguistica ML ha linguaggi imperativo-funzionali tipicamente staticamente digitati come OCaml. Oltre a dover gestire le chiusure, la compilazione di OCaml non è fondamentalmente diversa dalla compilazione C. E C ha anche caratteristiche problematiche che limitano la sua efficienza sull'hardware attuale, ad es. puntatore aliasing.

Se le lingue funzionali hanno una funzionalità problematica w.r.t. esecuzione efficiente, è la necessità di Garbage Collection . Per esempio. strutture dati immutabili, chiusure e continuazioni sono tutte vantaggiose se:

  • i dati non referenziati possono essere raccolti con parsimonia a basso costo
  • probabilmente: i dati possono essere copiati a basso costo, ad es. attraverso copy-on-write (CoW)
  • un modello esecutivo che non presuppone l'esistenza di uno stack

Queste sono cose che potrebbero in linea di principio essere spostate nel silicio, ad es. un chip MMU con hardware GC e un indirizzamento virtuale incorporato che supporta CoW. (Sì, sono a conoscenza delle pagine di CoW, ma qui non è abbastanza granulare.) Tuttavia, ciò implicherebbe un modello di memoria radicalmente diverso rispetto a quello utilizzato oggi. Dubito che questo sarebbe più efficiente dello stato attuale della tecnica, ma potrebbe consentire un'esecuzione più efficiente di programmi funzionali e orientati agli oggetti rispetto all'hardware corrente.

Ma ciò non accadrà, semplicemente perché le economie di scala favoriscono lo status quo. C'era una volta l'hardware di programmazione funzionale: Lisp Machines . Questi sono praticamente scomparsi, a causa del calo della domanda Lisp e dei microprocessori (come i chip x86): i microprocessori sono già abbastanza veloci. Costruire grandi compilatori è più economico rispetto allo sviluppo di chip competitivi. Per ragioni simili, le JVM hardware non sono mai state catturate (anche se le piattaforme Java lo hanno fatto, vedi Android e molti feature phone).

    
risposta data 01.07.2018 - 13:12
fonte