Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/gli-sviluppatori-del-kernel-linux-pensano-all-abbandono-dell-abi-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.

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

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

è bastato chiamarlo, ed è arrivata :ciapet:

si' alla fine... :sofico:

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

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

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

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

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

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).
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 :D

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

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

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


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.


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.

@s-y: non ho usato x32, per cui non saprei la situazione dei pacchetti e delle distro che la supportano.
Non temere, gli sviluppatori di Electron elimineranno il problema :D
:-/
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. :read:

Continui a trincerarti su un non-sequitur.

io non capisco perchè NVIDIA si ostina a rilasciare le librerie per la compatibilità con linux (linulator), in ambiente BSD, solo a 32 bit :muro:
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? :doh:

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

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

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

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? :asd:

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

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

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 :D ).

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

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.

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ò :D

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.

facciamoci il callo e prepariamoci per l'invasione delle applicazioni che girano su Electron :muro:

Tutto questo per permettere a qualunque capra di poter dire:"So programmare". Il che poi non è vero, ma tant'è.

Tutto questo per permettere a qualunque capra di poter dire:"So programmare". Il che poi non è vero, ma tant'è.

Purtroppo bisogna accettarlo. Per questo non c'e' domanda per x32. 5-10% di guadagno, quando dall'altra parte buttiamo bellamente l'acqua sporca con tutto il bambino.

Ci sono altri angoli da smussare pesantemente. Poi magari si potra' pensare ai virtuosismi come x32.

Purtroppo bisogna accettarlo. Per questo non c'e' domanda per x32. 5-10% di guadagno, quando dall'altra parte buttiamo bellamente l'acqua sporca con tutto il bambino.

Ci sono altri angoli da smussare pesantemente. Poi magari si potra' pensare ai virtuosismi come x32.

Però è anche vero che così penalizzi anche quei pochi che sanno davvero programmare, mentre le scimmie continueranno a premere tasti a caso comunque.

c'entra solo parzialmente, ma io (pur da incompetente sulla programmazione) rimpiango sempre più i tempi dei kernel 'preobesizzati', coi tarball dei sorgenti da 20 mega :fiufiu:

Però è anche vero che così penalizzi anche quei pochi che sanno davvero programmare, mentre le scimmie continueranno a premere tasti a caso comunque.

Parliamo veramente di pochi pochi pochi. Per esempio usare puntatori a 32 bit ti mette a disposizione uno spazio d'indirizzamento di sole 4G locazioni. E' facile immaginare quanto possano andare nel pallone milioni di programmatori che realizzano programmi gestionali di medie/grandi dimensioni. Non e' raro in questi casi sfruttare proprio l'enorme spazio d'indirizzamento a 64 bit ( ok 56 in realta' ) per mappare giganteschi database in memoria, riempire tabelle e listbox "virtualmente" con decine di milioni di elementi, ecc...

Per questo dicevo che il campo applicativo dell'ABI x32 e' quello degli specialisti di alto livello. Penso al HPC ad esempio. Ma in quel ramo chi pesa in memoria sono le gigantesche matrici non certo i puntatori.

Sono queste le ragioni mi fanno titubare sull'effettiva utilita' di un'ABI del genere. Cioe' mi sfugge il caso d'uso per un'ABI la cui una differenza rispetto a x86_64 sono i puntatori a 32 bit. Se hai un'applicazione che maneggia tantissimi dati, allora potresti avere tanti puntatori. Ma comunque la memoria e' piena di tantissimi dati, che impatto avranno mai i puntatori? Se hai pochi dati, hai pure pochi puntatori e allora comunque non consumi chissa' che.

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

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"!
This!
Purtroppo bisogna accettarlo. Per questo non c'e' domanda per x32. 5-10% di guadagno, quando dall'altra parte buttiamo bellamente l'acqua sporca con tutto il bambino.

Ci sono altri angoli da smussare pesantemente. Poi magari si potra' pensare ai virtuosismi come x32.
Mi riquoto, visto che a quanto pare sei "sordo":

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

Puoi benissimo smussare ciò che vuoi E (congiunzione) mantenere x32 dov'è utile. Le due cose NON sono mutuamente esclusive, logica (elementare) alla mano.
Parliamo veramente di pochi pochi pochi. Per esempio usare puntatori a 32 bit ti mette a disposizione uno spazio d'indirizzamento di sole 4G locazioni. E' facile immaginare quanto possano andare nel pallone milioni di programmatori che realizzano programmi gestionali di medie/grandi dimensioni. Non e' raro in questi casi sfruttare proprio l'enorme spazio d'indirizzamento a 64 bit ( ok 56 in realta' ) per mappare giganteschi database in memoria,
Parliamo di programmi di veramente grandi dimensioni. Dunque roba NON mainstream -> nicchie di mercato.
riempire tabelle e listbox "virtualmente" con decine di milioni di elementi, ecc...
Tabelle e listbox che contengano una tale massa di elementi sarebbero ben poco gestibili anche con un sistema a 64 bit.

