The Signal
Qiskit 2.6 porta i pass di compilazione personalizzati nella sua API C
Qiskit 2.6 aggiunge all’API C il supporto per i pass di compilazione personalizzati, la serializzazione dei circuiti e le operazioni quantistiche definite dagli utenti. La nuova versione rende inoltre QPY v18 il formato predefinito e porta
Quantum.world Team · Scritto con l’IA · verificato ·
Il team di Qiskit di IBM ha pubblicato il riepilogo della versione v2.6 il 22 ottobre, descrivendo uno stack di compilazione che espone una parte maggiore dei suoi meccanismi attraverso un’API C. La versione 2.6.0 dell’SDK è stata rilasciata il 16 ottobre; il 22 ottobre è seguita la patch 2.6.1. La novità principale non è un nuovo algoritmo quantistico, ma una serie di strumenti per costruire e trasferire programmi quantistici da ambienti che usano linguaggi compilati.
«Qiskit v2.6 è, soprattutto, una versione incentrata sull’API C», scrive il Qiskit Team nel riepilogo della nuova versione pubblicato da IBM Quantum. L’aggiornamento consente a chi usa l’API C di definire pass di compilazione, comporre pipeline con controllo dei tipi tra rappresentazioni intermedie, serializzare circuiti in QPY e aggiungere operazioni personalizzate senza dipendere dal modello a oggetti di Python.
I gestori dei pass arrivano nell’API C
Il supporto precedente dell’API C consentiva agli sviluppatori di costruire circuiti ed eseguire la pipeline di transpilazione preconfigurata di Qiskit. La versione 2.6 aggiunge un framework per scrivere e comporre pass personalizzati tramite un QkPassManager. Ogni pass dichiara la rappresentazione intermedia che accetta e quella che produce, permettendo al gestore di verificare che le fasi di una pipeline siano compatibili tra loro.
Le rappresentazioni integrate comprendono attualmente QkCircuit e QkDag; gli sviluppatori possono anche definirne di proprie. Questa struttura consente a un programma di passare attraverso più rappresentazioni man mano che la compilazione procede, anziché limitare chi usa l’API C a un unico flusso di lavoro preconfigurato. La funzionalità si basa sul lavoro sul compilatore a rappresentazioni multiple introdotto nella v2.5.
QPY trasferisce i circuiti tra linguaggi
Il formato binario QPY di Qiskit è ora disponibile tramite l’API C. I programmi possono scrivere circuiti in un file o in un buffer di memoria e ricaricarli senza passare da Python; i file risultanti restano compatibili con l’interfaccia qiskit.qpy di Python. Si apre così la possibilità, per i programmi scritti in linguaggi compilati, di salvare i circuiti tra un’esecuzione e l’altra o preparare file da analizzare successivamente in Python.
La versione 2.6 rende inoltre QPY v18 il formato predefinito. La codifica dei registri di questa versione può ridurre le dimensioni dei file, con i maggiori risparmi attesi per i circuiti che contengono registri molto grandi o molti registri classici. Le versioni precedenti di Qiskit potrebbero non riuscire a caricare i file scritti in v18: chi ha bisogno della compatibilità con le versioni precedenti può quindi selezionare una versione precedente del formato quando salva un circuito.
Le operazioni personalizzate non richiedono oggetti Python
La nuova versione consente inoltre a chi usa l’API C di definire operazioni, inclusi gate personalizzati, e aggiungerle ai circuiti o ai grafi aciclici diretti. Un’operazione personalizzata usa una vtable per fornire caratteristiche come il nome, il numero di qubit e la definizione. Sono obbligatori soltanto il nome e il numero di qubit; ai comportamenti facoltativi omessi vengono assegnati valori predefiniti.
Gli sviluppatori possono così rappresentare i gate nativi dell’hardware direttamente in un circuito senza creare oggetti operazione in Python. La portata potenziale dell’API C va oltre il linguaggio C: IBM descrive la possibilità di accedervi da C++, Julia o Fortran tramite le rispettive interfacce per chiamare funzioni C.
Per ora Python resta una dipendenza
Qiskit 2.6 porta avanti il lavoro per eliminare il requisito di installare Python per usare la libreria C autonoma, ma non lo completa. In modalità autonoma la libreria non avvia l’interprete Python, eppure richiede ancora che Python sia installato perché alcune parti del modello di dati Rust di Qiskit fanno riferimento a tipi Python. IBM afferma di voler completare l’eliminazione di questa dipendenza in fase di linking nella v2.7.
Altri dettagli dell’aggiornamento sono importanti per chi cura la manutenzione: la v2.6 mantiene Python 3.10 come versione minima, ma è l’ultima versione di Qiskit a supportarla; la v2.7 richiederà Python 3.11 o una versione successiva. La compilazione dal codice sorgente richiede ora Rust 1.89, mentre per chi installa wheel precompilati non cambia nulla. IBM afferma inoltre che l’API C non è ancora dichiarata stabile, sebbene le modifiche tra la v2.5 e la v2.6 siano soltanto aggiunte.
La patch del 22 ottobre risolve quattro problemi
La patch Qiskit 2.6.1, rilasciata quello stesso giorno, comprende quattro correzioni segnalate: una gestione più sicura dei byte null interni in CString::new nell’estensione C, correzioni ai wrapper Python del decompositore a due qubit, un’impostazione di compilazione di mimalloc e la conservazione dello stato di controllo nelle operazioni di elevamento a potenza per tre gate controllati. La patch lascia intatte le principali aggiunte al compilatore della v2.6.
Per gli sviluppatori che devono decidere quando adottare le nuove interfacce, la distinzione è chiara: l’API C ora supporta pipeline di compilazione personalizzate e la serializzazione dei circuiti, ma IBM non ha ancora dichiarato stabile l’interfaccia. I team che usano QPY tra versioni diverse devono inoltre tenere conto dei file v18, mentre i progetti basati su Python 3.10 dovranno passare a un interprete più recente prima di Qiskit 2.7.