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

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/sistem...x32_79662.html

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

Click sul link per visualizzare la notizia.

[s-y]

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

[bancodeipugni]

ah vedi che una notizia su linux ogni tanto salta fuori ?

è bastato chiamarlo, ed è arrivata

si' alla fine...

[cdimauro]

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

[pabloski]

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

[Phoenix Fire]

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

[cdimauro]

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-y]

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

[pabloski]

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.

[cdimauro]

@s-y: non ho usato x32, per cui non saprei la situazione dei pacchetti e delle distro che la supportano.

Originariamente inviato da pabloski

Non temere, gli sviluppatori di Electron elimineranno il problema

:-/

Prima dovremmo pensare ad ottimizzare i software applicativi.

Questo è un mantra che esiste dalla notte dei tempi informatici.

Beh sicuramente con quel 5-10% si potrebbe colmare la voragine prestazionale introdotta dalle varie misure anti-Specter e compagnia.

x32 nasce parecchi anni prima.

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

Il che, di nuovo, non ha nulla a che vedere con x32 e la sua abolizione.

Continui a trincerarti su un non-sequitur.

[LukeIlBello]

io non capisco perchè NVIDIA si ostina a rilasciare le librerie per la compatibilità con linux (linulator), in ambiente BSD, solo a 32 bit
alla luce di tutte ste posizioni che vedono, giustamente, il progressivo abbandono dei puntatori a 32 bit.. mi aspetterei che escano le ABI emulate su FreeBSD only 64bit, o al max 32 e 64 bit.. ma SOLO a 32 bit che senso ha?

[fano]

Secondo me x32 era / è una buona idea, ma - ovviamente - su Linux non sono stati capaci a farlo funzionare per il casino che hanno sempre con i pacchetti software che sono legati mani & piedi al kernel

Un ulteriore ambito in cui è importante avere puntatori a 32 bit è in linguaggi managed come Java o C# dove praticamente tutto è un puntatore!

Infatti proprio per evitare un uso enorme di memoria (a volte più essere anche il doppio usando x64 senza alcun vantaggio vero e proprio!), Visual Studio di default compila le applicazioni .Net con "Prefer 32 bit"!

Un S.O. come Cosmos potrebbe usare tranquillamente x32 e la cosa bella è che il tutto sarebbe trasparente per le applicazioni!
Per me quello dovrebbe essere il kernel di "default".

[LukeIlBello]

Originariamente inviato da fano

Secondo me x32 era / è una buona idea, ma - ovviamente - su Linux non sono stati capaci a farlo funzionare per il casino che hanno sempre con i pacchetti software che sono legati mani & piedi al kernel

Un ulteriore ambito in cui è importante avere puntatori a 32 bit è in linguaggi managed come Java o C# dove praticamente tutto è un puntatore!

Infatti proprio per evitare un uso enorme di memoria (a volte più essere anche il doppio usando x64 senza alcun vantaggio vero e proprio!), Visual Studio di default compila le applicazioni .Net con "Prefer 32 bit"!

Un S.O. come Cosmos potrebbe usare tranquillamente x32 e la cosa bella è che il tutto sarebbe trasparente per le applicazioni!
Per me quello dovrebbe essere il kernel di "default".

perchè non lo fai "cross-platform" come alphawinux?

[fano]

Un sistema operativo basato su .Net è cross platform by design sicuramente lato applicazione e se il kernel è fatto come si deve anche il kernel sarebbe cross-platform per un buon 90%.

Ma non sono sicuro se quando uno cita alphawinux meriti una risposta seria

[s-y]

come scritto svariate altre volte, non ha senso giudicare un os nato per gioco (quasi letteralmente) come se fosse stato pianificato a tavolino

che poi la natura 'distriubuita' (o 'incasinata') renda più complicate modifiche a basso livello, è senza dubbio vero, come già scritto

alla fine quello che conta è, anche se non perfetto (posto che significhi qualcosa il concetto di perfezione) può essere cmq un valido os per molti casi? (non universalmente quindi) secondo me si, e se si pensa alle suddette premesse, non è tanto poco

penso anche che qualsiasi os, pure win, se venisse riprogettato da zero oggi, sarebbe più efficiente... bisogna vedere in prospettiva e/o a regime...

[fano]

Su questo sono perfettamente d'accordo... anche Windows ha il suo "bagaglio" di inificienze dovute alla retrocompatibilità con Win32/Win9x in buona parte!
(Win32 credo proprio fosse un accrocchio malvagio, manco sono sicuro fosse corretto definirlo un S.O. era più un "parassita" di DOS ).

[pabloski]

Originariamente inviato da fano

Secondo me x32 era / è una buona idea, ma - ovviamente - su Linux non sono stati capaci a farlo funzionare per il casino che hanno sempre con i pacchetti software che sono legati mani & piedi al kernel

Non mi pare che sotto Windows si possano creare eseguibili nativi multi-ABI. Se parli di .NET, pure gli eseguibili Mono o JVM sotto Linux presentano gli stessi vantaggi.

Semplicemente non c'e' domanda per un'ABI come x32, altrimenti avrebbe preso piede proprio in Linux, il cui ecosistema e' sempre stato poco orientato al conservatorismo.

[fano]

Sì su Windows a 64 posso far girare senza problemi applicazioni a 32 bit grazie a WoW (Windows on Windows), Microsoft non usa l'ABI x32, ma x86... anche se SSE1/SSE2 sono utilizzabile quindi non è poi tanto differente. Infatti proprio per risparmiare memoria molte applicazioni anche di Microsoft sono ancora a 32 bit su Windows (per esempio Visual Studio).

Per quanto riguarda "prefer 32" almeno quando testai con Mono su una CentOS non aveva funzionato nel senso che l'applicazione girava comunque a 64 bit, ignorare il flag è comunque "legale" visto che è appunto una "preferenza" quindi di per se Mono era compliant... non so se facendo accrocchi installando libreria a 32 Bit su Linux avrebbe funzionato... dubito, però

[pabloski]

Originariamente inviato da fano

Sì su Windows a 64 posso far girare senza problemi applicazioni a 32 bit grazie a WoW (Windows on Windows),

Che e' la stessa cosa che si fa con Linux installando le varie lib32-blahblah.

E rimane su entrambi i sistemi la necessita' di ricompilare i programmi ( nel caso di x32 ). Non e' che un programma x86_64 diventa magicamente x32. Il prefer 32 non ti aiuta in questo caso, perche' x32 vuole poter usare elementi di x86 ed elementi di x86_64 nello stesso eseguibile.

Per cui francamente non vedo dove stia la differenza tra Windows e Linux su questo tema.

Inoltre non va mai dimenticata la vera ragione di queste soluzioni, ovvero avere milioni di programmi a 32 bit da far girare su un sistema a 64 bit. Ma nel mondo Linux i porting del genere avvengono molto rapidamente, per cui non c'e' nemmeno domanda per una simile soluzione.