In questi casi si usano grid e listbox "virtuali", che caricano soltanto i dati che servono (in genere solo quelli da visualizzare).
Per questo dicevo che il campo applicativo dell'ABI x32 e' quello degli specialisti di alto livello. Penso al HPC ad esempio. Ma in quel ramo chi pesa in memoria sono le gigantesche matrici non certo i puntatori.
E siccome le matrici sono gigantesche, per l'appunto, proprio l'HPC è l'ambito in cui x32 sarebbe IMPOSSIBILE da utilizzare. :rolleyes:
Sono queste le ragioni mi fanno titubare sull'effettiva utilita' di un'ABI del genere. Cioe' mi sfugge il caso d'uso per un'ABI la cui una differenza rispetto a x86_64 sono i puntatori a 32 bit. Se hai un'applicazione che maneggia tantissimi dati, allora potresti avere tanti puntatori. Ma comunque la memoria e' piena di tantissimi dati, che impatto avranno mai i puntatori? Se hai pochi dati, hai pure pochi puntatori e allora comunque non consumi chissa' che.
Il punto è proprio questo: TI sfugge. Ma la realtà è diversa, e infatti codice che fa uso di tanti puntatori è abbastanza comune. Il che NON implica che siano necessari più di 4GB di memoria.

Anche una pagina web ha una caterva di puntatori, ma un browser web NON richiede più di 4GB a pagina, visto che ormai da anni la tendenza è quella di isolare le singole pagine facendole girare ognuna in un apposito processo. Un browser web moderno potrebbe AMPIAMENTE nonché saggiamente utilizzare un'ABI come x32 consentendo di tenere aperte anche centinaia di tab/pagine/processi, con un notevole risparmio sia di spazio sia di prestazioni richieste.

E questo è solo un esempio, ovviamente.

Ti sfugge anche questo o te ne servono altri di esempi?

Puoi benissimo smussare ciò che vuoi E (congiunzione) mantenere x32 dov'è utile. Le due cose NON sono mutuamente esclusive, logica (elementare) alla mano.


Se è per questo si possono pure spendere 2 anni per ottimizzare un qualsiasi software. Ma il costo? Ne vale la pena? Il gioco vale la candela?

E per quel che vedo, sul fronte home/soho non frega a nessuno perchè tanto l'hardware è sovraproporzionato per i compiti che svolge. Sul fronte hpc ha un senso investire in x32, ma parliamo di un mercato microscopico in termini di quantità. Per questo credo che x32 potrà sopravvivere come patch set al di fuori del mainline, ma nulla di più.

Se è per questo si possono pure spendere 2 anni per ottimizzare un qualsiasi software.
Ovvio.
Ma il costo? Ne vale la pena? Il gioco vale la candela?
Puoi chiedere a Toninelli un rapporto costi / benefici. :asd:
E per quel che vedo, sul fronte home/soho non frega a nessuno perchè tanto l'hardware è sovraproporzionato per i compiti che svolge.
In tal caso, sempre logica elementare alla mano, non avrebbe alcun senso:
- perdere tempo a ottimizzare il software;
- la corsa a migliorare l'hardware.

Ma ho il non vago dubbio che, invece, entrambe le cose abbiano ancora motivo d'esistere.
Sul fronte hpc ha un senso investire in x32, ma parliamo di un mercato microscopico in termini di quantità.
Come già detto, in ambito HPC vengono processati enormi quantità di dati: quindi è ovvio che x32 NON possa assolutamente essere utilizzato.

Perché ti ostini a tirare in ballo x32 proprio in un caso in cui sia IMPOSSIBILE usarlo?!? Bah...
Per questo credo che x32 potrà sopravvivere come patch set al di fuori del mainline, ma nulla di più.
x32 ha DI GRAN LUNGA più senso in ambito consumer / mainstream, che in nicchie più ristrette come l'HPC o certi server che devono gestire grosse quantità di dati.

Un esempio pratico e comunissimo te l'ho fornito, ma te ne potrei riportare a palate.

Ciò che non capisco è questa tua presa di posizione del tutto irrazionale per screditare x32, che ha i suoi perché, e mi piacerebbe che, invece, venisse adottata anche da altri s.o., Windows incluso.

Io sono daccordissimo con cdimauro. Mi dispiace vedere un'altra tacca su linux causata dal suo stesso male. Pazienza, la politica di sviluppo quella è...

più che altro a quanto pare la coperta è corta, a quanto almeno mi pare siano state le motivazioni. tra l'altro sarebbe interessante, se fosse possibile ovviamente, sapere le discussioni interne alle multinazionali grosse sulla possibilità di implementare l'api in oggetto o meno :D