Dopo ben 4 anni di successi (si sono toccate punte di 400 partecipanti) PyCon Italia ha ceduto temporaneamente il posto alla più prestigiosa EuroPython, evento internazionale svoltosi fra il 20 e il 26 (in realtà gli ultimi due giorni erano riservati agli “sprint”, ma ne parlerò meglio dopo), che si ritroverà a Firenze anche il prossimo anno.
Con circa 650 partecipanti e ben 7 tracce (di cui una in lingua italiana, omaggio alla nostrana PyCon, seconda soltanto all’EuroPython per affluenza nel continente) potete ben capire come sia stato molto difficile annoiarsi. La carne al fuoco era così tanta che a volte decidere quale talk seguire è stato un dilemma, sacrificando necessariamente qualcosa d’interessante.
Come ogni anno tutti gli interventi sono stati videoregistrati, per cui è sempre possibile recuperare quello che s’è perso. Rispetto a prima c’è da dire che i video sono stati messi a disposizione in tempi rapidissimi. E’ possibile, infatti, che siano ormai tutti presenti (basta aprire il relativo link su una pagina a parte e controllare se c’è il video embedded oppure un file torrent per scaricarlo).
Io ho tenuto un paio di talk (uno in italiano e uno nel mio maccheronico inglese) su un’idea balzana che m’era venuta in mente qualche mese e fa e che sono riuscito a completare in tempo per presentarla. Avremo modo di riprendere l’argomento fra un po’ di tempo, perché è mia intenzione scrivere una serie di articoli che esplorino il funzionamento e l’implementazione di una buona parte della virtual machine di Python (CPython).
D’altra parte compilatori, macchine virtuali, architetture degli elaboratori (CPU in particolare) sono interessi che coltivo da tempo, per cui, come potete immaginare, hanno influenzato pesantemente la scelta dei talk da seguire.
Quindi anche se i talk su Django (per chi non lo sapesse è il framework maggiormente utilizzato in Python riguardo allo sviluppo web, grazie anche alla forte “sponsorizzazione” di Google che l’ha posto alla base del suo App Engine) hanno dominato la scena (ce ne saranno stati una decina circa!), presentandolo in tutte le salse.
Diciamo che gli sviluppatori web avranno trovato pane per i loro denti, con parecchio nonché utile materiale da gustarsi, ma non essendo “di quelli” ho preferito evitare. E’ una grave mancanza, considerato che il web è divenuto parte integrante della nostra vita, ma al momento ho tutt’altro a cui pensare (però, come si suol dire, “del doman non v’è certezza”).
Le applicazioni web vanno spesso a braccetto coi database, e non sono mancati talk a riguardo, in particolare su PostgreSQL, presente ormai da anni a manifestazioni come questa, grazie anche al pregevole supporto presente per Python.
Ha fatto capolino anche qualche talk su Oracle, di cui è stato distribuito anche un DVD con un ambiente virtualizzato già pronto per potervi smanettare (cosa che conto di fare durante le ferie, spero), che purtroppo non ho potuto seguire. Grande assente, come sempre, MySQL; e a buon ragione, a mio avviso, visto che c’è di molto meglio come engine SQL (anche gratuiti / open source).
In un periodo in cui si fa gran parlare di morte (come sempre, solo annunciata) dei database relazionali, erano ovviamente presenti dei talk sui cosiddetti engine (paradigmi?) NoSQL, a cui… non ho potuto partecipare, ma avendo seguito un talk sulla completa riscrittura di Sourceforge (da PHP + MySQL sono passati a Python + MongoDB per problemi di manutenibilità e, soprattutto, scalabilità) e un altro sulla piattaforma di streaming musicale Spotify, qualcosa su di essi e il loro utilizzo l’ho sentita.
MongoDB ho già avuto modo di usarlo e quindi lo conosco (ho realizzato anche una piccola libreria a uso interno per semplificarne ulteriormente l’accesso da Python), mentre per Spotify (scritto per la maggior parte in Python, con qualcosa in Java e C/C++) hanno sfruttato Cassandra e PostgreSQL, e onestamente è l’intervento che mi ha colpito e apprezzato di più.
Il motivo è molto semplice: dopo tanto parlare di NoSQL di qua, db relazionali di là, in una netta contrapposizione ideologica e dicotomica, ci sono professionisti che presentano un prodotto vincente che li utilizza entrambi, sfruttandone i rispettivi punti di forza e, quindi, eliminando o limitandone fortemente i loro difetti, in una sinergia d’intenti che porta a una piattaforma stabile, robusta, efficiente e scalabile (e non è poco, avendo 15 milioni di brani e 10 milioni di utenti da gestire, con numeri in continua crescita).
Un altro tema fortemente dominante è stato quello delle elevate prestazioni in ambito scientifico, con diversi talk incentrati in particolare sullo sfruttamento delle moderne GPU allo scopo, scaricando sulle loro spalle l’enorme capacità di calcolo parallelo / distribuito necessaria in questi ambiti (la nostra Eleonora penso ne saprà qualcosa).
Non me ne voglia qualche collega che lavora nell’ambito delle GPU, ma sinceramente scrivere kernel per CUDA oppure OpenCL non è il massimo della semplicità e rapidità. Wrapper come PyCUDA consentono di eliminare parecchio codice “di supporto”, ma alla fine il kernel lo si deve scrivere necessariamente in C/C++ (verrà poi compilato al volo da PyCUDA, e passato alla GPU al momento dell’esecuzione).
Tutto ciò a un pythonista può non piacere, e men che meno a uno scienziato che non fa il programmatore di professione e vuole perdere pochissimo tempo per imparare un linguaggio perché, giustamente, vuol dedicarsi maggiormente alla sua professione (sarà per questo che Python è molto amato dagli astronomi, ad esempio).
Pertanto è stato veramente impressionante vedere all’opera un nuovo strumento allo scopo, CopperHead, che… permette di scrivere codice Python (per la precisione un sottoinsieme delle caratteristiche dell’intero linguaggio) che verrà automaticamente convertito in un kernel CUDA, con la possibilità di far girare lo stesso codice sulla CPU anziché sulla GPU, e il tutto in maniera assolutamente trasparente.
Tool del genere consentono di sviluppare velocemente un modello e di testarlo (grazie anche all’uso della shell interattiva di Python) il prima possibile anche su un PC senza GPU, per poi provare il codice finale su una scheda video adeguata. Anche per questo Python ha preso particolarmente piede pure in ambito economico, dove la dinamicità del mercato richiede sviluppi molto frequenti, e in poco tempo, di nuovi modelli (c’è stato qualche talk a riguardo sempre alla conferenza).
Il progetto non è ancora maturo, ma le potenzialità sono enormi, specialmente per chi, come dicevo prima, ha bisogno di concentrarsi sul suo lavoro perdendo poco tempo a imparare linguaggi di programmazione e relative problematiche. Per per rendersene conto basti guardare l’esempietto che è presente nella home page del sito del progetto:
from copperhead import * import numpy as np @cu def axpy(a, x, y): return [a * xi + yi for xi, yi in zip(x, y)] x = np.arange(100, dtype=np.float64) y = np.arange(100, dtype=np.float64) with places.gpu0: gpu = axpy(2.0, x, y) with places.here: cpu = axpy(2.0, x, y)
Una soluzione che si pone come compromesso fra PyCUDA e CopperHead è, invece, Theano, utilizzabile, al contrario del precedente, anche in produzione e che mette a disposizione alcuni tipi di dato predefiniti che possono essere manipolati con Python e convertiti poi velocemente (e in maniera trasparente allo sviluppatore) in kernel per CUDA. Il vantaggio, anche qui, è quello di non portarsi dietro tutto l’overhead richiesto da CUDA (e, in misura minore, da PyCUDA) nella scrittura del kernel.
Al solito una menzione non può che andare ai talk relativi a PyPy, progetto che in pochi anni ha permesso a Python di mostrare i muscoli anche sul piano prestazionale (impressionanti le dimostrazioni effettuate, con miglioramenti anche di un paio di ordini di grandezza!), e che ormai è abbastanza maturo da poter essere usato in produzione.
Di questo passo, e con tutte le caratteristiche introdotte finora, si propone come il candidato numero uno a prendere il posto dell’implementazione “mainstream” di Python (CPython). Se avete bisogno di velocizzare una vostra applicazione, è certamente la soluzione a cui guardare (utilissimo, in questo caso, è stato l’aver seguito il talk sulla scrittura di un emulatore Chip8 in Python), come pure se volete realizzare compilatori & macchine virtuali per altri linguaggi (è nato proprio per questo motivo, tra l’altro).
Gli ultimi due giorni sono stati dedicati ai cosiddetti sprint. Si tratta di riunioni di programmatori interessati a un particolare ambito (ad esempio CPython, PyPy, Django, SciPy, ecc.) che si tuffano in uno sviluppo “matto e disperatissimo” per implementare nuove caratteristiche (con esperti del settore; usualmente nella “tavolata” è presente qualche sviluppatore ufficiale a supporto / aiuto), oppure, ed è quello che va per la maggiore, per aiutare nei bug fix.
Ho partecipato allo sprint di CPython di sabato (domenica sono dovuto andare via, purtroppo), e devo dire che mi è stato molto utile il talk che Ezio Melotti ha tenuto sul ciclo di sviluppo di CPython e degli strumenti che si utilizzano, perché mi ha permesso di segnalare e fornire patch per un paio di semplici bug che ho individuato, facendomi quindi le ossa col sistema di ticket / issue messo in piedi dagli sviluppatori di CPython.
Tutte le belle storie hanno una fine, e purtroppo il tempo è volato via lasciando il posto ai piacevoli ricordi di quest’esperienza. Ma forse mia moglie e mia figlia hanno apprezzato di più perché, mentre partecipavo alla conferenza, erano in giro a visitare la stupenda Firenze…
