Con Python direttamente su hardware

Un bel giorno RobertoA digitò:

Mi sfugge qualcosa?

"Una toolchain personalizzata compila un file .py in CPython ByteCode, lo traduce in un assembly personalizzato e produce un binario che viene eseguito su un processore pipeline costruito da zero"

Quindi hai un IDE che compila il tuo codice sorgente e carica il binario sulla CPU, come avviene con qualunque altro IDE basato su C/C++.

Poi non dubito che la loro suite di compilatore+FPGA sia più efficiente rispetto al JIT del MicroPython fatto girare su un processore generico, ma pubblicizzarlo in questo modo denota un certo atteggiamento da cazzari da parte loro.

E poi anziché confrontare le prestazioni con un compilatore JIT, semmai dovrebbero confrontarle con altre soluzioni più simili, come ad esempio:

Nucleo+STM32CubeIDE, Arduino+Arduino IDE, ESP32 devboard+PlatformIO, PIC16F devboard+MPLAB, MSP430 Launchpad+CCS...

Il 02/09/2025 17:47, dalai lamah ha scritto:

Se non ho capito male, si tratta di una CPU virtuale in una FPGA, quindi non proprio una qualsiasi altra CPU. Non ho idea di quello che fanno, ma potrebbero addirittura personalizzare la CPU, la memoria e le periferiche attorno per ottimizzare la tua applicazione Python.

Ma queste sono soluzioni che permettono di scrivere codice Python? Perché la loro soluzione ha senso se vuoi scrivere in Python. Non ha senso confrontare le soluzioni classiche C/C++ con la loro soluzione.

Il 04/09/2025 08:54, pozz ha scritto:

Si, la scheda e' una Digilent 410-346-20, programmata per farci girare programmi scritti in Pyton

Il 02/09/2025 17:47, dalai lamah ha scritto:

Forse ti sfugge il 'dove' viene eseguita la traduzione da Python a binario, perche' tu ipotizzi che venga fatta fuori con la normale catena di programmazione e venga spedito il binario alla scheda Ma potrebbe essere che la catena di programmazione sia dentro E le varie compilazioni e linkaggi vengano eseguiti al volo prima dell'esecuzione Fosse cosi, sarebbe comunque un buon esempio di efficentamento del processo di programmazione della scheda

Un bel giorno pozz digitò:

RobertoA aveva chiesto sistemi simili alternativi per "linguaggi comunemente utilizzati", non mi sembrava specificamente interessato al Python.

Loro focalizzano il loro ragionamento sulle performance, dicendo che la loro soluzione (che genera codice binario che gira direttamente su un processore, che sia custom o meno fa poca differenza) è trenta volte più veloce di una soluzione che adotta un compilatore JIT. Non mi sembra un paragone molto equo, semmai andrebbe confrontato con altre soluzioni che generano del codice binario, a prescindere dal linguaggio usato in origine.

Nella loro demo mostrano come abbiano una latenza di 480 ns sul pilotaggio di un GPIO, il che significa che se lo pilotassero continuamente ON-OFF otterrebbero una frequenza di circa 1 MHz. Puoi trovare facilmente dei thread su Internet dove gente dice di ottenere varie decine di MHz con dei comuni STM32 montati su una scheda Nucleo da pochi dollari.

Ovviamente questa scheda FPGA è un "dimostratore tecnologico" con costi inaccettabili per applicazioni reali, e il loro obiettivo sarà quello di produrre un ASIC in grandi volumi per ridurre i costi. Ma la mia domanda è: esiste veramente la necessità? Ci sono milioni di progettisti di hardware embedded che bramano così tanto di usare il Python al posto del C, anche a costo di avere prestazioni peggiori?

Un bel giorno RobertoA digitò:

Non l'ho ipotizzato, è quanto affermano loro. Qui c'è un video:

Il 04/09/2025 11:33, dalai lamah ha scritto:

Linguaggi comunemente utilizzati per sistemi desktop/web. Io lo interpreto con: non so scrivere e non voglio imparare a scrivere in C perché troppo difficile, ma sono un pover frontendista che fa siti web. Posso usare le tecnologie che già conosco nel mondo embedded?

E invece secondo me loro puntano proprio all'utilizzo di un linguaggio di altissimo livello come python, dove le performance sono drasticamente peggiori rispetto a linguaggi di più basso livello come il C (già sui desktop, figuriamoci sull'embedded).

E si vantano che la loro soluzione python è migliore delle altre soluzioni python.

E con Micropython?

Secondo me sì. Vedi anche tutto il filone dell'AI sviluppata in python su macchine desktop. Prestazioni di gran lunga peggiori se si utilizzasse C.

Il 04/09/25 13:10, pozz ha scritto:

Stai scherzando, vero? La tua frase dice: "Se usi C ottieni prestazioni peggiori" Diciamo che l'hai solo scritta male... Intendevi dire "sviluppando in python si ottengono prestazioni di gran lunga peggiori RISPETTO alla versione sviluppata in C". Giusto?

Il 04/09/2025 16:00, infar ha scritto:

Sì, ho scritto male :-D