La giovane Developer Edition di Firefox si è dotata di una build 64-bit dedicata ai sistemi Windows: era stata annunciata contestualmente ai festeggiamenti per il decennale del browser ed ora è disponibile nel canale dedicato agli sviluppatori.
Lo sviluppo di build a 64 bit per sistemi Windows era stato interrotto nel 2012: gli sviluppatori di Firefox avevano scelto di concentrarsi sulle build a 32-bit per problemi di instabilità e bug troppo complessi da risolvere con le risorse a disposizione della community. Ora sembra giunto il momento di riallinearsi alla concorrenza di Chrome e di Internet Explorer.
Con l’evolvere di applicazioni web sempre più complesse, ad esempio con l’avanzare delle frontiere della videoludica incastonata nel browser, le esigenze sono cambiate: lo spazio di indirizzamento va aumentato oltre i 4 GB concessi dai 32-bit e un browser a 64-bit può fare la differenza, ripercuotendosi anche sulle prestazioni in termini di velocità. Mozilla cita l’esempio del subset JavaScript asm.js (che anche Microsoft ha scelto di supportare per Windows 10): con l’aumento dello spazio di indirizzamento dato dalla versione 64-bit e la possibilità di sfruttare nuovi registri e istruzioni hardware, gli incrementi prestazionali vanno dall’8 al 17 per cento, garantendo al contempo una maggiore sicurezza, con la possibilità di appieno le misure di protezione ASLR.
Mozilla suggerisce agli sviluppatori che vogliano mettere alla prova la build 64-bit di Firefox 38.0a2 di disinstallare la versione Win32 senza rimuovere il proprio profilo prima di scaricare la versione desiderata.
Gaia Bottà
-
ennesimo fallimento del mondo open
le OpenGL hanno fallito => ennesimo fallimento del mondo open.Ci fosse un progetto open che venga adottato seriamente!Re: ennesimo fallimento del mondo open
Apache2 quindi lo mettiamo nel XXXXX direttamente?Re: ennesimo fallimento del mondo open
Lo standard TCP-IP al bando!E' open pure lui!Lascialo stare, non sa ma parla.Re: ennesimo fallimento del mondo open
- Scritto da: Giulia> Apache2 quindi lo mettiamo nel XXXXX direttamente?ma anche si, meglio nginxRe: ennesimo fallimento del mondo open
- Scritto da: dumah> le OpenGL hanno fallito => ennesimo fallimento> del mondo> open.> Ci fosse un progetto open che venga adottato> seriamente!Le OpenGL vengono usate su tutti i giochi mobile, per Android e per iOS, oltre che per diversi giochi per Windows e praticamente tutti quelli per Linux e OSX.Se chiami fallimento questo, voglio fallire anche io!Re: ennesimo fallimento del mondo open
Ehm.sad fsafdf saasf asdf sadf asdfasfa sdf?Okay?Pressochè è quello che devi avere in testa tu.Re: ennesimo fallimento del mondo open
- Scritto da: dumah> le OpenGL hanno fallito => ennesimo fallimento> del mondo> open.> Ci fosse un progetto open che venga adottato> seriamente!Sei proprio convinto di quello che vai dicendo (o che ti fanno dire)?OpenGl vs Vulkan
Le OpenGl hanno il problema che non girano su ARM ... Vulkan invece si, per questo non sn compatibili con OpenGl.Re: OpenGl vs Vulkan
non è certamente il motivo più importantela vera ragione sta nell'architettura completamente differente della nuova apima il nocciolo della questione è che quest'api ti dà:1. performance migliori2. meno bug3. driver più semplici4. maggior controllo in mano alle applicazioniRe: OpenGl vs Vulkan
- Scritto da: collione> 1. performance migliori> 2. meno bug> 3. driver più semplici> 4. maggior controllo in mano alle applicazioni5. maggiori difficoltà per gli sviluppatori che devono usarle.Non dimentichiamo che le OpenGL, pur con i loro limiti dovuti a 25 anni di storia e retrocompatibilità, offrono delle API di livello più alto. Con Vulkan solo le grandi software house (e, speriamo, grandi progetti open source) saranno in grado di creare motori grafici, gli altri dovranno limitarsi ad appoggiarsi a questi progetti.Re: OpenGl vs Vulkan
Ma l'idea è che chi non ha i mezzi non dovrebbe mettersi a pasticciare con i motori graficiRe: OpenGl vs Vulkan
- Scritto da: Fra> Le OpenGl hanno il problema che non girano su ARM> ... Vulkan invece si, per questo non sn> compatibili con> OpenGl.Le OpenGL "complete" non girano su AMR, ma OpenGLSL sì.Vulkan è stato progettato con il mobile in mente, quindi è pensato per girare anche con poche risorse.Re: OpenGl vs Vulkan
- Scritto da: Fra> Le OpenGl hanno il problema che non girano su ARM> ... Vulkan invece si, per questo non sn> compatibili con> OpenGl.Non c'è nessuna incompatibilità fra OpenGL e ARM. In genere su telefoni e aggeggi del genere non ci sono le OpenGL complete ma le OpenGL ES, con alcune cose in meno, ma non ha nulla a che vedere con l'architettura della CPU/GPU.Re: OpenGl vs Vulkan
> Non c'è nessuna incompatibilità fra OpenGL e ARM.> In genere su telefoni e aggeggi del genere non ci> sono le OpenGL complete ma le OpenGL ES, con> alcune cose in meno, ma non ha nulla a che vedere> con l'architettura della> CPU/GPU.Esattamente. In realtà le GLES che sono state definite anche loro da Khronos, richiedono al programmatore di scriversi gli shaders a mano, cosa che le GL non fanno, in quanto gli shaders sono già compilati.Peccato che per ogni luce che piazzi devono calcolare l'effetto su ogni singolo pixel della scena e se usi l'alpha channel la complessità diventa ancora maggiore.Consentendo al programmatore di scrivere gli shaders, gli consenti di scegliere il giusto compromesso tra velocità e complessità, che serve a lui, cablandosi applicazioni su misura e per questo sono lo standard delle WebGL.Quello che però sembra veramente rivoluzionario, è la definizione dell'OpenCL. Considerato che il proXXXXXre di un modulo grafico di uno smartphone è in grado di eseguire centinaia di calcoli vettoriali paralleli in virgola mobile in un microsecondo, poter riusare questi dati a livello di CPU invece che per la semplice rappresentazione grafica, è una possibilità completamente nuova nello sviluppo di giochi e algoritmi vari.Re: OpenGl vs Vulkan
- Scritto da: Luppolo> > Non c'è nessuna incompatibilità fra OpenGL e> ARM.> > In genere su telefoni e aggeggi del genere non> ci> > sono le OpenGL complete ma le OpenGL ES, con> > alcune cose in meno, ma non ha nulla a che> vedere> > con l'architettura della> > CPU/GPU.> > Esattamente. In realtà le GLES che sono state> definite anche loro da Khronos, richiedono al> programmatore di scriversi gli shaders a mano,> cosa che le GL non fanno, in quanto gli shaders> sono già> compilati.Eh? No, questa differenza non esiste. Devi scriverti gli shader, se li vuoi usare, qualunque sia la versione di OpenGL.> Quello che però sembra veramente rivoluzionario,> è la definizione dell'OpenCL.> > > Considerato che il proXXXXXre di un modulo> grafico di uno smartphone è in grado di eseguire> centinaia di calcoli vettoriali paralleli in> virgola mobile in un microsecondo, poter riusare> questi dati a livello di CPU invece che per la> semplice rappresentazione grafica, è una> possibilità completamente nuova nello sviluppo di> giochi e algoritmi> vari.Questa non è una novità, è da anni che si fa.Grazie, il tuo commento è in fase di approvazioneGrazie, il tuo commento è stato pubblicatoCommento non inviatoLeggi gli altri commentiPubblicato il 4 mar 2015Link copiato negli appuntiTi potrebbe interessare
![Gaia Bottà]()
Pubblicato il 4 mar 2015Link copiato negli appunti
