Stop allo sviluppo di Firefox in versione a 64bit

[type]

Originariamente inviato da ziozetti

Il futuro è a 64 bit ma il presente è assolutamente a 32 bit, sospendere il supporto ai SO a 32 bit è un suicidio.
C'è un mondo fatto di Windows XP aziendali fuori da questo forum.

Si, perchè tu pensi che sui pc aziendali, passa un tecnico ad aggiornare Firefox & Co. ogni volta che esce una versione nuova?

Quelli si tengono le vecchie versioni dei programmi finchè non gli muore il pc. Ci sono dei posti che viaggiano ancora con Windows 98.

[carabas]

Mi pare sia stata anche la scelta di Chrome, però creando un processo distinto per ogni tab (2GB per pagina sono ancora difficili da raggiungere).
Secondo me è stata una scelta pragmatica dettata dalle difficoltà nel debug del codice a 64 bit, optando naturalmente per il forking per ciascun nuovo tab.

[LMCH]

Originariamente inviato da Benjamin Reilly

in cosa prevalgono praticamente i sistemi a 64 bit rispetto a quelli a 32?

In primo luogo la quantità di memoria indirizzabile.
Un S.O. a 64bit anche se fa girare solo applicazioni a 32bit può sfruttare più di 4GB di ram per il caching dei dati o per permettere a più applicazioni che usano 1..2GB di ram ognuna di girare completamente in ram anche se complessivamente superano i 4GB.
Con applicazioni tipo Office o IE/Firefox non si notano grandi vantaggi, ma se si fa editing di video, fotoritocco a qualità di stampa di roba grossa e cose simili la differenza può essere notevole.

Poi il set d'istruzioni a 64bit (per quel che riguarda gli x86) fornisce 16 registri interi a 64bit invece degli 8 accessibili in modalità a 32bit, inoltre è garantita la presenza di 16 (invece di 8 come in modalità 32bit) registri XMM a 128bit di SSE/SSE2.
Questo torna molto utile per aumentare di fino al 30% l'efficenza del codice assembly a partire dagli stessi sorgenti in C/C++ o compilati Jit da sorgenti Java o di linguaggi .Net

[coschizza]

Originariamente inviato da LMCH

Poi il set d'istruzioni a 64bit (per quel che riguarda gli x86) fornisce 16 registri interi a 64bit invece degli 8 accessibili in modalità a 32bit, inoltre è garantita la presenza di 16 (invece di 8 come in modalità 32bit) registri XMM a 128bit di SSE/SSE2.
Questo torna molto utile per aumentare di fino al 30% l'efficenza del codice assembly a partire dagli stessi sorgenti in C/C++ o compilati Jit da sorgenti Java o di linguaggi .Net

questo pero a livello teorico perche a livello pratico grazie alla OoO del processore e la funzione di rinomina dei registri fa si che alla fine i registri realmente diponibili per contenere i dati siano molti di piu e il vantaggio di prestazioni si ha solo per certi tipi di elaborazioni. Inolte il codice a 64bit occupa piu spazio fisico sia come sorgente che come ram occupata e banda verso la cache quindi per certe tipi di elaborazioni si ottiene anche un risultato peggiore dello stesso codice a 32bit. L'unico caso dove i vantaggi sono evidenti sono qundo si usano le unita mmx sse ecc per il resto si ha un susseguirsi di pareggi vittorie e sconfitte in base al codice utilizzato.

Molto dipende anche dalla ram del sistema se guardi benchmark con un pc da 2GB vedi che perde quasi nella totalita dei casi quando usa un SO a 64bit mentre solo da 4GB in su a parità di hardware e software la situazione si ribalta.

[Benjamin Reilly]

quindi un sistema completamente a 64 bit dovrebbe risultare più performante.

[Pier2204]

Originariamente inviato da The_misterious

qui mi sembra più un'abbandono per motivi "tecnici".
Dato che l'unica versione a 64 bit a venire "eliminata" è quella per Windows penso che ci sia un motivo serio dietro.
Le altre versioni (per Linux e MacOS) sono tutte a 64 bit.

Ci scommetto le palle da flipper che adesso è colpa di Microsoft.

[LMCH]

Originariamente inviato da coschizza

questo pero a livello teorico perche a livello pratico grazie alla OoO del processore e la funzione di rinomina dei registri fa si che alla fine i registri realmente diponibili per contenere i dati siano molti di piu e il vantaggio di prestazioni si ha solo per certi tipi di elaborazioni. Inolte il codice a 64bit occupa piu spazio fisico sia come sorgente che come ram occupata e banda verso la cache quindi per certe tipi di elaborazioni si ottiene anche un risultato peggiore dello stesso codice a 32bit. L'unico caso dove i vantaggi sono evidenti sono qundo si usano le unita mmx sse ecc per il resto si ha un susseguirsi di pareggi vittorie e sconfitte in base al codice utilizzato.

Per questo ho parlato di un miglioramento sino al 30% (che non è poco, ma che è il miglioramento medio più elevato che si riscontra in pratica).

Come avevo scritto prima, in modalità a 64bit le SSE e le SSE2 sono disponibili "di serie", ma anche il raddoppio dei registri indirizzabili direttamente è significativo, solo che non lo è tanto se si fa il confronto con x86 + SSE2.

