Python vs Lua (4)

Ok, ho messo un po' in ordine i miei esperimenti con micropython ed ho raccolto il tutto in un repo su github. Ecco il link

https://github.com/depaolim/micropython_vs_lua

Ricapitolo il mio obiettivo:

1. costruire un eseguibile C++ che contenga un interprete rispettivamente python e lua (fase di "embedding")
2. esporre delle funzioni C++ che possano essere chiamate dall'interprete (fase di "extending")

L'esperimento preliminare è sostanzialmente riuscito, per cui provo a condividere qui alcune considerazioni sull'esperienza.
Premetto che non ho ancora fatto alcuna prova sull'effettivo utilizzo di memoria, sulla efficienza di elaborazione e neppure, cosa più importante, non ho ancora provato a far girare il tutto su una schedina hardware effettiva bensì mi sono limitato a far girare il tutto su PC linux
L'ultima avvertenza preliminare è che sia per micropython che per lua non li ho utilizzati in modo esteso.
Dopo tutte queste avvertenze veniamo ora ad una bella considerazione netta:

L'embedding di micropython è un pochino più complesso di quello di Lua. In compenso l'efficienza e la configurabilità di micropython mi paiono nettamente superiori.

Nessuna sorpresa: entrambi i comportamenti sono conseguenza di scelte di design ben precise e perfettamente giustificare per l'obiettivo che ciascuno dei due si pone.

Lua fa una scelta molto semplice e "pulita": localizza tutto lo stato di esecuzione (compresi i puntatori alle funzioni globali) in una struttura denominata Stack.
Per cui, come si può vedere nel file shell_lua.cpp tutta l'inizializzazione risulta concettualmente molto essenziale.
Utilizzando però in modo pervasivo lo Stack Lua ha i seguenti svantaggi:

1. introduce sistematicamente un ulteriore livello di indirezione in tutti gli accessi alla memoria
2. consente un controllo pressoché nullo sulle modalità di allocazione e gestione della memoria

La scelta di micropython è quasi opposta. Lo si nota analizzando il file shell_upy.cpp dove si vede chiaramente: allocazione esplicita dello heap, dello stack e, perfino, del garbage-collector: insomma varie istruzioni che "maneggiano" oggetti a basso livello solo per inizializzare e configurare il run-time dell'interprete. Tra l'altro la maggior parte di queste strutture risultano essere statiche e globali.

Ne risulta indubbiamente una maggiore complessità per un programmatore che voglia fare l'embedding di micropython rispetto a Lua

Ma ci sono motivi ben precisi di efficienza per l'uso di queste strutture statiche e il fatto che tutto ciò venga inizializzato esplicitamente è, in effetti uno dei punti di forza delle scelte architetturali di micropython: ognuna di queste configurazioni è sotto il pieno controllo dello sviluppatore!

Non dimentichiamo che micropython ha l'esigenza primaria di poter girare su schedine a microcontrollore per cui l'efficienza, in particolare nell'accesso alla memoria, è un imperativo fondamentale
A partire dal progetto su github (rilasciato con licenza MIT, per altro) ognuno può costruire un micropython ritagliato perfettamente "su misura" sulle caratteristiche dell'hardware su cui dovrà girare.
Solo per citare alcune delle moltissime possibili scelte di embedding posso costruire un micropython: che supporta o non supporta i thread, che supporta o meno le primitive matematiche, che gira senza garbage-collector o con un gc custom, che alloca lo stack sull'uno o l'altro supporto di memoria della schedina, etc. etc. In generale micropython non da nulla per scontato, neppure la disponibilità di un filesystem: per cui prevede di poter configurare il meccanismo di import dei moduli di python andando via via a reperire i moduli sui vari supporti di memoria (Tra l'altro ho notato, disseminati nel codice, vari "punti di misurazione" per controllare, passo per passo, ad esempio, l'occupazione di memoria).

La cosa straordinaria è che tutta questa configurabilità è comunque a fronte della messa a disposizione di un linguaggio decisamente esteso ed efficace come è python.
Insomma mi pare che la sfida di Damien George di quasi 5 anni fa sia stata sostanzialmente vinta: l'intero linguaggio python disponibile per girare su schedine ridottissime.
Damien inoltre mi risulta pienamente attivo sul progetto github coadiuvato da alcuni collaboratori che si sono via via aggiunti negli anni