Arch Linux termina oggi il supporto ai pacchetti i686

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/sistemi...686_72255.html

Arch Linux non offrirà più, a partire dalla giornata di oggi, il supporto ai pacchetti compilati per architetture i686 e, pertanto, destinati ai processori a 32 bit. Il futuro è a 64 bit anche per il Pinguino

Click sul link per visualizzare la notizia.

[s-y]

beh, oddio, oltre che il futuro, il presente, ma anche il passato...
che, specialmente in passato, non fosse sto gran vantaggio e a volte anzi, ok, ma le versioni 64 bit ci sono da un pochinello di tempo, anche da prima rispetto ad altri os (per quanto non sia una gara e cmq è soprattutto la modularità del pinguino che ha permesso di 'migrare' prima)

[mattia.l]

e la i786? non era a 32bit anche quella?

[matrix83]

Originariamente inviato da mattia.l

e la i786? non era a 32bit anche quella?

i686 è un termine generico per indicare qualsiasi 32bit, quindi anche quello

[silviop]

ha ancora molto da dire nel mondo aziendale e infatti windows 10 LTSB 2016 esiste a 32bit (e sara supportato per altri 10anni),non capisco tutta questa fretta delle distribuzioni di abbandonare i 32bit x86, che comunque saranno supportati PER SEMPRE dal kernel linux,
spero che almeno ubuntu 18.04 LTS abbia ancora la versione server a 32bit almeno staremo tranquilli fino al 2023.

[fano]

Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?

[Marco71]

...la prima cpu Intel a disporre di architettura completamente a 32 fu il glorioso 80386 con i suoi circa 275000 transistor integrati.
Per "i686" si intende la prima microarchitettura x86 con esecuzione delle istruzioni "fuori ordine"...una grande "famiglia" che iniziò con il processore Pentium Pro.

Marco71.

[benderchetioffender]

x64 a livello consumer è arrivato nel 2003.... direi che x86 ha fatto il suo tempo, visto sopratutto che il 64bit puo gestire agevolmente il 32bit mentre non si puo nel contrario

[danieleg.dg]

Originariamente inviato da fano

Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?

Anche 32bit è troppo, torniamo a 8 così si consuma un quarto di ram!

[Yrbaf]

Non diciamo stupidate solo per muovere le dita.

Il futuro è a 64 bit ma 32 bit sono ancora sufficienti per una buona fetta delle applicazioni del presente e spesso le versioni a 64 bit se non sfruttano i 64 bit (o nel caso x86 i registri in più, cosa magari non vera in tutte le altre architetture a 64b) sono pure più lente della controparte 32b.

La ram ormai sarà poco costosa (in config oltre 4GB) ma le cache di primo livello dei processori non sono cresciute così tanto (come gli altri livelli) rispetto a quando si era solo a 32b.
Forse anche a livello di MMU c'è un carico maggiore nell'usare i 64b sempre anche quando non servono.

Senza contare che ci sono vecchie macchine che hanno il supporto a 64b ma la ram fisica limitata comunque a 3-4GB e obbligarle a passare alla versione a 64b dell'OS (che potrebbe girare) sarebbe forse solo una perdita di prestazioni e basta senza veri altri benefici.

[Opteranium]

era ora. Anche ubuntu li ha lasciati con la 17.10, ormai hanno fatto il loro tempo

[AleLinuxBSD]

Il problema principale dato dall'abbandono del supporto delle architetture a 32bit non viene dal supporto ai 64bit da parte delle Cpu, ma al livello di memoria Ram.

I computer super obsoleti non soltanto hanno una limitata quantità di Ram, chiedendo in negozio, te la vendono a peso oro.

Che poi questa decisione fosse inevitabile, considerando la grande dispersione di risorse in ambito Linux, era scontato.

Considerando poi la micidiale combinazione costituita dall'avvento di Wayland, nonché di applicazioni videoludiche che fanno uso di recenti standard non supportati neanche da hardware relativamente recente, il cambio a 64bit rappresenta pure il minore dei mali.

[s-y]

cmq sia la arch è sempre stata 'drastica' su questi aspetti. ad esempio non supportava già ai tempi gli i386 (da pentium pro a scendere), e non credo sia da prendere come esempio tipico del mondo pinguinesco

[Phoenix Fire]

