È possibile che F # sarà ottimizzato più di altre lingue .Net in futuro?

Question

È possibile che Microsoft sia in grado di creare programmi F #, in fase di esecuzione della VM, o più probabilmente in fase di compilazione, rilevare che un programma è stato creato con un linguaggio funzionale e parallelizzarlo automaticamente meglio?

In questo momento credo che non ci sia nessuno sforzo per provare ad eseguire un programma che è stato creato automaticamente come programma a thread singolo come programma multi-thread.

Vale a dire, lo sviluppatore codificherebbe un singolo programma thread. E il compilatore sputerebbe fuori un programma compilato che è multi-thread completo di mutex e sincronizzazione dove necessario.

Queste ottimizzazioni sarebbero visibili nel task manager nel conteggio dei thread del processo o sarebbero di livello inferiore rispetto a quello?

Answer 1

Penso che ciò sia improbabile nel prossimo futuro. E se ciò dovesse accadere, penso che sarebbe più probabile a livello di IL (riscrittura di assembly) piuttosto che a livello di linguaggio (ad esempio qualcosa di specifico per F # / compilatore). È una domanda interessante, e mi aspetto che alcune belle menti lo stiano guardando e continueranno a guardarlo per un po ', ma a breve termine, penso che l'attenzione sarà focalizzata sul rendere più facile per gli umani dirigere il thread / parallelizzazione dei programmi, piuttosto che far accadere tutto come per magia.

(Funzionalità linguistiche come F # async flussi di lavoro e librerie come la libreria parallela alle attività e altre , sono buone esempi di progressi a breve termine qui; possono fare la maggior parte del lavoro pesante per te, specialmente quando il tuo programma è più dichiarativo che imperativo, ma richiedono ancora al programmatore di opt-in, fare analisi per correttezza / significatività e probabilmente fare lievi modifiche alla struttura del codice per far funzionare tutto.)

Comunque, è tutta una speculazione; chi può dire cosa porterà il futuro? Non vedo l'ora di scoprirlo (e speriamo che accada qualcosa). :)

Answer 2

Dato che F # è derivato dai compilatori Ocaml e Ocaml in grado di ottimizzare i tuoi programmi molto meglio degli altri compilatori, probabilmente potrebbe essere fatto.

Answer 3

Non credo che sia possibile autovectorizzare il codice in un modo generalmente utile e la funzione di programmazione funzionale di F # è essenzialmente irrilevante in questo contesto.

Il problema più difficile non è rilevare quando è possibile eseguire sub-computazioni in parallelo, è determinare quando ciò non degraderà le prestazioni, ovvero quando le attività secondarie impiegheranno abbastanza tempo per calcolare che vale la pena subire il colpo di prestazione di un spawn parallelo.

Abbiamo studiato questo in dettaglio nel contesto dell'informatica scientifica e abbiamo adottato un approccio ibrido nella nostra libreria F # for Numerics. I nostri algoritmi paralleli, basati sulla Task Parallel Library di Microsoft, richiedono un parametro aggiuntivo che è una funzione che fornisce la complessità computazionale stimata di una sottoattività. Ciò consente alla nostra implementazione di evitare una suddivisione eccessiva e garantire prestazioni ottimali. Inoltre, questa soluzione è ideale per il linguaggio di programmazione F # perché il parametro della funzione che descrive la complessità è in genere una funzione anonima di prima classe.

Saluti, Jon Harrop.

Answer 4

Penso che la domanda manchi il punto dell'architettura .NET: F #, C # e VB (ecc.) vengono tutti compilati in IL, che viene quindi compilato in codice macchina tramite il compilatore JIT. Il fatto che un programma sia stato scritto in un linguaggio funzionale non è rilevante: se ci sono ottimizzazioni (come ricorsione della coda, ecc.) Disponibili per il compilatore JIT dall'IL, il compilatore dovrebbe trarne vantaggio.

Naturalmente, ciò non significa che la scrittura di codice funzionale sia irrilevante - ovviamente, ci sono modi per scrivere IL che si parallelizzeranno meglio - ma molte di queste tecniche potrebbero essere utilizzate in qualsiasi linguaggio .NET.

Quindi, non è necessario contrassegnare l'IL come proveniente da F # per esaminarlo per un potenziale parallelismo, né sarebbe auspicabile una cosa del genere.

Answer 5

Esiste una ricerca attiva per l'autoparallelizzazione e la vettorializzazione automatica per una varietà di lingue. E si potrebbe sperare (dal momento che mi piace molto F #) che possano concedere un modo per determinare se un "puro" è stato utilizzato un sottoinsieme privo di effetti collaterali e quindi parallelizzato. Inoltre, dato che Simon Peyton-Jones, padre di Haskell, lavora in Microsoft, faccio fatica a non credere che ci siano delle cose fantastiche in arrivo.

Answer 6

È possibile ma improbabile. Microsoft impiega la maggior parte del tempo a supportare e implementare le funzionalità richieste dai suoi maggiori clienti. Questo di solito significa C #, VB.Net e C ++ (non necessariamente in quell'ordine). F # non sembra essere in cima alla lista delle priorità.

Answer 7

Microsoft sta attualmente sviluppando 2 strade per la parallelizzazione del codice: PLINQ (Pararllel Linq, che deve molto ai linguaggi funzionali) e Task Parallel Library (TPL) che originariamente faceva parte di Robotics Studio. Una versione beta di PLINQ è disponibile qui .

Metterei i miei soldi su PLINQ diventando la norma per l'auto-parallelizzazione del codice .NET.