Quanto è maturo il progetto linguistico di calcolo scientifico "Julia"?

Sto pensando di imparare un nuovo linguaggio da utilizzare per i progetti di modellazione numerica / di simulazione, in sostituzione (parziale) di C ++ e Python che attualmente uso. Mi sono imbattuto in Julia , che suona un po 'perfetto. Se fa tutto ciò che afferma, potrei usarlo per sostituire sia C ++ che Python in tutti i miei progetti, dal momento che può accedere a un codice di libreria scientifica di alto livello (incluso PyPlot) e correre per loop a una velocità simile a C. Vorrei anche beneficiare di cose come le corrette coroutine che non esistono in nessuna delle altre lingue.

Tuttavia, è un progetto relativamente nuovo, attualmente alla versione 0.x, e ho trovato vari avvisi (pubblicati in varie date in passato) che non è del tutto pronto per l'uso quotidiano. Di conseguenza, vorrei alcune informazioni sullo stato del progetto in questo momento (febbraio 2014 o ogni volta che viene pubblicata una risposta), al fine di aiutarmi a valutare se personalmente dovrei considerare di investire il tempo per imparare questa lingua in questa fase.

Gradirei risposte che si concentrano su fatti specifici specifici relativi al progetto Julia ; Sono meno interessato alle opinioni basate sull'esperienza con altri progetti.

In particolare, un commento di Geoff Oxberry suggerisce che l'API Julia è ancora in uno stato di flusso, richiedendo l'aggiornamento del codice quando cambia. Vorrei avere un'idea della misura in cui questo è il caso: quali aree dell'API sono stabili e quali possono cambiare?

Immagino che in genere farei principalmente algebra lineare (ad esempio, risoluzione di autovalori), integrazione numerica di ODE con molte variabili e stampa con PyPlot e / o OpenGL, nonché crunching numerico di basso livello in stile C (ad esempio per simulazioni Monte Carlo ). Il sistema bibliotecario di Julia è completamente sviluppato in queste aree? In particolare, l'API è più o meno stabile per questi tipi di attività o troverei che il mio vecchio codice tenderebbe a rompersi dopo l'aggiornamento a una nuova versione di Julia?

Infine, ci sono altri problemi che varrebbe la pena considerare nel decidere se utilizzare Julia per un lavoro serio in questo momento?

Julia, a questo punto (maggio 2019, Julia v1.1 con v1.2 sta per uscire) è abbastanza matura per il calcolo scientifico. La versione v1.0 indicava la fine della rottura annuale del codice . Con ciò, molte librerie di informatica scientifica hanno avuto il tempo di crescere semplicemente senza interruzioni. Un'ampia panoramica dei pacchetti Julia è disponibile su pkg.julialang.org .

Per il core computing scientifico, la libreria DifferentialEquations.jl per equazioni differenziali (ODE, SDE, DAE, DDE, simulazioni Gillespie, ecc.), Flux.jl per reti neurali e la libreria JuMP per la programmazione matematica (ottimizzazione: lineare, quadratica, programmazione mista mista, ecc.) sono tre dei cardini dell'ecosistema del calcolo scientifico. La libreria di equazioni differenziali in particolare è molto più sviluppata di quella che vedresti in altre lingue, con un grande team di sviluppo che implementa funzionalità come integratori EPIRK , Runge-Kutta-Nystrom , equazione differenziale ritardo rigido / differenziale-algebrico etempo adattativo equazione rigida differenziale stocastica integratori, insieme ad un sacco di altre cose, come analisi di sensitività adjoint , DSL reazioni chimiche , privo di matrice Newton-Krylov e completo (dati svincolato) compatibilità GPU, con formazione di equazioni differenziali neurali , tutti con risultati di benchmark fantastici (disclaimer: sono lo sviluppatore principale).

La cosa che sbalordisce un po 'l'ecosistema Julia maturato è la sua compostabilità. In sostanza, quando qualcuno crea una funzione di libreria generica come quelle in DifferentialEquations.jl, è possibile utilizzare qualsiasi tipo AbstractArray / Number per generare al volo nuovo codice. Quindi, ad esempio, esiste una libreria per la propagazione degli errori ( Measurements.jl ) e quando lo si inserisce nel solutore ODE, compila automaticamente una nuova versione del solutore ODE che esegue la propagazione degli errori senza campionamento dei parametri . Per questo motivo, potresti non trovare alcune funzionalità documentate perché il codice delle funzionalità si genera da solo, quindi devi pensare di più alla composizione della libreria.

