Il CLR di F # e C# è lo stesso, quindi perché F # è più veloce di C#

Question

Sono confuso e apprezzerei se mi illuminassi. F # utilizza lo stesso CLR di C# e il codice sottostante è identico, allora come si può suggerire che una funzione sia più veloce quando viene scritta in F # rispetto a C#? Se io uso solo variabili immutabili in C# e le prestazioni devono essere il più alte possibile, allora perché usare F #?

Answer 1

C'è stata la domanda this su stackoverflow qualche tempo fa, può aiutarti a capire alcuni motivi per cui F # potrebbe essere più veloce. Il guadagno di prestazioni dipende molto dall'applicazione e dalle funzionalità di codifica che stai utilizzando.

Answer 2

Potrebbero esserci diversi motivi per cui il codice scritto in una lingua deve essere più veloce del codice scritto nell'altro, anche se utilizzano la stessa libreria di runtime. Tuttavia, la libreria di runtime .NET non è l'unica libreria di runtime coinvolta. A quanto ho capito, c'è una libreria di runtime F # piuttosto grande che fa cose specifiche per F #. Il compilatore F # conosce questa libreria. Il compilatore C# non lo fa. Quindi il compilatore F # può effettuare chiamate a un codice di libreria runtime altamente ottimizzato a cui il compilatore C# non ha accesso.

Se entrambi utilizzano lo stesso set di librerie di runtime, quindi mi aspetto che i programmi siano vicini allo stesso, ma non esatti. I singoli compilatori potrebbero generare codice più o meno ottimale per particolari costrutti.

Answer 3

1) Se si scrive codice C# e codice F # che viene compilato esattamente con lo stesso IL (linguaggio intermedio del CLR), il codice mostrerà le stesse caratteristiche di prestazione. Tuttavia, l'implementazione dello stesso algoritmo in C# e F # non garantisce che verrà generato esattamente lo stesso IL, pertanto le prestazioni del mondo reale potrebbero variare. Credo che in pratica a volte il codice F # sarà più veloce ma altre volte C# sarà più veloce.

2) Esistono molti motivi per scegliere un linguaggio di implementazione oltre alle prestazioni. Ad esempio, alcune persone trovano che F # sia più succinta, leggibile e più facile da ragionare rispetto a C# per determinati domini problematici, il che sarebbe uno dei motivi per preferirlo. Per la stragrande maggioranza dei programmi, una differenza del 5% o del 10% nelle prestazioni sarà impercettibile per gli utenti, quindi se un linguaggio offre prestazioni paragonabili ma una produttività superiore, allora avrebbe senso usare quel linguaggio.

Answer 4

Potresti essere interessato all'articolo Performance-Related Features in F# and C#. Per quanto riguarda "perché usare F #" non posso parlare per te, ma per me uso F # perché mi piace di più.

Answer 5

codice sottostante è identico? Dubbioso. In generale, F # sarà più veloce in alcune cose e più lento negli altri. Lo stesso vale per C#. O anche VB. Ogni lingua ha i suoi vantaggi. Se c'è un aumento generale delle prestazioni in molte aree, è nel compilatore.

Se utilizzo solo variabili immutabili in C# e le prestazioni devono essere il più alte possibile, perché utilizzare F #? Nessun motivo per passare da solo alle prestazioni, se in realtà c'è una vera differenza, a meno che perf sia il tuo problema. Per quanto riguarda il motivo per cui passare se si utilizzano solo le funzionalità che vanno bene in C#, direi "non cambiare".

Mi piace F #. Ci sono alcuni "problemi" che risolve molto meglio di C#. Ma, anche se ho un problema che risolve meglio, non sto necessariamente cambiando, dato che devo considerare gli sviluppatori nel mix. Al momento, so di pochi in questa organizzazione che sanno qualcosa su F #, quindi dovrei fare un buon business case da cambiare.

In definitiva, è necessario esaminare il "problema aziendale" e determinare un percorso. Devi considerare la lingua "migliore" come parte del mix, ma devi anche esaminare la competenza di base, ecc.

Answer 6