secondo me ha fatto bene, come detto da AleLinuxBSD, già le risorse mancano, se devo anche disperderle...
che poi come spiegato nell'articolo, non è che hanno "bloccato" la cosa, se la community vuole può continuare a svilupparseli lei, ma almeno io "distro" posso concentrare meglio le risorse

[s-y]

si, avevano preannunciato la cosa con anticipo motivando proprio con la difficoltà a manutenere entrambe le versioni

tra l'altro come specificato la v 32 è stata 'comunityzzata', e la serietà degli arch user esperti dovrebbe garantire una buona qualità di release, anche se da capire come proseguirà la cosa

[WarDuck]

Originariamente inviato da fano

Alla fine se non ha applicazioni scritte col c*lo che necessitano di più di 4 GB solo loro per funzionare, 64 bit non serve mica a molto!
Anche .NET di default compila con "prefer 32 Bit" che su Windows 64 Bit funziona alla perfezione (con WoW64), su Linux visto che l'architettura "ibrida" 32 / 64 non sono stati capici a farlo Mono ignorava il flag ed andava sempre a 64 Bit.

Lo sapete sì che alla fine il risultato più "tangibile" di avere applicazioni a 64 Bit è che usano il doppio della RAM?

Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.

[fano]

Sì ma il doppio dei registri non è un vantaggio dei 64 bit era x86 che faceva un po' schifo c'erano processori a 32 bit (tipo ARM e forse pure M68K!) che di registri ne avevano comunque 32 o 64... mica 8!

Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.

L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.

La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".

[Yrbaf]

Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.

32 registri (limitandoci agli interi, visto che sopra non ho contato gli FP) li avevano/hanno MIPS (in realtà 1 è un registro fisso a zero), PowerPC, Power di IBM, Dec Alpha, Sun/Oracle Sparc e gli Arm quando operano nella modalità a 64 bit (quindi Arm come x86 vede un raddoppio dei registri passando in ABI64).

PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.

[cdimauro]

Originariamente inviato da Yrbaf

Non diciamo stupidate solo per muovere le dita.

Il futuro è a 64 bit ma 32 bit sono ancora sufficienti per una buona fetta delle applicazioni del presente e spesso le versioni a 64 bit se non sfruttano i 64 bit (o nel caso x86 i registri in più, cosa magari non vera in tutte le altre architetture a 64b) sono pure più lente della controparte 32b.

Sfruttare i registri in più di x64 è molto più semplice, nonché comune ed effettivamente usato, che sfruttare i 64 bit. Basta disassemblare un po' di applicazioni per rendersene conto.

Eseguibili IA-32/x86, con soli 8 registri a disposizione (in realtà 7, perché uno riservato allo stack), sono pieni di istruzioni PUSH e POP per salvare e ripristinare registri, a cui si aggiungono vagonate di istruzioni che referenziano locazioni nello stack.

Eseguibili per x86-64/x64, invece, presentano di gran lunga meno casi del genere, e un notevole sfruttamento degli 8 registri in più.

Applicazioni a 64 bit che girano più lentamente delle equivalenti a 32 bit ce ne possono essere, senz'altro, ma sono una minoranza. In genere un'applicazione a 64 bit gira il 10-15% più velocemente della stessa, ma a 32 bit.

La ram ormai sarà poco costosa (in config oltre 4GB) ma le cache di primo livello dei processori non sono cresciute così tanto (come gli altri livelli) rispetto a quando si era solo a 32b.

No, ma quelle L2 e, soprattutto, L3 sono cresciute molto, e quindi mitigano molto l'accresciuta dimensione del codice (in genere il codice x64 è del 20-25% più grande di quello x86) e il raddoppio della dimensione dei puntatori (che è il problema primario quando si passare a un'ISA a 64 bit).

Forse anche a livello di MMU c'è un carico maggiore nell'usare i 64b sempre anche quando non servono.

Sì, ed ed è sempre tutto legato alla maggior dimensione del codice e dei dati.

Senza contare che ci sono vecchie macchine che hanno il supporto a 64b ma la ram fisica limitata comunque a 3-4GB e obbligarle a passare alla versione a 64b dell'OS (che potrebbe girare) sarebbe forse solo una perdita di prestazioni e basta senza veri altri benefici.

Con 4GB in genere si va abbastanza bene con s.o. & applicazioni a 64 bit.

Ovviamente dipende anche da quante se ne fanno girare, e di che tipo.

Originariamente inviato da WarDuck