Anche con esecuzione out-of-order passare da 8 a 16 registri permette di migliorare le prestazioni perchè si possono compiere ottimizzazioni più sofisticate rispetto a quelle più limitate che si ottengono solo con lo scheduler OoO e con il renaming.

Dati alla mano, lo "sweet spot" per le architetture a registri di uso generale è di 16..32 registri (con meno registri le prestazioni degradano, con più registri non ci sono vantaggi significativi causa maggior numero di registri non utilizzati con sufficiente frequenza).

La differenza nel passare da 8 a 16 registri quindi in linea generale si sente, solo che negli x86 se si fa il confronto con x86 + SSE2 (8 registri interi di uso generale ed 8 registri XMM a 128bit) si è già "quasi" nel caso a 16 registri (8+8) mentre con x86-64 si è "certamente" nel caso a 16 registri (16 registri interi a 64bit oppure 16 registri XMM a 128bit) e "quasi" nel caso a 32 registri (16 + 16).
Visto che il caso ottimale è tra 16..32 registri, se si fa il confronto con x86 + SSE2 non c'è il gran salto che ci si potrebbe aspettare.

[LMCH]

Originariamente inviato da Pier2204

Ci scommetto le palle da flipper che adesso è colpa di Microsoft.

Ti piace vincere facile, eh?
Comunque una volta tanto le ragioni sono solo tecniche e dettate più dalle risorse limitate di Mozilla che da colpe di Microsoft.

[birmarco]

Originariamente inviato da djfix13

beh io di architettura non ho fatto molto e sono rimasto alla base hobbystica della cosa ma ora mi chiedo:

questa notizia è quindi falsa?
windows-9-arriva-nel-2015-con-la-versione-a-128-bit-e-interfaccia-3d/

Chi ha scritto sto articolo?

[bio82]

Originariamente inviato da LMCH

Un S.O. a 64bit anche se fa girare solo applicazioni a 32bit può sfruttare più di 4GB di ram per il caching dei dati o per permettere a più applicazioni che usano 1..2GB di ram ognuna di girare completamente in ram anche se complessivamente superano i 4GB.

questo è il motivo per cui si migra ai 64 in qualsiasi ambito...io uso xp64 da 6/7 anni e i primi anni ero obbligato ad usarlo e sorbirmi i suoi problemi (senza SP era peggio di windows ME)....

le applicazioni a 32 bit su sistemi a 32 bit possono allocare massimo 3.2 gb (circa) di ram per processo...quelle stesse applicazioni a 32 su un sistema a 64 bit non hanno limite teorico di ram allocabile....e 6/7 anni fa alcuni software di calcolo che utilizzavo non avevano una versione a 64 bit...

ormai i 64 sono una costante (ho forse solo 3/4 macchine su una cinquantina a 32 bit solo perchè ad uso office)...

bio

[Vash_85]

Sono due anni che oramai uso waterfox, e fino ad ora non ho trovato broswer migliore....
Quindi se tagliano il supporto a firefox x64....

[Tasslehoff]

Originariamente inviato da bio82

questo è il motivo per cui si migra ai 64 in qualsiasi ambito...io uso xp64 da 6/7 anni e i primi anni ero obbligato ad usarlo e sorbirmi i suoi problemi (senza SP era peggio di windows ME)....

le applicazioni a 32 bit su sistemi a 32 bit possono allocare massimo 3.2 gb (circa) di ram per processo...quelle stesse applicazioni a 32 su un sistema a 64 bit non hanno limite teorico di ram allocabile....e 6/7 anni fa alcuni software di calcolo che utilizzavo non avevano una versione a 64 bit...

Quoto Veradun, per un maggiore dettaglio invito a consultare questa pagina di msdn.

Dire poi che i sistemi x64 non hanno limite teorico poi è falso, di limiti ce ne sono eccome, ora ci sembrano astronomici ricordiamoci però che era lo stesso negli anni '60 e '70 per i limiti imposti dalle architetture a 32bit.

Attenzione poi a un dettaglio tutt'altro che insignificante, un conto sono i limiti architetturali, un conto sono i limiti imposti dai produttori dell'OS o di uno specifico prodotto nell'uso delle risorse.
Come puoi vedere dalla pagina che ho linkato le soglie di occupazione ram per i sistemi operativi MS sono infinitamente più basse rispetto a quanto permetterebbe l'architettura x64, e non c'è "smanettamento" del registro che possa sbloccare tutto questo.

ormai i 64 sono una costante (ho forse solo 3/4 macchine su una cinquantina a 32 bit solo perchè ad uso office)...

Non sono così d'accordo, sistemi a 32bit sono ancora molto diffusi, e non solo per un retaggio del passato.
Questo è vero non solo un ambito client ma anche server, il mio lavoro mi permette di mettere il naso in molti ced di tantissime aziende ed enti pubblici (dall'ente in cui sto lavorano ora ho a perimetro 124 sistemi e una ventina di dispositivi tra san, bladecenter, switch fc e altre quisquilie) e ti posso assicurare che i 32bit sono ben lungi dall'essere abbandonati.
Anzi in molte condizioni sono più vantaggiose architetture distribuite a 32bit piuttosto che far girare il tutto a 64bit, il tutto senza considerare le implicazioni lato sviluppo e test, impensabili anche solo da pensare, specialmente in un momento storico come questo

[Benjamin Reilly]

anche i chipset delle motherboard passate rappresentano un limite.