Uno dei modi in cui la composizione è più utile è l'algebra lineare. I risolutori ODE, ad esempio, ti consentono di specificare jac_prototype, permettendoti di dargli il tipo per il giacobino che verrà usato internamente. Naturalmente ci sono cose nella libreria standard di LineraAlgebra come Symmetrice Tridiagonalsi può usare qui, ma data l'utilità della composibilità negli algoritmi di tipo generico, le persone sono ormai andate a costruire intere librerie di tipi di array. BandedMatrices.jl e BlockBandedMatrices.jl sono librerie che definiscono tipi di matrice a bande (Block) con lusovraccarichi rapidi , rendendoli un modo piacevole per accelerare la soluzione di discretizzazioni MOL rigide di sistemi di equazioni differenziali parziali. PDMats.jlconsente la specifica di matrici definite positive. Elemental.jl ti consente di definire un giacobino sparso distribuito. CuArrays.jl definisce gli array sulla GPU. Eccetera.

Quindi hai tutti i tuoi tipi di numero. Unitful.jl esegue il controllo dell'unità al momento della compilazione, quindi è una libreria di unità senza sovraccarico. DoubleFloats.jl è una libreria di precisione superiore e veloce, insieme a Quadmath.jl e ArbFloats.jl . ForwardDiff.jl è una libreria per la differenziazione automatica in modalità forward che utilizza l'aritmetica a doppio numero. E posso continuare ad elencarli. E sì, puoi gettarli in librerie Julia sufficientemente generiche come DifferentialEquations.jl per compilare una versione specificamente ottimizzata per questi tipi di numeri. Anche qualcosa come ApproxFun.jlche funziona come oggetti algebrici (come Chebfun) funziona con questo sistema generico, consentendo la specifica di PDE come ODE su scalari in uno spazio funzionale.

Dati i vantaggi della compostabilità e il modo in cui i tipi possono essere utilizzati per generare codice nuovo ed efficiente sulle funzioni generiche di Julia, c'è stato molto lavoro per ottenere implementazioni della funzionalità di calcolo scientifico di base in Julia pura. Optim.jl per l'ottimizzazione non lineare, NLsolve.jl per la risoluzione di sistemi non lineari, IterativeSolvers.jl per i solutori iterativi di sistemi lineari e eigensystems, BlackBoxOptim.jl per l'ottimizzazione della scatola nera, ecc. Anche la libreria di rete neurale Flux.jl utilizza solo CuArrays. compilazione automatica di codice jl nella GPU per le sue capacità GPU. Questa compostabilità è stata il nucleo di ciò che ha creato cose come le equazioni differenziali neurali in DiffEqFlux.jl. Anche i linguaggi di programmazione probabilistica come Turing.jl sono abbastanza maturi e fanno uso degli stessi strumenti di base.

Dal momento che le librerie di Julia sono fondamentalmente basate su strumenti di generazione del codice, non dovrebbe sorprendere che ci siano molti strumenti per la generazione del codice. Il sistema di trasmissione di Julia genera al volo kernel fusi che sono sovraccaricati dai tipi di array per fornire molte delle funzionalità sopra menzionate. CUDAnative.jl consente di compilare il codice Julia in kernel GPU. ModelingToolkit.jl elimina automaticamente gli AST in un sistema simbolico per la trasformazione di codice matematico. Cassette.jlconsente di "sovraincidere" la funzione esistente di qualcun altro, utilizzando le regole per modificarne la funzione prima del tempo di compilazione (ad esempio: modificare tutte le allocazioni di array in allocazioni di array statiche e spostare le operazioni nella GPU). Si tratta di strumenti più avanzati (non mi aspetto che tutti coloro che eseguono elaborazioni scientifiche assumano il controllo diretto del compilatore), ma questo è il modo in cui viene costruita la maggior parte degli strumenti di prossima generazione (o meglio, come si scrivono le funzionalità).

Per quanto riguarda il parallelismo, ho menzionato le GPU e Julia ha integrato il multithreading e il calcolo distribuito . Il multithreading di Julia utilizzerà molto presto un'architettura PARTR (parallel-task runtime) che consente la pianificazione automatizzata del multithreading nidificato . Se si desidera utilizzare MPI, si può semplicemente utilizzare MPI.jl . E poi, ovviamente, il modo più semplice per sfruttarlo è semplicemente usare una configurazione di tipo AbstractArray per usare il parallelismo nelle sue operazioni.

