Red Hat apre SPICE

Re: Si ma la differenza principale è...
- Scritto da: Vault Dweller
Dipende dall'ambito, dalla frequenza e dal tempo
di
utilizzo.
non dimenticare che lo scopo è accelerare ajax, quindi si parla di script che funzionano per tutta la durata di una sessione web
Ora tu forse non ti leggi quando scrivi ma non
puoi usare processi e thread indifferentemente in
due punti del post ed insistere che sonon cose
totalmente diverse; essi sono diversi,
semplicemente perché più processi indicano uno
scope di esecuzione differente, tuttavia i thread
vengono forkati e clonano la memoria del padre,
pur mantenedo uno scope di esecuzione comune
denominato
proXXXXX.
non confondiamo....il forking riguarda i processi e consiste nell'istanziare un nuovo spazio d'indirizzamento per i processi figliil threading è una suddivisione logica che il proXXXXX fa al suo interno senza però creare un nuovo spazio d'indirizzamento e senza copiare i dati ( visto che sono accessibili da tutti i thread )c'è una differenza significativa tra i due
Ma non è senza dati; in esso vi sono i dati di
inizalizzazione del programma nonché i
riferimenti pid dei programmi
figli!!
certo, ma tanto per dirne una non c'è tutta la struttura del domi dati di cui parli sono contenuti in una singola pagina di memoria, parliamo di 4kbytes, una banalità praticamente
Il dispendio di memoria di firefox deriva dalla
costruzione delle interfaccie XUL, ed al
contrario di chrome non è una per tab; ed inoltre
non è nemmeno così elevata; ma forse non ti sei
mai dato pena di fare dei
test.veramente ho visto come funziona firefox normalmente e noto che consuma un bel pò di memoria per costruire il dom, stoccare i javascript, compilarli, ecc... a parità di attività chrome consuma decisamente meno....anzi webkit consuma decisamente meno
Non insultare la mia intelligenza, nemmeno un
bambino farebbe i confronti utilizzando diversi
metri di
giudizio.
un bambino no, ma potevi aver volutamente usato due metri diversimi è parso strano perchè io riscontro il comportamento contrario e cioè che chrome consuma molto meno
Ribadisco che gli activeX non c'entrano una XXXX.e infatti non sto dicendo che chrome usa il modello usato da ms per gli activex....sto dicendo che la sandbox serve per evitare le sorpresine a cui purtroppo gli activex ci hanno abituati
In quanto all'esterno di chrome gli ECMAScript
sono interpretati ed è l'interprete a fungere da
isolante tra sistema e script, mentre in chromeinfatti
basandosi sulla compilazione devono passare
forzatamente in
sandbox.
ma del resto pure l'interprete javascript implementa il sandboxing, lo fa applicando maggiori controlli all'atto dell'interpretazione, invece di isolare l'esecuzione del codice generato dal js, ma alla fin fine pure l'interprete ha un overhead dovuto alla sicurezzatant'è che i benchmark parlano chiaro e dicono che v8 è il più veloce in assolutoe ovviamente firefox pure c'ha la sua jit, safari pure, ecc....
Il tempo di compilazione va sommato con il tempo
di inizializzazione ed esecuzione, e alla prima
esecuzione ciò risulta molto più lento di codice
interpetato.
che intendi per inizializzazione? normalmente un compilatore jit si limita a compilare appunto ed esguire il codice generato....un interprete legge l'istruzione, ne crea una versione compilata al volo ( o meglio richiama delle sue funzioni interne con determinati parametri ) e l'eseguepoi il compilatore jit non è stupido, compila on demand e a pezzi
Ma è un ambito di utilizzo diverso; se devi fare
una buca una ruspa è il mezzo più adatto, ma se
devi andare a oslo, pur arrivandoci anche con la
ruspa, usare l'aereo risulterebbe più
comodo.
dipende da cosa si intende per diversi...un sito web con ajax e gingilli vari, con applicazioncine sparse qua e là non è tanto diverso da un normale programmadel resto ms usa .net pure per il web
Ma hai una vaga idea di cosa sia e come funzioni
un compilatore
jit?direi di si
Un compilatore jit compila tutto il codice in
codice nativo appena prima dell'esecuzione (just
in time per l'appunto) compilando ogni file (ono no no, la compilazione jit può essere resa incrementale, il che vuol dire che alcuni blocchi vengono compilati on demandmi spiace ma sei tu a non aver idea di come funziona un compilatore jithttp://www.gnu.org/software/dotgnu/libjit-doc/libjit_3.html#SEC8"In the previous tutorials, we compiled everything that we needed at startup time, and then entered the execution phase. The real power of a JIT becomes apparent when you use it to compile functions only as they are called"nessun compilatore jit moderno, da .net a v8 compila tutto a runtime
classe o funzione) come una libreria e durante
l'esecuzione il profiler rileva eventuali
ottimizzazioni possibili per il segmento e avvia
la ricompilazione dello stesso, che anrdà a
sostituirsi nelle chiamate a libreria delle altre
parti. Ciò risulta che per ridurre al minimoquesto riguarda l'ottimizzazione del codice, ma non toglie il fatto che il jit compila a pezzi
l'overhead il compile-time ante esecuzione non è
ottimizzato, in quanto le ottimizzazioni verranno
introdotte dalle iterazioni di compilazione
successive.
falso, il compilatore quando inizia a compilare sa già su quale proXXXXXre sta lavorando e le ottimizzazione sono applicabili al primo colpollvm fa così ad esempio....quello di cui parli tu è il dynamic typing supportato da linguaggi come python, dove il tipo di ogni variabile può essere polimorfico, per cui ad ogni uso della variabile si può avere la necessità di ricompilare parte del codice ( e bada bene parliamo sempre di pezzi non della totalità ) per far assumere alla variabile il nuovo tipo richiesto
Iniziano a sorgermi dubbi sul fatto che tu sia
propenso a scivere senza pensare; i binari non
sono un problema in quanto binari ma in quanto
binari creati da codice non affidabile reperito
su remoto, che se eseguiti all'esterno dellocosì come sono i binari reperiti da remoto...se scarichi un exe da un sito web sei sicuro che sia affidabile?perchè un binario generato dalla compilazione jit del js dovrebbe essere meno affidabile di un binario normale?
scope del programma verrebbero eseguiti
direttamente e non in
sandbox.
appunto, i normali binari vengono eseguiti direttamente quindi sono più pericolosi, negando l'affermazione che hai fatto poco più su

Re: Microsoft Firefox!!!!
Assolutamente d'accordo con te.Però il problema riguardo NSA è un dubbio legittimissimo, però non ci sono prove concrete sul controllo.Io non critico i dubbi, critico le frasi in qualche modo offensive tipo "Tipico ragionamento di un utente M$". Avete perfettamente ragione a criticare, ma c'è critica e critica.

Re: Microsoft Firefox!!!!
eh già... il beta di microsoft è ben diverso del beta che usano gli altrivedi win 7 beta e ubuntu 9.10 beta