Gli sviluppatori del kernel Linux pensano all'abbandono dell'ABI x32

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 pubblicata il , alle 17:21 nel canale Sistemi Operativi
Linux
 

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.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

30 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
s-y14 Dicembre 2018, 17:55 #1
se non ricordo male i cosiddetti vantaggi prestazionali dovrebbero essere sul 1% ma a fronte della gestione (e patch da applicare) di un set aggiuntivo di librerie. alla fine credo che lo scarsissimo utilizzo dipenda da questo. detta in altre parole, massa casin per poca ciccia
bancodeipugni14 Dicembre 2018, 21:27 #2
ah vedi che una notizia su linux ogni tanto salta fuori ?

è bastato chiamarlo, ed è arrivata

si' alla fine...
cdimauro15 Dicembre 2018, 06:49 #3
Originariamente inviato da: s-y
se non ricordo male i cosiddetti vantaggi prestazionali dovrebbero essere sul 1%

No, sono dal 5 al 10%: per l'1% non avrebbe avuto alcun senso introdurre una nuova ABI.
ma a fronte della gestione (e patch da applicare) di un set aggiuntivo di librerie.

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.
alla fine credo che lo scarsissimo utilizzo dipenda da questo. detta in altre parole, massa casin per poca ciccia

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).
s-y15 Dicembre 2018, 10:56 #4
in effetti ricordavo male, e ho approfittato per riaggiornarmi un pò sulla questione (dopo un certo hype 5/6 anni fa se n'è parlato sempre meno)
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
pabloski15 Dicembre 2018, 18:56 #5
x32 non e' stata sfruttata perche' ha senso solo in un ambito molto ristretto

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
maxy0415 Dicembre 2018, 19:06 #6
Originariamente inviato da: pabloski

certo che se fai calcoli dalla mattina alla sera su giganteschi dataset da miliardi di entry, allora un suo perche' ce l'ha


Mh.... Secondo me ormai non c'è più nessuno che fa calcoli pesanti con x32, troppo vecchie, poco performanti e, a parità di potenza e volume dei server, troppo esosa
Phoenix Fire15 Dicembre 2018, 20:22 #7
notizia interessante che mi ha permesso di conoscere qualcosa di "nuovo"

spero che decidano per il meglio, ovvero ragionino su casi dove serve e vantaggi che porta in questi casi
cdimauro16 Dicembre 2018, 09:01 #8
Originariamente inviato da: s-y
in effetti ricordavo male, e ho approfittato per riaggiornarmi un pò sulla questione (dopo un certo hype 5/6 anni fa se n'è parlato sempre meno)
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).
Originariamente inviato da: pabloski
x32 non e' stata sfruttata perche' ha senso solo in un ambito molto ristretto

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.
davvero nel 2018 abbiamo bisogno di puntatori a 32 bit per risparmiare memoria? oppure abbiamo bisogno di quel 5-10% di prestazioni in piu',

Direi di sì, considerato che l'IPC dei processori ormai cresce ben poco.
che possono essere annullate rapidamente in millemila modi diversi ( uso di JS per scrivere applicazioni desktop )?

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.
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

Può ed è sensato in quasi tutto, invece.
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

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.
s-y16 Dicembre 2018, 11:12 #9
Originariamente inviato da: cdimauro
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).


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
pabloski16 Dicembre 2018, 11:32 #10
Originariamente inviato da: cdimauro
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.


Non temere, gli sviluppatori di Electron elimineranno il problema

Originariamente inviato da: cdimauro
Direi di sì, considerato che l'IPC dei processori ormai cresce ben poco.


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.

Originariamente inviato da: cdimauro
Non è che perché ci siano già tanti sprechi uno non debba pensare a risparmiare qualcosa quando può: è un ragionamento privo di senso.


No, ma costruire un'ecosistema software piu' sano porterebbe vantaggi ben maggiori.

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".

La discussione è consultabile anche qui, sul forum.
 
^