Julia ha anche l'ecosistema di base che ti aspetteresti da un linguaggio generico usato per applicazioni scientifiche. Ha l' IDE Juno con un debugger integrato con punti di interruzione , ha Plots.jl per creare tutti i tipi di grafici. Anche molti strumenti specifici sono utili, come Revise.jl aggiorna automaticamente le tue funzioni / libreria quando un file viene salvato. Hai il tuo DataFrames.jl , librerie statistiche , ecc. Una delle librerie più belle in realtà è Distributions.jl che ti permette di scrivere algoritmi generici per la distribuzione (ad esempio:rand(dist)prende un numero casuale di qualunque distribuzione sia passata), e c'è un intero carico di distribuzioni univariate e multivariate (e ovviamente l'invio avviene in fase di compilazione, rendendo tutto così veloce come codificare una funzione specifica della distribuzione). C'è un sacco di strumenti di gestione dei dati , server Web , ecc. A questo punto è abbastanza maturo che se c'è una cosa scientifica di base e ti aspetteresti che esista, devi solo cercarla su Google con .jl o Julia e verrà visualizzata.

Quindi ci sono alcune cose da tenere a mente all'orizzonte. PackageCompiler sta cercando di creare binari dalle librerie Julia, e ha già alcuni successi ma ha bisogno di più sviluppo. Makie.jl è un'intera libreria per la stampa accelerata con GPU con interattività, e ha ancora bisogno di un po 'più di lavoro, ma sta davvero cercando di diventare la principale libreria di stampa in Julia. Zygote.jl è una libreria di differenziazione automatica da sorgente a fonte che non presenta i problemi di prestazioni di un annuncio di traccia (Flux's Tracker, PyTorch, Jax) basato su traccia e che sta cercando di funzionare su tutti i codici Julia puri. Eccetera.

In conclusione, puoi trovare molto movimento in molti luoghi, ma nella maggior parte delle aree c'è già una solida libreria maturata. Non è più in un posto in cui si chiede "verrà adottato?": Julia è stata adottata da un numero sufficiente di persone (milioni di download) che ha lo slancio per rimanere per sempre. Ha una comunità davvero bella, quindi se vuoi solo sparare la brezza e parlare di calcolo parallelo o equazioni differenziali numeriche, alcune delle migliori chat room per quello sono nel Julialang Slack . Se è una lingua che dovresti imparare è una domanda personale, e se è la lingua giusta per il tuo progetto è una domanda tecnica, e quelli sono diversi. Ma è un linguaggio che è maturato e ha il sostegno di un ampio gruppo coerente di sviluppatori? Sembra un sì affermativo.

In caso contrario, è possibile fornire una stima approssimativa dell'ordine di grandezza per quanto tempo dovrei aspettare prima di considerarlo di nuovo?

La mia stima approssimativa, in ordine di grandezza, di quanto tempo impiega a maturare i linguaggi della scienza computazionale è di circa un decennio.