Avere uno spazio di indirizzamento più ampio non vuol dire solo poter usare più RAM, ma anche sfruttare più bit per l'algoritmo di randomizzazione degli indirizzi logici (ALSR).

Le applicazioni 64 bit sono tendenzialmente più sicure delle stesse compilate a 32 bit.

Inoltre in x86_64 hai a disposizione il doppio dei registri, con tutti i benefici di ciò.

Il fatto che le applicazioni 64 usino il doppio della RAM non è un assoluto: sono i puntatori ad occupare il doppio.

Motivo per cui hanno sviluppato l'ABI x32, per il supporto ai registri a 64 bit con indirizzi a 32 bit.

*

Anche se purtroppo è un'ABI che viene usata troppo poco.

Originariamente inviato da fano

Diciamo pure che x86 è nato male cresciuto peggio e che x64 cerca di metterci delle pezze, ma è un po' un casino di architettura.

x64 è una pezza in tutti i sensi, perché il lavoro che hanno fatto lascia il tempo che trova.

Comunque il problema più grosso di x86/x64 è rappresentato dai decoder. Ma una volta che le istruzioni sono state tradotte in micro-op, il backend è poco influenzato dal "legacy".

L'ABI 32x che io trovo una soluzione interessante per uso "desktop" sembra come al solito essere stata abbandonata su Linux almeno io non la vedo molto pubblicizzata... non me la sentirei sinceramente di usarla in produzione: già i driver sono pochi figuriamoci per la versione "esotica" 32x.

Purtroppo è proprio questo il problema: la scarsa adozione. Aggiungiamoci pure che Microsoft ha completamente ignorato quest'ABI.

E' un vero peccato, perché oggi si potrebbero tranquillamente utilizzare applicazioni x32 e x64, a seconda dei casi, sfruttando il meglio delle due ABI.

La stiamo valutando per Cosmos credo che a tendere sarà quella la "nostra" versione a 32 bit, supportare 8087, farli i "long" a mano scrivendo dentro 2 registri, menarsela a salvare tutto nello stack non ha molto senso quando processori 32 bit "puri" sono una nicchia della nicchia, magari avrà senso per particolari soluzioni embedded in cui sono usate m*rdate tipo "Galileo" o "Geode".

Infatti i 32 bit "puri" (x86) hanno senso sostanzialmente solo in ambito embedded ormai.

Originariamente inviato da Yrbaf

Per la precisione Arm (32bit) e M68K di registri generici ne hanno solo 16 (sempre meglio degli 8 di x86) e non 32 o più.

In realtà i 68K hanno 8 registri dati e 8 registri indirizzi. I registri, quindi, non sono "ortogonali" (utilizzabili indifferentemente).

Mentre in x64 (e x32) sono ortogonali.

PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.

Davvero molto interessante, grazie.

[fano]

Originariamente inviato da Yrbaf

PS
La JVM a 64 bit di Java usa la tecnica dei puntatori compressi.
I puntatori (interni non si ha accesso diretto ai puntatori in java) sono nativi a 64b ma finché non si richiedono più di 2/4GB di memoria per la JVM vengono compressi per stare in 32b, altrimenti i benchmark mostrano mediamente decrementi delle prestazioni (mi pare di aver letto -30%) per i software che non se ne fanno nulla di tanta ram ma con puntatori a 64b sfruttano di meno le cache.
Presumo (ma non lo so) che qualcosa di simile lo faccia anche Net.

.Net in realtà quando usato con "AnyCpu" si intende "Prefer 32 Bit" quindi se possibile il Jitter crea istruzioni a x86 proprio per il problema di non usare troppa memoria.
Non è x86 "puro" visto che hanno iniziato ad usare comunque SSE per operazioni floating point e vettoriali, ma non può nemmeno essere chiamato x32... è una via di mezzo.

Durante l'esecuzione le applicazioni .NET girano quindi o "nativamente" sulla CPU se l'OS è a 32 bit oppure usano WoW per girare a 32 bit su Windows 64, il Jitter può comunque decidere di ignorare il "consiglio" e far girare tutto a 64 bit se così desidera (su Linux 64 non c'è "LoL" quindi...), questo credo vale solo su x86 non so una CPU ARM64 può switchare tra 64 / 32 bit a runtime...

Questo può essere simile ai "compressed pointers" di Java: https://github.com/dotnet/coreclr/issues/555