Gli sviluppatori del kernel Linux pensano all'abbandono dell'ABI x32
Gli sviluppatori del kernel Linux stanno pensando di abbandonare l'ABI x32, che permette di usare puntatori a 32 bit su sistemi a 64 bit con conseguenti vantaggi prestazionali, per via dell'utilizzo pressoché nullo
di Riccardo Robecchi pubblicata il 14 Dicembre 2018, alle 17:21 nel canale Sistemi OperativiLinux
L'ABI x32 su Linux è stata sviluppata alcuni anni fa per rendere più rapida la gestione dei puntatori rimanendo in un ambiente x86_64, ma gli sviluppatori del kernel Linux stanno pensando di rimuoverla per via dello scarso impiego.
Lo scopo dell'ABI x32 è quello di utilizzare registri e istruzioni dell'architettura x86_64 pur utilizzando puntatori a 32 bit, rendendo così migliori le prestazioni in quei casi in cui non sono necessari puntatori a 64 bit.
L'adozione dello standard è però stata decisamente ridotta, tanto che si può parlare di una assenza in pratica di software che usino l'ABI x32. Il supporto, però, è costoso in termini di tempo: gli sviluppatori del kernel devono continuare a supportare questa funzionalità anche se questa appare pressoché inutilizzata.
La discussione che sta avvenendo in questi giorni, riportata da Phoronix, riguarda quindi iil continuare a dare supporto a x32. Con lo stesso Linus Torvalds che è a favore dell'eliminazione di x32 e l'assenza di utenti enterprise, sembra che il destino di x32 sia ormai pressoché segnato - anche se l'ultima parola sarà detta in futuro.
29 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoè bastato chiamarlo, ed è arrivata
si' alla fine...
No, sono dal 5 al 10%: per l'1% non avrebbe avuto alcun senso introdurre una nuova ABI.
In linea teorica un'ABI del genere non dovrebbe comportare grossi problemi, ma dipende quasi esclusivamente da com'è stato scritto il codice. Se lo scrivi facendo certe assunzioni (es: sizeof(long) == sizeof(void *)), allora è chiaro che possono esserci problemi.
x32 ha il suo perché come ABI, perché consente di eseguire codice a 32 bit girando su un s.o. a 64 bit, traendo il vantaggio di entrambi i mondi (puntatori "corti" assieme al doppio dei registri GP & SIMD + PIC), e senza portarsi dietro tutte le problematiche di x86.
Meglio ancora sarebbe stato un s.o. a 64 bit con supporto trasparente per applicazioni x32, in modo da offrire binari ad hoc a seconda del tipo di applicazione, ottimizzando sia lo spazio su disco sia le prestazioni, visto che non serve poter avere tutte le applicazioni a 64 bit (e qui, specificamente, intendo applicazioni che abbiano ESCLUSIVAMENTE bisogno di indirizzare più di 4GB di memoria).
afaik il problema principale, al momento, è che serve ricompilare i pacchetti per abilitare, con anche qualche problema di convivenza con quelli 'normali', a meno di separarli, in un chroot ad esempio.
poi anche cercando eventuali distro compilate con x32, si trovano directory apparentemente semiabbandonate
intendo a livello utenti finali, mentre a livello di mantainers non sono in grado di 'sintetizzare', provato a seguire il thread su lkml.org ma è per me fuori portata...
potrebbe essere uno di quei casi dove la natura frammentata dell'ecosistema, è solo uno svantaggio
davvero nel 2018 abbiamo bisogno di puntatori a 32 bit per risparmiare memoria? oppure abbiamo bisogno di quel 5-10% di prestazioni in piu', che possono essere annullate rapidamente in millemila modi diversi ( uso di JS per scrivere applicazioni desktop )?
certo che se fai calcoli dalla mattina alla sera su giganteschi dataset da miliardi di entry, allora un suo perche' ce l'ha
ma per un uso generale, temo sia una soluzione ad un problema che non c'e'
tirando tirando, sui server puo' essere sensato, ma anche li' ci sono altre variabili in gioco
i cloudisti preferiscono risolvere tramite un complessissimo sistema di orchestrazione che consuma millemila cicli di cpu per fare cose che si potrebbero fare con uno script da due righe
viviamo in un mondo sprecone, qualche MB guadagnato in ram o un 5% di cicli di cpu in piu' non attirano tanta gente
facciamoci il callo e prepariamoci per l'invasione delle applicazioni che girano su Electron
spero che decidano per il meglio, ovvero ragionino su casi dove serve e vantaggi che porta in questi casi
afaik il problema principale, al momento, è che serve ricompilare i pacchetti per abilitare, con anche qualche problema di convivenza con quelli 'normali', a meno di separarli, in un chroot ad esempio.
poi anche cercando eventuali distro compilate con x32, si trovano directory apparentemente semiabbandonate
intendo a livello utenti finali, mentre a livello di mantainers non sono in grado di 'sintetizzare', provato a seguire il thread su lkml.org ma è per me fuori portata...
potrebbe essere uno di quei casi dove la natura frammentata dell'ecosistema, è solo uno svantaggio
Personalmente, e come già detto, l'unico problema che vedo è nel modo in cui sono stati scritti i progetti, perché altrimenti supportare x32 dovrebbe essere una bazzecola (è esattamente identica a x64, tranne per i puntatori a 32 bit).
Ma anche no: come già detto, si può sfruttare in TUTTI i casi in cui NON sia richiesto accedere a più di 4GB di memoria virtuale.
Direi di sì, considerato che l'IPC dei processori ormai cresce ben poco.
Questo non c'entra assolutamente nulla, perché appunto avviene già.
Non è che perché ci siano già tanti sprechi uno non debba pensare a risparmiare qualcosa quando può: è un ragionamento privo di senso.
ma per un uso generale, temo sia una soluzione ad un problema che non c'e'
tirando tirando, sui server puo' essere sensato, ma anche li' ci sono altre variabili in gioco
Può ed è sensato in quasi tutto, invece.
viviamo in un mondo sprecone, qualche MB guadagnato in ram o un 5% di cicli di cpu in piu' non attirano tanta gente
facciamoci il callo e prepariamoci per l'invasione delle applicazioni che girano su Electron
Come già detto sopra, sono prese di posizione prive di senso: lo spreco attuale NON può legittimare l'abolizione di strumenti che consentono, invece, di recuperare un po' spazio e prestazioni.
si come scrivevo pure io, penso sia uno dei casi dove la frammentazione (o 'frankeisteinizzazione') dei pacchetti rende più complicata l'implementazione
ad ora afaik (ma non ne ho esperienza diretta) oltre ai pacchetti specifici per poterlo fare, serve ricompilare a mano i pacchetti (che possono essere molti) per i quali si vuole abilitare
se ci fosse qualche distro che mette su un repo dedicato potrebbe essere più semplice (sempre lato end user) ma se non è stato fatto un motivo ci sarà (non retorica)
ripeto che non ho esperienza diretta sulla questione, potrei non essere preciso
Non temere, gli sviluppatori di Electron elimineranno il problema
Prima dovremmo pensare ad ottimizzare i software applicativi. Beh sicuramente con quel 5-10% si potrebbe colmare la voragine prestazionale introdotta dalle varie misure anti-Specter e compagnia.
No, ma costruire un'ecosistema software piu' sano porterebbe vantaggi ben maggiori.
:-/
Questo è un mantra che esiste dalla notte dei tempi informatici.
x32 nasce parecchi anni prima.
Il che, di nuovo, non ha nulla a che vedere con x32 e la sua abolizione.
Continui a trincerarti su un non-sequitur.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".