[IronPhyton] - ACCU Conference

[gugoXX]

Come promesso, ecco il link relativo alla presentazione IronPhyton dell'ultima ACCU conference (04/04/2008)


http://www.voidspace.org.uk/ironpython/ACCU2008/


Buona lettura

[variabilepippo]

http://www.voidspace.org.uk/ironpython/ACCU2008/

[cdimauro]

Grazie. Me lo spolpo appena ho un po' di tempo. :D

[cdimauro]

Con entrambi i figli a letto (e la moglie pure :p) finalmente ho avuto la possibilità di leggermi l'intera presentazione.

Che dire: mi sembra molto ben fatta per chi vuole sapere qualcosa di Python, ma in particolare di IronPython, e delle possibilità che offre all'intero di strumenti quali SilverLight.

L'integrazione .NET c'è, come avevo pensato, ma a senso unico: IronPython può consumare qualunque oggetto prelevato da assembly .NET, ma per gli oggetti prodotti da IronPython non vale il principio di reciprocità; quindi linguaggi come C# purtroppo non possono consumare oggetti generati da IronPython (anche se non mi è ancora chiaro quali siano esattamente le limitazioni).

Probabilmente in futuro verrà rimosso questo vincolo, con l'aggiornamento della CLR. MOOOOLTO interessante è il fatto che sarà aggiunto supporto diretto e pieno ai linguaggi dinamici con quella che viene definita DLR.
Questo è un passo estremamente importante, perché non solo faciliterà la scrittura di linguaggi dinamici che girano su .NET, ma permette di migliorare anche i tempi d'esecuzione.
Da questo punto di vista se alla Sun non si danno una mossa, la piattaforma Java rimarrà troppo indietro, ed è facile pensare che la sua popolarità ne risentirà non poco.

Infine, è stata una bellissima sorpresa leggere che YouTube è stato realizzato quasi interamente in Python (e ben prima che Google lo acquisisse), ma ancora più interessante, per quanto mi riguarda, è stato visitare questo http://research.microsoft.com/kt/ link.

[gugoXX]

cdimauro. Stasera ho conosciuto una persona che fa un lavoro che secondo me a te piacerebbe tantissimo.
Lavora come consulente per un'azienda il cui core-business e' andare in giro da chi li chiama (e fino li'), e che tipicamente ha un problema di performance.
Loro vanno li', studiano il problema, riscrivono gli algoritmi centrali preparandoli in modo da poter funzionare in ambiente multiprocess, tipicamente usando linguaggi funzionali o linguaggi che permettono la costruzione di alberi di esecuzione. Il tutto per sfruttare i pochi core/proc che si hanno ora, ma i tanti, tanti, tanti che avremo a breve
Lui e' l'addetto Python della faccenda.

Ha insegnato e scritto parecchi libri sul C++, ma da un po' si e' lanciato con il Python, del quale ha scritto anche un paio di libri, (e altri linguaggi vecchi, scritti per i multiproc dei mainframe degli anni 70 ma tornati attuali, dei quali neppure avevo mai sentito parlare)

Mi ha detto che ci sono grossi problemi con le virtual machine Python di oggi ad agire in multiprocess (come d'altronde per tanti altri come il Java), ma che ci sono parecchie spinte, anche da parte del mercato, per il rilascio di una virtual machine robusta in grado di parallelizzare bene i lavori. E lui sta partecipando ad un progetto della vecchia universita' in cui insegnava, proprio per la riscrittura del core di uno di questi dialetti.

Mi ha detto che stanno cercando, soprattutto per il versante Python (e F# e C#)
Vieni a farti una gita qui?

Ad ogni modo mi sa che presto si dovra' cambiare modo di programmare un po' tutti. Gli algoritmi sequenziali stanno per tramontare neppure troppo lentamente.

[cdimauro]

Un salto a Torino potrei anche farlo, ma a breve c'è il PyCon2 a Firenze, e ho già tutto prenotato (dal 9 all'11): magari è il luogo migliore per incontrarsi. Tra l'altro si parlerà anche di PyPy che è un progetto molto interessante.

Quanto alla VM di Python, è cosa nota che abbia problemi per il multiprocessing. Ne abbiamo discusso anche qui tempo addietro (è il famigerato problema del GIL, "Global Interpreter Lock"), e Marco aveva postato alcuni link interessanti, fra cui anche un progetto che sembra messo molto bene (e ben visto anche da Guido, il creatore di Python): http://www.parallelpython.com/

Per quanto riguarda il mio lavoro, ho affrontato e risolto le problematiche relativa al dispatch ed esecuzione parallela del codice in maniera diversa: se ho n core a disposizione lancio n processi, uno per ogni ben preciso core, e affido il load balancing al runtime di Ice (che è un framework per la creazione di middleware; simile a CORBA e SOAP, ma IMHO ben più efficiente e flessibile).

Il "costo" dell'operazione è che devo progettare il mio codice in modo tale che ogni applicazione sia del tutto "isolata" dalle altre. Inoltre c'è un maggior consumo di porte TCP (perché, per ogni PC), ma questo è trascurabile.

Ovviamente si tratta di soluzioni particolari, che vanno bene per i miei problemi. ;)