In realtà da utilizzatore di Iphone e iPad noto che la stragrande maggioranza delle applicazioni sono compatibili con entrambi. Spesso capita infatti, che installando una applicazione su iphone, si installi la stessa anche su Ipad. Esistono eccezioni è vero ( sia in un senso ,che nell'altro) ma non trovo la cosa poi così terrificante.

In realtà da utilizzatore di Iphone e iPad noto che la stragrande maggioranza delle applicazioni sono compatibili con entrambi. Spesso capita infatti, che installando una applicazione su iphone, si installi la stessa anche su Ipad. Esistono eccezioni è vero ( sia in un senso ,che nell'altro) ma non trovo la cosa poi così terrificante.

Io ho girato intorno al problema, installando alcune applicazioni di terze parti.

Certo che trovarsi ad installare applicazioni di terze parti sulla piattaforma per cui dovrebbe esserci tutto, puzza proprio d'impresa per il culo.

No aspettate un secondo, chiedo qui perchè sicuramente ho sbagliato io e non può essere una mancanza così grossa.

Come faccio ad aggiungere parole al dizionario della tastiera corrente?

Solitamente, su Android e anche su Windows Phone, quando una parola è sottolineata come sconosciuta o errata si può aggiungere al dizionario, ed a quel punto viene considerata parte del sistema predittivo del correttore ortografico.

Come si fa in iOS? Non riesco a farlo.

Sparo la minchiata della domenica pomeriggio...e un China tablet con 3G e risoluzione iPad? Ci sono degli eccezionali cloni di iPad mini con display retina.

PS: Avevo premesso che potrebbe essere una gran minchiata per alcuni!

Sparo la minchiata della domenica pomeriggio...e un China tablet con 3G e risoluzione iPad? Ci sono degli eccezionali cloni di iPad mini con display retina.

PS: Avevo premesso che potrebbe essere una gran minchiata per alcuni!

Suvvia dai non sono ancora così disperato

Se crei un tablet, o mi fornisci OGNI applicazione per il mio display, togliendo la scelta allo sviluppatore, o fai il possibile per scalare una singola interfaccia su diversi schermi. Non ci sono altre possibilità.

Se ti inventi altro, sei disonesto.

Togliere la scelta allo sviluppatore significa impedire all'utente di usare un'app fatta per telefono nel frattempo che lo sviluppatore l'adatta al tablet.

La seconda opzione potrebbe rendere le applicazioni poco adatte agli schermi più grandi, perché gli sviluppatori potrebbero essere pigri e non adattarle ma lasciare che se la veda il sistema.

In entrambi i casi l'unica cosa che so per certa è che l'opzione che hanno scelto serve come incentivo a fare app adatte agli schermi più grandi (dovrei cercare la fonte ma la posso trovare), se sia una scelta giusta o sbagliata non lo so e non m'interessa stabilirlo.

Mi hanno anche detto che steve jobs aveva un cazzo da 45cm, ma non per questo ci credo.

Ho fatto varie prove comparative, dal ridimensionamento immagini al trim di video, comparando il vetusto Nexus 7 all'iPad Mini.

Ti ricordo che il Nexus 7 monta un Tegra 3, che è uno dei peggiori processori degli ultimi anni.

Certo, l'ipad mini è più veloce, e ci mancherebbe anche, ma non in modo così eclatante come cercano di venderlo.

Si, è veloce, ma non è così rivoluzionario.

La storiella dei 64bit, poi, è uno specchio per le allodole, i core sono comunque due, il numero di operazioni per ciclo di clock sempre quello è, ed il clock è basso.

Per capirci, non abbiamo di fronte un salto generazionale come quello che ci fu, ai tempi, tra P6 e Centrino.

Li fu un salto grosso.

Sto Arm a 64bit è carino, è sicuramente valido, ma starei molto cauto a fare come fa certa stampa specializzata, che dipinge l'A7 come rivoluzionario e afferma che, a confronto, cose come lo Snapdragon 800 sono vetuste.

Odio il sensazionalismo, e cerco sempre di usarlo in modo parsimonioso. L'A7 se ne merita davvero poco.

Poi ripeto, non ho detto non sia un buon processore, probabilmente uno dei più efficaci sul mercato in questo momento, ma andiamoci molto molto piano.

Mi ripeto, l'A7 ha le migliori performance attualmente e questo è obiettivamente vero visti i test fatti e i risultati consistenti (fin qui è tutto chiaro).

Ora sfatiamo un po' di miti (voglio solo fare un discorso in generale sul processore, dopo rispondo):

i 64 di per sé non indicano la dimensione fisica degli indirizzi RAM (e di conseguenza la dimensione della RAM che il calcolatore può supportare), il modo in cui la CPU parla con la ram è indipendente da questo, negli ARM in genere la dimensione varia da 26 a 40 bit e può cambiare indipendente dai bit del processore (che possono indicare la dimensione dei registri o quella dei puntatori); non indicano la dimensione del data bus, l'iPhone 5 prelevava già i dati a pezzi di 64 bit; non dice nulla sui registri floating point, i processori ARM avevano già da prima i registri FPU a 64 bit.

I cambiamenti ci sono su: numeri interi, i 64 bit processano numeri con dimensione doppia rispetto ai 32 bit; RAM assegnabile a un singolo processo, con i 32 bit è limitata a 4 GB, se ne vuole di più può ottenerla, ma è poco efficiente e difficile da implementare (il sistema dovrebbe forkare il processo, etc), il vantaggio c'è anche se non si ha molta memoria perché si possono avere dei memory-map file più grandi; puntatori, raddoppiano la dimensione e di conseguenza occupano più memoria.

Fin qui il discorso riguarda solo i 32 vs 64, nel caso della nuova architettura questi sono i cambiamenti specifici:

Numero di registri, quelli per gli interi sono raddoppiati di numero e quelli per i floating point sono pure aumentati; Registro condizionale, negli ARM 32bit c'era un registro che memorizzava una condizione e permetteva di compilare gli if senza dover fare il branching, l'hanno tolto perché sembra non funzionasse molto bene; C'è il nuovo NEON che a differenza dei vecchi 32 bit con singola precisione ora ha doppia precisione rispetto ai IEEE 754; Nuove istruzioni per la crittografia.

Di questi cambiamenti i più importanti sono il numero maggiore di registri e la doppia precisione del NEON.

Cambiamenti Apple: tagged pointers, in iOS con la nuova architettura si usano solo 33 bit (prima non c'erano i tagged pointers), il resto viene usato per salvare piccole quantità di dati.

Negli oggetti di Objcetive-c il primo pezzo di memoria è riservato all'isa (un puntatore), che punta alla classe dell'oggetto, questi puntatori devono essere divisibili per otto e così si risparmiano altri 3 bit (usano 30 bit invece di 33), tutto questo aiuta nel reference count.

In objcective-c il reference count non è memorizzato nella memoria assegnata all'oggetto ma in una hash table, pur essendo velocissima è sempre meno veloce di un accesso diretto alla memoria, ora però 19 dei 34 bit lasciati liberi dall'isa sono usati per incrementare/decrementare il reference count, ovviamente se c'è un overflow bisogna tornare all'hash table, ma si tratta in ogni caso di un boost enorme, il resto dei 34 bit è usato per altri compiti (per controllare se c'è una variabile weak che lo punta, etc.)

Il tutto si quantifica in un 50% di risparmio (in tempo) per poter creare e distruggere oggetti.

Ora rispondo sul fatto che il numero di core sia sempre due e che il clock sia sempre a 1.3 ghz.

Quattro core non sono necessariamente meglio di due, tutto dipende da come sono gestiti i periodi di turbo e idle, il fatto che il numero di core non sia aumentato non implica che le prestazioni non siano aumentate sostanzialmente.

I cambiamenti fatti da Apple sull'architettura riguardano la cache di L1 che è raddoppiata, e la velocità della banda per la memoria che è aumentata.

È vero che il numero di operazioni per ciclo di clock è sempre lo stesso, tuttavia la potenza di calcolo è aumentata di circa il 50% sugli interi e sui floating point (registri, dimensione degli interi...), anche la velocità della memory bandwidth è aumentata del 50%, tutti questi fattori aumentano le prestazioni nonostante il clock invariato.

Riguardo i gzh ci sarebbe da considerare anche il throttling, ma visto che i tablet e i telefoni non sono indicati per convertire i video si tratta di un aspetto marginale.

Rispetto alla vecchia generazione i cambiamenti ci sono stati, se si tratti di uno specchietto per le allodole usato dal marketing Apple non lo so e non m'interessa stabilirlo.

Per gli appassionati di bit qui c'è la fonte sul discorso dei tagged pointers: Hamster Emporium: [objc explain]: Non-pointer isa

È breve ma un po' pesante, il resto di quello che ho scritto lo trovate ovunque e quello riguardo la nuova architettura ARMv8 leggendo qualche spiegazione della sua documentazione.

PS Riguardo alle parole non presenti sul dizionario, su OS X il correttore automatico non mostra l'opzione per aggiungerle, bisogna selezionarle e cliccarci col tasto destro e infine aggiungerle, non avendo nessun iCoso non so se anche lì funzioni in questo modo.

Modificato 1 Dicembre 201311 anni fa da AR89

Togliere la scelta allo sviluppatore significa impedire all'utente di usare un'app fatta per telefono nel frattempo che lo sviluppatore l'adatta al tablet.

Sono d'accordo, troppo limitante.

La seconda opzione potrebbe rendere le applicazioni poco adatte agli schermi più grandi, perché gli sviluppatori potrebbero essere pigri e non adattarle ma lasciare che se la veda il sistema.

In entrambi i casi l'unica cosa che so per certa è che l'opzione che hanno scelto serve come incentivo a fare app adatte agli schermi più grandi (dovrei cercare la fonte ma la posso trovare), se sia una scelta giusta o sbagliata non lo so e non m'interessa stabilirlo.

Dal punto di vista dell'utente è una cagata pazzesca. Dal punto di vista dello sviluppatore pure. In altre parole è una cagata pazzesca al quadrato.

Mi ripeto, l'A7 ha le migliori performance attualmente e questo è obiettivamente vero visti i test fatti e i risultati consistenti (fin qui è tutto chiaro).

Nei vari confronti fra il 5S ed il Nexus 5 dotato di un volgarissimo Snapdragon 800 a 32bit (si fa per dire, l'800 è una bestia), queste performance inarrivabili non si notano affatto, eppure il N5 costa la metà.

Mi ripeto, l'A7 ha le migliori performance attualmente e questo è obiettivamente vero visti i test fatti e i risultati consistenti (fin qui è tutto chiaro).

Ora sfatiamo un po' di miti (voglio solo fare un discorso in generale sul processore, dopo rispondo):

i 64 di per sé non indicano la dimensione fisica degli indirizzi RAM (e di conseguenza la dimensione della RAM che il calcolatore può supportare), il modo in cui la CPU parla con la ram è indipendente da questo, negli ARM in genere la dimensione varia da 26 a 40 bit e può cambiare indipendente dai bit del processore (che possono indicare la dimensione dei registri o quella dei puntatori); non indicano la dimensione del data bus, l'iPhone 5 prelevava già i dati a pezzi di 64 bit; non dice nulla sui registri floating point, i processori ARM avevano già da prima i registri FPU a 64 bit.

I cambiamenti ci sono su: numeri interi, i 64 bit processano numeri con dimensione doppia rispetto ai 32 bit; RAM assegnabile a un singolo processo, con i 32 bit è limitata a 4 GB, se ne vuole di più può ottenerla, ma è poco efficiente e difficile da implementare (il sistema dovrebbe forkare il processo, etc), il vantaggio c'è anche se non si ha molta memoria perché si possono avere dei memory-map file più grandi; puntatori, raddoppiano la dimensione e di conseguenza occupano più memoria.

Fin qui il discorso riguarda solo i 32 vs 64, nel caso della nuova architettura questi sono i cambiamenti specifici:

Numero di registri, quelli per gli interi sono raddoppiati di numero e quelli per i floating point sono pure aumentati; Registro condizionale, negli ARM 32bit c'era un registro che memorizzava una condizione e permetteva di compilare gli if senza dover fare il branching, l'hanno tolto perché sembra non funzionasse molto bene; C'è il nuovo NEON che a differenza dei vecchi 32 bit con singola precisione ora ha doppia precisione rispetto ai IEEE 754; Nuove istruzioni per la crittografia.

Di questi cambiamenti i più importanti sono il numero maggiore di registri e la doppia precisione del NEON.

Cambiamenti Apple: tagged pointers, in iOS con la nuova architettura si usano solo 33 bit (prima non c'erano i tagged pointers), il resto viene usato per salvare piccole quantità di dati.

Negli oggetti di Objcetive-c il primo pezzo di memoria è riservato all'isa (un puntatore), che punta alla classe dell'oggetto, questi puntatori devono essere divisibili per otto e così si risparmiano altri 3 bit (usano 30 bit invece di 33), tutto questo aiuta nel reference count.

In objcective-c il reference count non è memorizzato nella memoria assegnata all'oggetto ma in una hash table, pur essendo velocissima è sempre meno veloce di un accesso diretto alla memoria, ora però 19 dei 34 bit lasciati liberi dall'isa sono usati per incrementare/decrementare il reference count, ovviamente se c'è un overflow bisogna tornare all'hash table, ma si tratta in ogni caso di un boost enorme, il resto dei 34 bit è usato per altri compiti (per controllare se c'è una variabile weak che lo punta, etc.)

Il tutto si quantifica in un 50% di risparmio (in tempo) per poter creare e distruggere oggetti.

Ora rispondo sul fatto che il numero di core sia sempre due e che il clock sia sempre a 1.3 ghz.

Quattro core non sono necessariamente meglio di due, tutto dipende da come sono gestiti i periodi di turbo e idle, il fatto che il numero di core non sia aumentato non implica che le prestazioni non siano aumentate sostanzialmente.

I cambiamenti fatti da Apple sull'architettura riguardano la cache di L1 che è raddoppiata, e la velocità della banda per la memoria che è aumentata.

È vero che il numero di operazioni per ciclo di clock è sempre lo stesso, tuttavia la potenza di calcolo è aumentata di circa il 50% sugli interi e sui floating point (registri, dimensione degli interi...), anche la velocità della memory bandwidth è aumentata del 50%, tutti questi fattori aumentano le prestazioni nonostante il clock invariato.

Riguardo i gzh ci sarebbe da considerare anche il throttling, ma visto che i tablet e i telefoni non sono indicati per convertire i video si tratta di un aspetto marginale.

Rispetto alla vecchia generazione i cambiamenti ci sono stati, se si tratti di uno specchietto per le allodole usato dal marketing Apple non lo so e non m'interessa stabilirlo.

Per gli appassionati di bit qui c'è la fonte sul discorso dei tagged pointers: Hamster Emporium: [objc explain]: Non-pointer isa

È breve ma un po' pesante, il resto di quello che ho scritto lo trovate ovunque e quello riguardo la nuova architettura ARMv8 leggendo qualche spiegazione della sua documentazione.

Ciao, io sono un esperto di architetture degli elaboratori (per lavoro, mica perchè mi diverto a farmi i segoni con le cpu), e il misturotto di nozionistica che hai scritto sopra non ha alcun senso compiuto.

Cioè, ci sono qua e la tracce di cose che hanno senso in architetture, e che compaiono qua e la nella documentazione delle specifiche ARM, ma sono mescolate a numeri casuali e a frasi che non sono nemmeno scritte in italiano corretto.

Conosco l'ARMv8-A, e so che la prima implementazione "commerciale" (e ribadisco commerciale, perchè esistono già implementazioni industriali ed aeronautiche) di tale standard è l'Apple A7. Ho accesso ai reference manual per lavoro, e li avevo letto parecchio tempo fa, ben prima che Apple se ne uscisse.

Io non so se il testo di cui sopra l'hai scritto tu, o se l'hai copiato, o se l'hai tradotto, e da dove l'hai fatto.

Ma non è un trattato, non ha né capo né coda, e ti consiglio vivamente un buon libro di testo, prima di metterti a fare il contropelo ai bit dei registri.

Tutto questo detto in amicizia e buona fede, sia chiaro.

Ma quando mi si spinge sul mio campo di competenza in modo gratuito, e soprattutto maldestro, io tendo a non essere mai cortese, non ho un carattere semplice, e vorrei evitare.

Detto questo, posso anche chiudere l'argomento "A7", perchè è così maledettamente inessenziale che ho davvero l'impressione di perdere tempo.

Ci sono molte altre cose utili di cui parlare, riguardo all'iPad Mini, ed ho aperto questo thread apposta.

Nei vari confronti fra il 5S ed il Nexus 5 dotato di un volgarissimo Snapdragon 800 a 32bit (si fa per dire, l'800 è una bestia), queste performance inarrivabili non si notano affatto, eppure il N5 costa la metà.

Non ho parlato di inarrivabili prestazioni.

Ciao, io sono un esperto di architetture degli elaboratori (per lavoro, mica perchè mi diverto a farmi i segoni con le cpu), e il misturotto di nozionistica che hai scritto sopra non ha alcun senso compiuto.

Cioè, ci sono qua e la tracce di cose che hanno senso in architetture, e che compaiono qua e la nella documentazione delle specifiche ARM, ma sono mescolate a numeri casuali e a frasi che non sono nemmeno scritte in italiano corretto.

Conosco l'ARMv8-A, e so che la prima implementazione "commerciale" (e ribadisco commerciale, perchè esistono già implementazioni industriali ed aeronautiche) di tale standard è l'Apple A7. Ho accesso ai reference manual per lavoro, e li avevo letto parecchio tempo fa, ben prima che Apple se ne uscisse.

Io non so se il testo di cui sopra l'hai scritto tu, o se l'hai copiato, o se l'hai tradotto, e da dove l'hai fatto.

Ma non è un trattato, non ha né capo né coda, e ti consiglio vivamente un buon libro di testo, prima di metterti a fare il contropelo ai bit dei registri.

Tutto questo detto in amicizia e buona fede, sia chiaro.

Ma quando mi si spinge sul mio campo di competenza in modo gratuito, e soprattutto maldestro, io tendo a non essere mai cortese, non ho un carattere semplice, e vorrei evitare.

Detto questo, posso anche chiudere l'argomento "A7", perchè è così maledettamente inessenziale che ho davvero l'impressione di perdere tempo.

Ci sono molte altre cose utili di cui parlare, riguardo all'iPad Mini, ed ho aperto questo thread apposta.

Anche io sono in totale buonafede per cui se ho scritto qualcosa di errato vorrei che me lo spiegassi (va bene in privato visto che hai aperto il topic per altri scopi).

Anche io sono in totale buonafede per cui se ho scritto qualcosa di errato vorrei che me lo spiegassi (va bene in privato visto che hai aperto il topic per altri scopi).

Artemis ti dirà la sua, io ti dico la mia: il fork non ha una cippa a che fare con il supporto della memoria oltre i 4Gb, con architetture a 32 bit il limite di 4Gb si supera con approcci come il PAE et similia. Qualcosa di simile al PAE c'è nello Snapdragon 805, ma il limite dei 4Gb per processo in uno smartphone o in un tablet è, per ora, solo psicologico.

Il discorso dei turbo e idle collegati ai core è senza senso. Il vantaggio di un'architettura a multicore si vede con il multithreading.

Il discorso dei tagged pointers è incomprensibile.

edit: dimenticavo: mentre sui PC il passaggio ad architetture a 64bit aveva come scopo quello di superare effettivamente ed efficientemente la barriera di 4Gb, su melofonini, che hanno una RAM abbondantemente sotto i 4Gb, questo è assolutamente inutile. Il vantaggio effettivo è rappresentato dal numero di registri che raddoppiano in numero ed in capacità (da 64 a 128bit). Questo è quello che fa la differenza rispetto alla generazione precedente. Il fatto che l'A7 supporti ottimamente la crittografia AES non dipende certo dal bus a 64bit, ma dal nuovo set di istruzioni crittografiche dell'ARMv8.

L'A7 ha una cache L1 maggiore di quella dello Snapdragon 800 che, a sua volta, ha una cache L2 doppia rispetto all'altro. Ci sono benchmark che danno come superiore l'uno e benchmark che danno superiore l'altro.

Modificato 1 Dicembre 201311 anni fa da loric