appena arriva al mio gestore telefonico prolungo il contratto e lo prendo,il mio 5 di 2 mesi lo passo in mano alla mia dolce meta' ;-) l'attuale suo 4s(ex mio) parte in vendita cosi accontento tutti,me' in primis Mauretto tu gia lo sapevi :-)
Si vero /emoticons/wink@2x.png 2x" width="20" height="20"> /emoticons/biggrin@2x.png 2x" width="20" height="20">
Hai pienamente ragione...non hai mai detto certe cose /emoticons/wink@2x.png 2x" width="20" height="20"> Pero' vi prego non litighiamo
Hai ragione.. Chiedo scusa.. A gabo prima di tutto, e anche a te.. Ma ne vedo troppi di niubbi che ridacchiano tanto per farlo nel mio lavoro, e allora mi va il sangue alla testa...
Non c'e' problema /emoticons/wink@2x.png 2x" width="20" height="20"> ...puo' capitare a tutti, a me in primis /emoticons/wink@2x.png 2x" width="20" height="20"> Ci conosciamo..anche se solo virtualmente /emoticons/sad@2x.png 2x" width="20" height="20"> e so che non sei una persona così /emoticons/wink@2x.png 2x" width="20" height="20">
Comunque, questo articolo, che è di ottobre, chiarisce alcuni concetti e conferma alcuni dubbi da me espressi sin dalla presentazione dell'iphone 5S a settembre: http://news.techworld.com/personal-tech/3471543/apples-64-bit-a7-chip-a-marketing-gimmick-qualcomm-exec-says/ Versione tradotta (per chi non mastica molto l'inglese..) http://translate.google.com/translate?hl=it&sl=auto&tl=it&u=http%3A%2F%2Fnews.techworld.com%2Fpersonal-tech%2F3471543%2Fapples-64-bit-a7-chip-a-marketing-gimmick-qualcomm-exec-says%2F
Io invece riporto tutto in inglese /emoticons/wink@2x.png 2x" width="20" height="20"> http://www.itworld.com/mobile-wireless/377181/apple-64-bit-a7-chip-making-big-to-improvements-audio-and-video-apps L'articolo che riporti tu e' normale che si dica certe cose /emoticons/wink@2x.png 2x" width="20" height="20"> ( Qualcomm ....snapdragon) Cmq, vediamo nel prossimo periodo come vanno le cose...anche se già Samsung e' all'opera per un 64bit e il ID Touch /emoticons/wink@2x.png 2x" width="20" height="20"> Questo non significa certo chi lo ha più lungo...anzi...tutt'altro... Sono curioso di capire dove voglio arrivare ( tutti) con questi terminali!
Già.. Ma Phil Schiller non lavora mica alla FIAT.. Ma dato che si occupa dello sviluppo di XCode non può mica dire che la nuova architettura porta svantaggi tecnici.. Il discorso è perfettamente reversibile, solo che mentre Chandrasekher basa le sue supposizioni sulla mera matematica (cosa ben poco opinabile..), Phill Schiller non fornisce spunti tecnici su cui basare le sue tesi.. La ricompilazione di un'applicazione da 32 a 64 porta ad una migliore gestione della memoria, che comunque "CI DEVE ESSERE", altrimenti il tutto va in overflow... E su iphone 5S, la memoria, a quanto pare non c'è.. Resto dell'idea che sia solo un modello di transizione, come furono le prime CPU AMD, montate su sistemi con poca RAM per gestire registri a 64 bit in modo efficente.. Riporto il solito esempio: Un registro a 32 bit consente di indirizzare 232 indirizzi, o 4 gigabyte di memoria Un registro a 64 bit incrementa la quantità di memoria indirizzabile fino 264 byte, equivalenti a 17.179.869.184 gigabyte o 16 exabyte E anche se è ovvio che nessuno smartphone proverà mai a muovere un indirizzo di tale mole, appare chiaro il concetto di "vastità" che è legato ad un registro a 64 bit La cosa andrà capita meglio, per ora non è affatto chiara In quanto a samsung e a qualcomm, i processori ARM a 64 bit li hanno già fatti (qualcomm un paio di annetti fa..), ma sino a che non ci sarà un OS a 64 bit, al massimo ci potranno fare un'insalata..
R: iPhone 5S e 5C Si ma stando a quanto dichiara apple ios7 dovrebbe già essere un OS a 64 bit.? Comunque a parte tutto in un apparato mobile l'unica vera utilità secondo me potrebbe essere il notevole miglioramento nella comprensione del parlato naturale soprattutto anche OFF line ed una sorta di intelligenza artificiale in modo da portare il telefono ad essere veramente una sorta di assistente personale. Praticamente un siri molto più evoluto e magari una sorta di traduttore universale.... Immagina di chiamare qualcuno che parla in giapponese e il telefono traduce in tempo reale... In entrambe le direzioni... Futuro? Si. ma neanche tanto lontano. Inviato dal mio GT-I9505 con Tapatalk 4
Questa è una buonissima ipotesi! Ma fa sempre a pugni con la penuria di memoria di iphone 5S, che allora sarebbe davvero un modello di transizione verso qualcosa di veramente evoluto.. Per quanto ne so io IOS è compilato a 64 bit, ma android non lo è, quindi sino a che non ne uscirà una versione a 64, qualunque produttore che lo utilizzi e che provi a sfornare una CPU a 64 bit lo farà solo come esercizio di stile, e nulla di più..
R: iPhone 5S e 5C Scusa... Ma il fatto che i 64 bit siano in grado di indirizzare l'esorbitante quantitativo di memoria, non vuol dire che tu debba per forza averlo od utilizzarlo. È vero che i 64 bit portano un'occupazione maggiore di memoria rispetto ai 32, ma in misura sostanzialmente ininfluente, specie se la ram installata è già sovradimensionata alle esigenze reali. Quindi il discorso di dire "non serve" perché hanno migrato a 64 bit ma hanno lasciato la stessa quantità di Ram, lascia il tempo che trova, poiché 1-2Gb in base a quanto sia esasperato il multitasking (e su ios non lo è per nulla), potrebbero restare più che sufficienti. Di conseguenza non è questo il problema, casomai è capire quanto realmente abbiano guadagnato in efficienza e prestazioni, posto che sui PC non si è mai gridato al miracolo nel passaggio da 32 a 64, anzi... By my Phablet N2
Discorso valido.. Ma solo a livello teorico, perchè in pratica: Se ricompili a 64 bit un'applicazione, che a 32 bit per una chiamata esprime un'occupazione sugli stack della memoria (o meglio sugli heap, dato che siamo su architetture ARM..) di dimensione X32, l'occupazione di memoria della stessa chiamata a 64 bit avrà un valore X64.. Il problema non sussiste se la memoria c'è, ma se non è sufficente, si presenta eccome... E se il vantaggio di avere una CPU a 64 bit è indubbio, la mancanza di memoria è il vero collo di bottiglia, esattamente come successe per i primi AMD a 64 bit che uscirono quando i sistemi "standard" arrivavano a 512 mb di memoria RAM
R: iPhone 5S e 5C Detta così, sembra che tu sostenga che l'occupazione di memoria raddoppi, ma sai meglio di me che non è così, indi per cui, torno al mio post precedente, 1GB potrebbe essere assolutamente sufficiente, come lo era per i 32bit, specie in sistemi, come questo, in cui il multitasking non è propriamente il punto di forza... By my Phablet N2
Non raddoppia, perchè un registro a 64 bit gestisce meglio gli stack, ma aumente in modo esorbitante (siamo intorno a valori del + 70% di occupazione sigli stack in ambiente x86, non conosco quali siano i valori su architettura ARM, ma dovrebbero coincidere).. E quel "potrebbe essere sufficente", non è un bel segno.. Sopratutto perchè IOS ora ha un vero sistema di multitasking, e non più un sempice freeze delle applicazioni.. Bisogna vedere cosa succederà quando cominceranno a circolare le applicazioni a 64 bit. Sino ad allora sono solo ipotesi, anche perchè un'applicazione a 32 bit che gira su una CPU a 64 retrocompatibile, non ha alcun vantaggio, e Phil Schiller quelle balle li le racconti pure a qualcun altro.. Se le applicazioni a 32 girano in modo migliore su questo nuovo processore, la cosa va addebitata a migliori set di istruzioni, non certo all'architettura delle CPU..
A me risultano studi e prove su ambienti home PC nell'ordine del +10/20%, se consideri che le applicazioni più importanti sono in bundle con il SO (browser, mail, galleria, dialer, ecc... che su ios neanche possono essere facilmente sostituite), gran parte del lavoro lo hanno praticamente già fatto in casa. By my Phablet N2
Non confondiamo le cose... Il 90% dei programmi windows che girano a 64 bit, in realtà sfruttano il sistema WOW64 di windows, che permette di ibridare le chiamate a 64 bit con quelle a 32 bit, grantisce la retrocompatibilità, e non sono "compilati per intero" a 64 bit... Questo ne limita le dimensioni, e anche (e sopratutto...) le prestazioni. Ma magari mi spiego meglio con qualche immagine... Qualunque sistema operativo su base X86 esegue un'accesso alle chiamate a 32 bit strutturato in questo modo: Mentre l'architettura delle chiamate a 64 bit è sostanzialmente più complessa.. La stessa chiamata nativa (parallela), viene strutturata in questo modo: Anche se sembrano molto diversi, in realtà non lo sono, la grande differenza sta nell'uso "lineare" della memoria nell'architettura a 64 bit, il cosidetto "adress space", e sta proprio li il problema.. Ma allora, come fa un sistema a 64 bit a far girare un'applicazione a 32 se la struttura dei registri non è la stessa? Bhè... Ci ha pensato Intel! Introducendo tutta una serie di istruzioni, che permette di strutturare le chiamate a 64 bit in modo diverso se rivolte ad interlocutori a 32 bit, aggiungendo ai suoi processori la cosidetta "modalità 32E" (Estesa), che permette di passare in modo nativo dalla modalità di funzionamento "in compatibilità 32 bit" con l'esclusione della memoria lineare tramite il re-indirizzamento dei prefissi, al pieno trattamento della memoria lineare con la sola variazione dei prefissi, sino al pieno funzionamento a 64 bit, garantendo in questo modo la piena retrocompatibilità del software a 32 bit (ma non dei drivers, che devono essere SEMPRE a 64 bit) Vediamole nel dettaglio queste modalità: Come leggiamo qui sopra, l'uso lineare della memoria, comporta il "RADDOPPIO" del numeri di registri utilizzati per chiamata, mente la modalità compatibile, permette solo di variare una parte delle chiamate utilizzando il set di istruzioni integrato nelle CPU in questo modo: Il sistema, vede queste applicazioni "ibride" come se fossero codificate a 64 bit, ma per non creare overflow gli alloca solo 4 gb di memoria lineare (la massima supportabile da una codifica a 32 bit), ed effettua le chiamate sempre nel solito modo, si occupa il set 32E della compressione dei registri, questo comporta il fatto che la maggior parte delle applicazioni "a 64 bit" disponibili sul mercato, in realtà non lo siano proprio per nulla, e che funzionino in modo completamente trasparente... Questo escamotage, permette di limitare le dimensioni della memoria lineare occupata (come hai detto tu, circa il 20% in più), ovviamente, la compressione effettuata dal set di istruzioni penalizza le prestazioni, dato che il ciclo non è realmente a 64 bit. Premesso questo, qual'è stata la soluzione adottata da windows per poter eseguire codice a 32 su macchine a 64 senza variare drasticamente le dimensioni dell'occupazione di memoria causata dal diversi dimensionamento degli indirizzi? Quella che occupa la memoria lineare e che rende obsoleto tutto il software a 32 bit, o quella retrocompatibile, che garantisce grandi prestazioni grazie al continuo progresso delle CPU e i mantenimento di un enorme parco software? In reltà sono stati adottati 2 sistemi, ed entrambi sono stati ideati dall'Intel, uno, il meno performante, usa il sistema WOW64 e limita le dimensioni dell'occupazione, l'altro, decisamente più performante, usa la memoria lineare fregandosene dell'occupazione degli indirizzi in pieno stile UNIX ({sarcasmo mode [ON*} chissà quale dei 2 potrà adottare un sistema su base UNIX come IOS...{sarcasmo mode [OFF]}), tanto a mamma microsoft della nostra memoria poco gli frega, e quindi, ottenuta la piena retrocompatibilità, lascia decidere agli sviluppatori... Ma la morale di tutta questa favola qual'è? Semplice: un'applicazione a 32 bit può girare su un sistema a 64, ed essere vista come un'applicazione a 64 bit nativa, ma una a 64 non può girare su un sistema a 32, quindi le applicazioni future per IOS dovranno essere compilate in 2 modi diversi per poter essere usate da tutto il parco hardware. Ma un'applicazione nativa a 64 bit comporta il raddoppio delle dimensioni dei registri, che se non significa il raddoppio dello spazio in memoria poco ci manca, perchè durante l'esecuzione di un applicativo, la UI viene caricata una volta sola nelle gerarchie di programmazione, e ciò che varia sono sempre le chiamate e i contenuti.. E se il nuovo modello di iphone subisce un raddoppio delle dimensioni delle chiamate, ma non si porta dietro un aumento in percentuale delle dimensioni della memoria, che la cosa piaccia o meno, è un problema, dato che le applicazioni la gente continuerà a scaricarle e ad usarle.. Ma se non saranno compilate a 64 bit, quale vantaggio potranno presentare? Come si può sostenere che una "compressione" effettuata da un set di istruzioni possa essere più veloce di un'interpretazione diretta da parte delle routine della CPU?
[MENTION=17830]Scrondo[/MENTION] Ma sei fuori :what: /emoticons/wink@2x.png 2x" width="20" height="20"> Ma secondo te qui qualcuno può capirci qualcosa di quel che hai scritto? Anch'io nonostante in passato, molto in passato abbia gozzovigliato con debug MOV int e tentativi vari, mal riusciti, di imparare l'assembly 8086 non ci ho capito quasi una mazza /emoticons/biggrin@2x.png 2x" width="20" height="20"> Inviato dal mio Nexus 7 con Tapatalk 4
In realtà sono io che sono troppo prolisso e che mi spiego male.. Il succo del discorso, è che la maggior parte delle applicazioni a 64 bit che usiamo in realtà vengono compilate tenendo conto che dentro windows c'è WOW64, che supplisce a tutto ciò che non si riesce a ricompilare in modo efficente, grazie alla manipolazione degli stack, un esempio sono i programmi della discreet (3dStudio ecc. ecc..), che uniscono una UI a 32 bit e dei set di drivers a 64 bit.. Maya invece è a 64 bit nativo, e necessita di ben altre risorse.. Ma mettila come vuoi, se un'applicazione è a 64 bit ha bisogno di un sacco di memoria lineare per funzionare... Se non la usa, è perchè sta utilizzando un'escamotage che gli permette di effettuare le chiamate a 32 bit, ma ovviamente non sarà mai efficente come del codice che usa grandi quantità di memoria lineare. Un esempio ancora più semplice? Provate ad installare apache 32 bit su un server linux, poi fate girare chainsaw e analizzate, conservate il log e disinstallate, rifate la procedura con apache 64 > chainsaw e log... Confrontate, e impallidite.. E apache non interconnesso è puro codice caricato in memoria, senza interazioni..