Esempio 1: SciPy è iniziato nel 2001 o giù di lì. Nel 2009, Scipy 0.7.0 è stato rilasciato e l'integratore ODE aveva un'interfaccia con VODE (che è l'equivalente di ode15s, approssimativamente; ode15sè basato su NDF, VODE è BDF / Adams-Bashforth, a seconda). Con SciPy 0.10.0, un'interfaccia a dopri5, che è all'incirca l'equivalente di MATLAB ode45, un metodo del quarto ordine di Runge-Kutta in genere ha introdotto come primo metodo pratico di integrazione numerica per gli studenti universitari. SciPy 0.10.0 è stato rilasciato nel dicembre 2011 e ci sono voluti circa 10 anni per includere una funzionalità di MATLAB introdotta in tutti gli studi di ingegneria che conosco.

Esempio 2: Mathworks è stata fondata nel 1984. Nella loro prima versione, hanno usato una porta LAPACK per C chiamata JACKPAC (dopo Jack Little, un ingegnere di MathWorks che l'ha scritto). Non lo sostituirono con LAPACK fino al 2000.

Julia potrebbe richiedere meno tempo, ma stimerei circa 10 anni dalla fondazione per diventare mainstream. (È già uscito da circa un anno; forse 9-10 anni, allora?)

Il sistema bibliotecario di Julia è completamente sviluppato in queste aree? In particolare, l'API è più o meno stabile per questi tipi di attività o troverei che il mio vecchio codice tenderebbe a rompersi dopo l'aggiornamento a una nuova versione di Julia?

Non uso Julia, quindi prendo quello che dico con un granello di sale, dato che ho visto Jeff Bezanson fare presentazioni su Julia. Si sono piegati all'indietro per semplificare il collegamento e l'uso delle librerie di C, Python e Fortran. Se non riesci a trovare una libreria Julia che fa ciò che desideri, scrivi uno shim Julia per una libreria in una lingua più consolidata. Di conseguenza, non credo che la mancanza di biblioteche sarà fonte di preoccupazione. Penso che una preoccupazione sarà assicurarsi che le modifiche alle funzionalità del linguaggio principale non ti mordano il culo. Se guardi le pietre miliari nel repository Julia Git, vedrai che il tag "breaking" viene usato abbastanza (12 volte nella versione 0.2, 5 volte nella versione 0.3). Per me, ciò suggerisce che il linguaggio principale è ancora in evoluzione, motivo per cui esito a usare il linguaggio in questo momento.

EDIT: Aurelius solleva un buon punto:

Cosa ti fa supporre che Julia diventerà mai veramente mainstream e non si spegnerà nell'oscurità come tante altre lingue? SciPy / numpy aveva / ha il supporto di una comunità di pitoni in continua crescita, che Julia non ha.

Nella risposta originale, ho deciso di evitare la domanda "Julia riuscirà a diventare mainstream?" per quanto possibile. Fallire è facile; il successo è difficile. Penso che il miglior confronto di Julia sia con linguaggi di calcolo tecnici come MATLAB, R e Octave. I linguaggi HPC (Chapel, Fortress, UPC, ecc.) Hanno un pubblico più ristretto rispetto ai linguaggi informatici tecnici e i linguaggi di uso generale (C, Python, C ++, ecc.) Hanno un pubblico più ampio rispetto ai linguaggi informatici tecnici.

Qualcosa che penso che aiuti Julia è il design per le prestazioni senza sacrificare l'espressività. Julia è molto più competitiva con i linguaggi compilati come C di MATLAB, R o persino Python. Questo obiettivo di progettazione è anche una caratteristica che può attirare persone dalle lingue esistenti, come:

• Le persone che si preoccupano molto di prestazioni e provengono da linguaggi come C e Fortran, ma sono disposti a sacrificare un piccolo po 'di prestazioni (forse un fattore di 2ish) per andare da linguaggio compilato a meno righe di linguaggio interpretato (insieme a un REPL per sviluppo e test più rapidi).
• Persone che hanno a cuore l'elevata produttività e provengono da lingue come Python, R e MATLAB, ma desiderano maggiori prestazioni. Quando si tratta di esecuzione, Python puro, MATLAB puro e R pura sono lenti. Gli sviluppatori di queste lingue hanno fatto di tutto per avvolgere le librerie in linguaggi compilati, ma non puoi avvolgere tutto e, a un certo punto, il linguaggio principale ti rallenterà. Core Julia è più veloce, il che ti consente di fare più scienza più velocemente.
• Le persone a cui interessa il software libero. Julia è interpretata e libera (così come Python, Octave, ecc.); MATLAB no.

Julia sta anche cercando di facilitare il parallelismo; Non mi sento terribilmente qualificato per espandermi su quel punto, e non penso che sia l'attrazione principale della lingua, ma penso che sia un punto di forza su cui stanno lavorando e spero che altri possano far luce su di esso.

Tuttavia, anche con il merito tecnico dalla loro parte, i creatori della lingua devono fare le gambe per promuovere la lingua ed evangelizzare. Jeff Bezanson, Alan Edelman, Stephen Karpinski e Viral Shah stanno lavorando molto duramente per far sì che la lingua abbia successo. Alan Edelman ha legami profondi con la comunità scientifica computazionale, e ha già lavorato a progetti a livello linguistico (in particolare, l'estensione Star-P a MATLAB). Jeff Bezanson ha fatto il circuito della conferenza per promuovere Julia a scienziati e ingegneri computazionali per un po '. Al MIT, hanno fatto un buon lavoro nel reclutare studenti e personale (in particolare, Steven G. Johnson) per contribuire con l'aggiunta di biblioteche a Julia. Hanno un articolo su Wired e sono riusciti a ottenere un articolo di Wikipedia per se stessi, il tutto solo dopo un anno. Il loro repository Git ha migliaia di stelle, centinaia di forchette, e centinaia di orologi, quindi secondo gli standard open source, il loro progetto è stato un successo. Penso che finora abbiano fatto tutte le cose giuste, quindi si tratta di sostenere tale sforzo e costruire comunità. Potrebbero ancora fallire, ma arrivare così lontano mi suggerisce che hanno ragionevoli possibilità di successo.

Credo che valga la pena imparare Julia. L'ho usato per produrre alcuni codici di elementi finiti per la ricerca e produrli molto rapidamente. Sono stato molto soddisfatto della mia esperienza.

Julia mi ha permesso un flusso di lavoro che ho trovato difficile da raggiungere con altre lingue. Puoi usarlo come un linguaggio di prototipazione come MATLAB, ma a differenza di MATLAB quando hai un codice funzionante e stai attraversando iterazioni di profilazione per accelerarlo, sostituire gli hotspot con il codice C è indolore. Hanno reso l'interfaccia con C (e Python) una priorità nella progettazione.

Quindi il linguaggio mi ha permesso di passare molto rapidamente dalle mie formulazioni matematiche al codice funzionale e quindi dal codice funzionale al codice altamente performante. Penso che questa caratteristica di Julia sia sottovalutata, ma aggiunge un valore straordinario.

In molti casi ho ottenuto prestazioni C (rispetto al mio codice C) nel giro di poche ore dopo aver prodotto un codice funzionale agli elementi finiti. Finora, se uso solo le funzionalità di Julia, di solito riesco a raggiungere ~ 3 volte più lentamente di C. Successivamente, sostituisco gli hotspot con le funzioni C (Julia viene fornito con un profiler di campionamento dello stack per aiutare a identificarli). Spesso ciò richiede solo la sostituzione delle righe di codice hotspot offensive con una "ccall", con Julia che gestisce l'eventuale marshalling.

Penso che le cose principali che Julia manchi in questo momento, anche se ciò mi esita a considerarlo per progetti più grandi, è la mancanza di un debugger pienamente supportato e uno scarso supporto per la stampa (in questo momento la tua scommessa migliore nella trama è in realtà solo un'interfaccia in matplotlib che mi sono rotto più spesso). Il feedback immediato sul codice è davvero importante. Inoltre non so come sopravvivere senza il debug interattivo, e a questo proposito sono molto viziato da MATLAB e GDB.

Dalla mia esperienza Julia non è ancora pronta per l'uso (scientifico) di tutti i giorni (sto parlando della versione stabilizzata 0.4 di marzo 2016). Il linguaggio stesso è gradevole, ricco di funzionalità e coerente; un rinfrescante passo avanti sia da Matlab che da Python. Vi sono certamente casi d'uso in cui Julia è una buona scelta anche in questa fase iniziale. Ma se hai bisogno di biblioteche scientifiche affidabili e mature non posso raccomandare di fare la mossa ora. I principali problemi che ho riscontrato sono:

• I pacchetti al di fuori del nucleo di Julia non sono affidabili. Si rompono con gli aggiornamenti, cambiano, vengono sostituiti, a volte sono incompleti o semplicemente rotti.
• Le caratteristiche del parallelismo di Julia (imo le caratteristiche più promettenti del killer matlab) sono immature. Incontrerai errori di segmentazione, perdite di memoria, arresti anomali e prestazioni deludenti. A volte non giocano bene con altre parti di julia, ad esempio alcuni solutori di sistemi lineari o pacchetti al di fuori del nucleo. Sebbene queste funzionalità sembrino promettenti, spesso non mi riescono abbastanza. Quasi mai è stato sufficiente scrivere semplicemente @paralleldavanti al ciclo for, dove in teoria dovrebbe.
• Molte piccole cose, piccoli bug e problemi con cui si potrebbe vivere: tracce dello stack di chiamate non così belle e talvolta errate, cronologia di un piccolo buggy, caricamento lento di pacchetti, cattive prestazioni di uno o un altro pacchetto / funzione, ecc. Cosa mi ha infastidito la maggior parte è il pacchetto PyPlot, un wrapper per matplotlib, attualmente non c'è alternativa ad esso. È davvero bello che sia lì e per lo più funziona. Ma se devi tracciare i dati, preparati a prestazioni e problemi molto lenti.

Tutto andrà meglio. Sono fiducioso che un giorno julia sarà superiore a matlab e pitone in quasi tutti gli aspetti. È molto probabile che vengano sviluppati pacchetti innovativi per questo. Sembra che ci sia già una grande comunità. Anche ora esiste una vasta gamma di pacchetti con casi d'uso che vanno dall'opencl ai server web. L'uso delle librerie python o c è molto semplice, quindi probabilmente non colpirai un muro in termini di disponibilità delle librerie. Un grande punto di forza di Julia sarà la facilità con cui si possono incollare funzionalità ad alte prestazioni da varie fonti in un linguaggio moderno e coerente di alto livello (vedere le risposte sopra). Ma nel complesso ho trovato che non era né maturo né abbastanza stabile per essere utilizzato in modo produttivo.