La risposta non è la prestazione in velocità o risorse BC sono quasi la stessa. Alcuni miglioramenti e svantaggi discussi ... Il motivo per F # è il tempo di sviluppo e implementazione. F # è più snella e desiderosa di costruire con un codice più sicuro. Meno errori inclini e più esatti senza preoccuparsi di cose semplici come contatori di loop e controllo di tipo, cross-threading ecc. Quindi non è solo più facile e veloce da scrivere ma molto meno buggato. Ottieni di più da ciò che volevi davvero senza preoccuparti delle cose meschine. Ciò significa meno test e più implementazione live, più codice attendibile e funzioni più precise che non comportano sovraccarico non necessario. Pertanto, il risultato finale è un codice scritto più veloce, prestazioni ottimizzate per natura e altrettanto fiducia con meno errori.

Answer 7

Non c'è motivo di cambiare, ma suggerisco componenti costruiti per soddisfare i migliori standard. F # rafforza un sacco di standard, rende semplici i test in tempo reale durante lo sviluppo e cura i problemi di mutabilità, dipendenza circolare e la maggior parte dei controlli di tipo/riferimenti null. C# d'altra parte ha la maggior parte degli sviluppatori e degli strumenti e può essere sviluppato pensando a un modello funzionale ma non sempre corretto. Sono un fan di C# e quasi sempre scelgo C# ma vedo molte volte quando F # è ciò di cui ho più bisogno per costruire un codice robusto e più pulito. Immagino, personalmente preferisco mescolare le due lingue quando posso, ma come accennato è più importante lavorare con ciò che il tuo team di sviluppo può anche mantenere e rivedere. In molte situazioni, il team di sviluppo sarà contrario, ma in alcuni lo faranno perché vogliono anche non solo rendere il codice più forte possibile, ma imparare cose nuove. Basta non perdere troppo tempo a decidere la lingua corretta, se sei certo che F # è la migliore, presentala e verifica se hai un consenso per completarla in quel modo. Mantieni separato il tuo progetto, anche se si trova nella stessa soluzione, e usa F # quando funziona meglio e C# quando funziona meglio. F # non è così difficile da imparare, ma per uno sviluppatore puramente imperativo potrebbe sembrare brutto e confuso all'inizio. Basta spiegarlo un po 'e penso che riesca a far girare la palla. I tempi per considerare F # sono gli algoritmi in cui non si desidera solo le prestazioni, ma test immediati dei risultati. Questo accelera il tempo di sviluppo e il runtime, vinci. Altri potrebbero essere modelli se i modelli sono costituiti da molti valori immutabili. F # funziona in tutte le aree, ma per me il lato dell'interfaccia utente è più semplice in C# così come in ViewModels, dove la logica è leggermente diversa ma è un'opinione. Sarai sorpreso dei guadagni che ottieni da una dolce combinazione dei due. Inoltre, la programmazione funzionale sta diventando più semplice con linq, lambda e la più recente sintassi C# in cui C# sembra fondamentalmente funzionale, quindi il tuo tono di utilizzo di F # potrebbe non essere così difficile come anni fa.
Non ho coperto nulla al massimo ma si ottiene l'idea ... F # è potente, usalo quando funziona meglio e lo stesso per C#. Ho iniziato con VB.NET ma non lo raccomanderei più semplicemente perché le nuove tecnologie come .NET Core non lo supportano. Tuttavia, c'è anche il vantaggio di usarlo a volte ... Anche se è molto meno di un vantaggio di F #. A tal proposito, mi limito a rispettare i due primari C#, F #. Un'altra cosa, non lasciare che una curva di apprendimento ti impedisca di essere il migliore ... Recentemente ho intervistato Wells Fargo per uno stipendio decente, che aggiornava i sistemi legacy con il più avanzato 4.6.2 .NET e hanno rifiutato per accettare la sintassi asincrona/attendi bc era troppo per imparare e hanno detto che era solo zucchero sintattico ... (oh caro) Per me era una buona affermazione dire, preferiamo usare il nuovo e fare il vecchio che è un grave errore, soprattutto per i grandi progetti. Non lasciare che un progetto importante sia per metà ingannato a causa di una piccola curva di apprendimento. Gli ingegneri sono costruiti per imparare e migliorare non solo per mantenere legacy nei tempi moderni.