Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

The Division 2: come va con 17 schede video
The Division 2: come va con 17 schede video
The Division 2 è oggi uno dei videogiochi con la migliore grafica. In questo articolo scopriamo come ha lavorato Ubisoft e come gira The Division 2 con una serie di differenti hardware. Inoltre, esaminiamo con la lente d'ingrandimento gli effetti grafici che rendono la versione PC di The Division 2 la migliore sul piano della completezza grafica e della fedeltà visiva
VOIspeed UCloud, il centralino virtualizzato di TeamSystem
VOIspeed UCloud, il centralino virtualizzato di TeamSystem
Teamsystem trasferisce sulla nuvola anche il centralino aziendale. La soluzione si chiama VOiSpeed UCloud e promette di trasformare il modo in cui vengono gestite le chiamate che passano tramite i PBX aziendali, permettendo di avere un centralino telefonico unificato fra le varie sedi. L'aspetto più intrigante è che sul cloud transitano solo i dati di instradamento mentre le chiamate rimangono gestite dalle classiche linee analogiche e mobili.
moto g7 Plus, recensione: uno dei migliori smartphone midrange del 2019
moto g7 Plus, recensione: uno dei migliori smartphone midrange del 2019
moto g7 Plus si configura come uno dei migliori dispositivi di fascia media: costa 319 euro ma si può trovare anche a meno online, e si caratterizza per ottime qualità sia sul piano della qualità costruttiva, sia su quello dell'attenzione per i dettagli lato software. Dispone inoltre di alcune caratteristiche mutuate dalla fascia alta, come ad esempio la stabilizzazione ottica per la fotocamera posteriore, rappresentando il top di gamma della nuova serie moto g7 di Motorola
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 27-06-2018, 09:01   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75180
Link alla notizia: https://www.hwupgrade.it/news/cpu/sn...arm_76731.html

Qualcomm sarebbe al lavoro su un nuovo processore dedicato al mondo Windows on ARM: lo Snapdragon 1000, le cui caratteristiche termiche lasciano presagire prestazioni superiori agli attuali chip del produttore

Click sul link per visualizzare la notizia.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 09:42   #2
supertigrotto
Senior Member
 
Iscritto dal: Aug 2006
Messaggi: 1197
Dimostrazione pratica

Architettura Arm é superiore alla architettura x86 finché le istruzioni in gioco e la mole di calcoli in gioco sono semplici,allo scalare della complessità mica é tanto più efficiente della controparte,a sto punto era meglio rispolverare MIPS che a livello di efficienza,anche nello scalare,si è dimostrata migliore di Arm e l'unica in grado di impensierire l'architettura x86,idem per la architettura Power
supertigrotto è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 10:01   #3
nickname88
Senior Member
 
L'Avatar di nickname88
 
Iscritto dal: Apr 2016
Messaggi: 7804
Poveretti
Ma su desktop e workstation non s'ha da fare ....
nickname88 è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 10:02   #4
csavoi
Member
 
Iscritto dal: Jun 2005
Messaggi: 133
E' il software che comanda

Tutto dipende dal supporto software della nuova architettura.
Anche se MIPS e POWER hanno le carte più che in regola per essere più performanti delle soluzioni X86 e ARM, lato software sono carenti e quindi non ci si investirà mai sopra.

Viceversa ARM può contare sull'enorme sviluppo e diffusione dei software sui telefonini Android che, con ogni probabilità, potrebbero essere portati su ARM/Windows con più semplicità.

Cmq, spezzare il monopolio X86 può fare bene purchè ARM sia veramente competitiva, per attrarre nuovi sviluppatori e nuovi OEM deve avere un vantaggio del 30%-40% su INTEL/AMD in generale (ossia più prestazioni e minor costi progettuali e di silicio)
csavoi è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 11:05   #5
Yrbaf
Senior Member
 
Iscritto dal: Dec 2015
Messaggi: 3526
Adesso si usa ARM64 e tale ISA diversamente da ARM32 è molto Mips-like.
Yrbaf è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 12:19   #6
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3857
Quote:
Originariamente inviato da supertigrotto Guarda i messaggi
Architettura Arm é superiore alla architettura x86 finché le istruzioni in gioco e la mole di calcoli in gioco sono semplici,allo scalare della complessità mica é tanto più efficiente della controparte,a sto punto era meglio rispolverare MIPS che a livello di efficienza,anche nello scalare,si è dimostrata migliore di Arm e l'unica in grado di impensierire l'architettura x86,idem per la architettura Power
Come ha detto pure @Yrbaf l'architettura ARM64 (ARMv8 e successive evoluzioni) non a caso è molto simile a quella delle cpu MIPS ed (aggiungo io) a quella delle cpu Alpha di DEC (il top a livello di cpu a 64bit in termini di prestazioni per anni ed anni fintantoché DEC ha continuato ad investirci sopra una frazione di quello che spendeva Intel nello sviluppo degli x86).

Notare anche che qui si parla di un SoC che consuma max 12W con un area che è circa 1/4 di un core i5 U da 15W.
Se ottiene prestazioni decenti già così, a parità di area e di consumi di core+cache sono prevedibili caXXi amari per Intel.

Praticamente a quel punto la sopravvivenza di Intel dipenderebbe esclusivamente dalla retrocompatibilità con le vecchie applicazioni win32 e .Net che per un motivo o l'altro possono girare solo su cpu x86.
Non è un bel scenario considerando che Microsoft stessa sta spingendo il più possibile su UWP e verso l'abbandono di win32.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 12:49   #7
imayoda
Senior Member
 
L'Avatar di imayoda
 
Iscritto dal: Mar 2006
Città: Rimini
Messaggi: 3153
un altro processore per refreshare facebook,
ci sarà da ridere quando e se si passerà ad arm per programmi della suite adobe, autodesk etc.
__________________
Fisso: i7-2700k 16GB amd7770ghz Antec 420W Portatile: Asus eeePc 901 black Canon 20D NAS Synology 108j Ottimi affari con: skullboy, Dominioincontrastato, hard_one, Torpedo, SSLazio83, OIBAF, Celly, nemozx, jobe, Holy_knight, frank_durelli, ragingbull42, Enky, Truzzone, Lelez, elmanna, Keim, IroNLieR
imayoda è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 16:30   #8
tuttodigitale
Senior Member
 
Iscritto dal: Sep 2010
Messaggi: 3619
Quote:
Originariamente inviato da LMCH Guarda i messaggi
Notare anche che qui si parla di un SoC che consuma max 12W con un area che è circa 1/4 di un core i5 U da 15W.
le dimensioni di 45x24mm si riferiscono al package di Cannon Lake che contiene oltre la CPU/GPU anche il chipset.
Le mggiori dimensioni del package sono dovute alla necessità di avere un numero molto alto di pin per la maggior dotazione di risorse, basti pensare alla possibilità di avere una GPU discreta.
Grazie tante se il package è più piccolo....

le dimensioni del die di uno snapdragon 835 è di 73,5mmq poco più di quello di CL (71mmq), e poco meno di quello skylake (82mmq).
Ci vuole un miracolo per ridurre le dimensioni a meno di 20mmq....
tuttodigitale è offline   Rispondi citando il messaggio o parte di esso
Old 27-06-2018, 23:29   #9
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3857
Quote:
Originariamente inviato da tuttodigitale Guarda i messaggi
le dimensioni di 45x24mm si riferiscono al package di Cannon Lake che contiene oltre la CPU/GPU anche il chipset.
Le mggiori dimensioni del package sono dovute alla necessità di avere un numero molto alto di pin per la maggior dotazione di risorse, basti pensare alla possibilità di avere una GPU discreta.
Grazie tante se il package è più piccolo....

le dimensioni del die di uno snapdragon 835 è di 73,5mmq poco più di quello di CL (71mmq), e poco meno di quello skylake (82mmq).
Ci vuole un miracolo per ridurre le dimensioni a meno di 20mmq....
Capisco. Nell'articolo la cosa non era chiara.
Resta comunque un chippetto a cui Intel può solo contrapporre la retrocompatibilità con il software x86 legacy.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2018, 06:57   #10
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 5419
non sono aggiornato, e non è strettamente a tema, anche se decisamente collegato
come lo stato dell'arte riguardo alla questione della 'emulazione' delle chiamate x86 tramite arm e relativa 'dichiarazione di guerra' legale da parte di intel?
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2018, 07:04   #11
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 23659
Quote:
Originariamente inviato da LMCH Guarda i messaggi
Capisco. Nell'articolo la cosa non era chiara.
Resta comunque un chippetto a cui Intel può solo contrapporre la retrocompatibilità con il software x86 legacy.
Ma anche no: vedi le prestazioni. x86/x64 hanno ottime prestazioni in single core/thread, nonostante siano un'architettura CISC abbastanza complicata (ARMv8/ARM64 ha il vantaggio di essere stata completamente riprogettata).

Questo perché un'architettura CISC (come quella) ha comunque la possibilità di poter eseguire più "lavoro utile". Ad esempio è il motivo per cui i primissimi Atom, nonostante fossero in-order (a 2 vie), arrivavano a competere coi Cortex-A15, che erano out-of-order a 3 vie, pur con un processo produttivo penoso (e consumavano pure molto meno).

Inoltre x86/x64 hanno unità SIMD più potenti rispetto a qualunque ARM (attuale; almeno finché non arriverà la nuova unità vettoriale che ARM ha presentato un paio d'anni fa, ma dovremo vedere come si comporterà sul campo), e CannonLake poi si porta dietro la nuovissima AVX-512, che è un autentico gioiello (oltre a consumare un sacco di spazio su chip, coi suoi 32 registri a 512 bit, e annesse unità di calcolo a 512 bit. Ecco perché c'è tutta quella differenza di dimensione).

Checché se ne dica, x86/x64 possono ancora dire la loro.

/OT
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Non ho più tempo di frequentare il forum. Eventualmente, contattatemi in PVT.
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2018, 10:54   #12
tuttodigitale
Senior Member
 
Iscritto dal: Sep 2010
Messaggi: 3619
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ma anche no: vedi le prestazioni. x86/x64 hanno ottime prestazioni in single core/thread, nonostante siano un'architettura CISC abbastanza complicata (ARMv8/ARM64 ha il vantaggio di essere stata completamente riprogettata).

Questo perché un'architettura CISC (come quella) ha comunque la possibilità di poter eseguire più "lavoro utile". Ad esempio è il motivo per cui i primissimi Atom, nonostante fossero in-order (a 2 vie), arrivavano a competere coi Cortex-A15, che erano out-of-order a 3 vie, pur con un processo produttivo penoso (e consumavano pure molto meno).

Inoltre x86/x64 hanno unità SIMD più potenti rispetto a qualunque ARM (attuale; almeno finché non arriverà la nuova unità vettoriale che ARM ha presentato un paio d'anni fa, ma dovremo vedere come si comporterà sul campo), e CannonLake poi si porta dietro la nuovissima AVX-512, che è un autentico gioiello (oltre a consumare un sacco di spazio su chip, coi suoi 32 registri a 512 bit, e annesse unità di calcolo a 512 bit. Ecco perché c'è tutta quella differenza di dimensione).

Checché se ne dica, x86/x64 possono ancora dire la loro.

/OT
la differenza la fanno anche le ottimizzazioni....il fatto di contrapporre ad un ASICs ad un chip custom dà al mondo X86 un vantaggio tale ad alta frequenza da annullare qualsiasi penalità dovuta alla maggior complessità della logica x86.
tuttodigitale è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2018, 17:15   #13
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 23659
I più grandi produttori di chip ARM (Qualcomm, Samsung, Huawei, Apple) utilizzano soluzioni custom, infatti.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Non ho più tempo di frequentare il forum. Eventualmente, contattatemi in PVT.
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 28-06-2018, 18:54   #14
yankeeone
Member
 
L'Avatar di yankeeone
 
Iscritto dal: Sep 2007
Città: Larciano (Pistoia)
Messaggi: 147
é un SOC non una CPU

Chi dice che lo Snapdragon 1000 é solo una cpu (e lo confronta solo con il DIE della cpu Inte) si sbaglia, lo snapdragon 1000 é un SOC dotato di cores, memory controller, chipset, controller di archiviazione, gpu (adreno) e modem 5G.
Il TDP é relativo a tutto il SOC (GPU, MMC, MODEM) perciò il confronto delle aree scritto sull'articolo é corretto.
Sarà una bella bestiolina.
Peccato che per problemi di licenze (grazie Intel) non possano emulare x86_64 ma solo x86.
yankeeone è offline   Rispondi citando il messaggio o parte di esso
Old 29-06-2018, 17:43   #15
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 23659
E' AMD ad avere inventato x86_64/x64, e non Intel. Intel ha inventato IA-32/x86 (sul quale x64 è basato). Intel e AMD hanno un accordo di cross-licensing. Quindi, eccezion fatta per la parte ereditata da x86, di x64 dovrebbe essere AMD a occuparsene, e non Intel.

Anche le CPU di Intel, per il restom sono sostanzialmente dei SoC, visto che incorporano anche loro non soltanto i core veri e propri, ma nel cosiddetto "uncore" annoverano anche controller della memoria, del PCI-Express, GPU, e altra roba.

Manca il modem 5G, in effetti, ma del resto non sappiamo esattamente cosa ci sia in entrambi i SoC (ad esempio il controller PCI-Express occupa anch'esso spazio nei SoC Intel, che mettono a disposizione numerose linee a riguardo).

In ogni caso la notizia non riporta esattamente la dimensione dei core di entrambi i SoC.

Ricordo soltanto che tempo fa erano state riportate delle immagini con annesse dimensioni dei soli core, e quelli di Intel erano sì più grandi, ma non molto rispetto a quelli ARM (di Apple, che sono quelli che offrono prestazioni più elevate) con cui erano confrontati.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Non ho più tempo di frequentare il forum. Eventualmente, contattatemi in PVT.
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 30-06-2018, 02:03   #16
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3857
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ma anche no: vedi le prestazioni. x86/x64 hanno ottime prestazioni in single core/thread, nonostante siano un'architettura CISC abbastanza complicata (ARMv8/ARM64 ha il vantaggio di essere stata completamente riprogettata).

Questo perché un'architettura CISC (come quella) ha comunque la possibilità di poter eseguire più "lavoro utile". Ad esempio è il motivo per cui i primissimi Atom, nonostante fossero in-order (a 2 vie), arrivavano a competere coi Cortex-A15, che erano out-of-order a 3 vie, pur con un processo produttivo penoso (e consumavano pure molto meno).

Inoltre x86/x64 hanno unità SIMD più potenti rispetto a qualunque ARM (attuale; almeno finché non arriverà la nuova unità vettoriale che ARM ha presentato un paio d'anni fa, ma dovremo vedere come si comporterà sul campo), e CannonLake poi si porta dietro la nuovissima AVX-512, che è un autentico gioiello (oltre a consumare un sacco di spazio su chip, coi suoi 32 registri a 512 bit, e annesse unità di calcolo a 512 bit. Ecco perché c'è tutta quella differenza di dimensione).

Checché se ne dica, x86/x64 possono ancora dire la loro.

/OT
A15 era un ARMv7 (32 bit con set d'istruzioni limitato dai flag di esecuzione condizionale, per quel che riguarda l'esecuzione out-of-order) era progettato per essere un ARM "più potente" (sempre restando nell'ambito mobile del periodo) e per quel che riguardava i consumi, gli Atom andavano a scontrarsi anche con i SoC basati su A7 e li le prendevano di brutto sotto quell'aspetto.
In Intel pensavano di contrapporre una singola linea di SoC contro una serie di linee distinte di SoC compatibili a livello di applicazioni tra loro ma che privilegiavano di volta in volta caratteristiche differenti e si è visto come è andata a finire.
Gli x86/64 possono ancora dire la loro, ma ora i produttori di chip ARM stanno iniziando a prendere di mira settori dominati da x86/64 ed Intel non sembra avere una strategia migliore se non sperare che la retrocompatibilità con le applicazioni x86 sia una feature ancora irrinunciabile in quei settori.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 30-06-2018, 08:00   #17
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 23659
Quote:
Originariamente inviato da LMCH Guarda i messaggi
A15 era un ARMv7 (32 bit con set d'istruzioni limitato dai flag di esecuzione condizionale, per quel che riguarda l'esecuzione out-of-order) era progettato per essere un ARM "più potente" (sempre restando nell'ambito mobile del periodo) e per quel che riguardava i consumi, gli Atom andavano a scontrarsi anche con i SoC basati su A7 e li le prendevano di brutto sotto quell'aspetto.
Ma venivano polverizzati lato prestazionale, incluso l'A9 (l'A7 non c'era ancora all'epoca di quei test) che era parzialmente out-of-order.

Sì, erano ARMv7 a 32 bit, ma gli Atom erano x86 e non x64 (quindi col classico set d'istruzioni nato con gli 80386: appena 8 registri in totale, e quindi facendo uno spasmodico uso dello stack per le variabili temporanee. ARMv7, per contro, offriva 16 registri, esecuzione condizionale, e istruzioni a 3 operandi: vedi tu che differenza c'era).

Ne abbiamo già parlato in passato, e avevo anche riportato un articolo di Extremetech che analizzava questi processori sia dal punto di vista prestazionale sia dei consumi: The final ISA showdown: Is ARM, x86, or MIPS intrinsically more power efficient?
Quote:
In Intel pensavano di contrapporre una singola linea di SoC contro una serie di linee distinte di SoC compatibili a livello di applicazioni tra loro ma che privilegiavano di volta in volta caratteristiche differenti e si è visto come è andata a finire.
Sì, ma è andata finire così anche perché su mobile è accaduto, e accade, quello che specularmente è successo e succede su desktop: ARM s'è presa il mercato, ed è diventata dominante. Per cui Intel, come pure altri produttori di processori (IBM/Freescale & co. con PowerPC; Infineon con MIPS) che hanno provato a entrarci, è rimasta fuori nonostante gli enormi investimenti e i buoni prodotti (a mio avviso è stato stupido abbandonare proprio quando ormai aveva un prodotto, ApolloLake, molto competitivo anche lato consumi).

Il legacy. La retro/compatibilità.

Solita questione, insomma.
Quote:
Gli x86/64 possono ancora dire la loro, ma ora i produttori di chip ARM stanno iniziando a prendere di mira settori dominati da x86/64 ed Intel non sembra avere una strategia migliore se non sperare che la retrocompatibilità con le applicazioni x86 sia una feature ancora irrinunciabile in quei settori.
Vedi sopra. Lato server, dove si sente di gran lunga mano la questione legacy, sono anni che ci provano, ma non sono riusciti a entrare lo stesso, tanto che qualche mese fa c'erano voci che circolavano e che dicevano che Qualcomm starebbe valutando di rinunciare al mercato server dopo tutti gli investimenti che ha fatto.

Evidentemente non è solo questione di legacy.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Non ho più tempo di frequentare il forum. Eventualmente, contattatemi in PVT.
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 30-06-2018, 22:49   #18
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3857
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ma venivano polverizzati lato prestazionale, incluso l'A9 (l'A7 non c'era ancora all'epoca di quei test) che era parzialmente out-of-order.
Giusto, ma era il lato costo + consumi ad essere più rilevante in fascia bassa e li non c'era storia.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ne abbiamo già parlato in passato, e avevo anche riportato un articolo di Extremetech che analizzava questi processori sia dal punto di vista prestazionale sia dei consumi: The final ISA showdown: Is ARM, x86, or MIPS intrinsically more power efficient?
Quello è un confronto che usa benchmark "classici" e non casi d'uso tipici dei dispositivi tipo smartphone e tablet, dove le cpu non girano a lungo a pieno carico (e dove l'efficienza energetica a pieno carico è meno rilevante).

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Sì, ma è andata finire così anche perché su mobile è accaduto, e accade, quello che specularmente è successo e succede su desktop: ARM s'è presa il mercato, ed è diventata dominante. Per cui Intel, come pure altri produttori di processori (IBM/Freescale & co. con PowerPC; Infineon con MIPS) che hanno provato a entrarci, è rimasta fuori nonostante gli enormi investimenti e i buoni prodotti (a mio avviso è stato stupido abbandonare proprio quando ormai aveva un prodotto, ApolloLake, molto competitivo anche lato consumi).

Il legacy. La retro/compatibilità.

Solita questione, insomma.
Vuoi dire che il maggior consumo di batteria nei casi d'uso reali non era un problema?
La retrocompatibilità non era un problema, ti sto scrivendo con un tablet android con cpu x86 e non ho mai avuto problemi legati ad app che non girano su x86, nonostante Intel abbia mollato tablet e smartphone da anni.
Questo tablet l'ho preso per il display da 12", si noti bene, non per il tipo di cpu che ha (a cui è abbinata una batteria da 12000mAh, si noti bene)


Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Vedi sopra. Lato server, dove si sente di gran lunga mano la questione legacy, sono anni che ci provano, ma non sono riusciti a entrare lo stesso, tanto che qualche mese fa c'erano voci che circolavano e che dicevano che Qualcomm starebbe valutando di rinunciare al mercato server dopo tutti gli investimenti che ha fatto.

Evidentemente non è solo questione di legacy.
Anche lato server esistono il lato legacy e le economie di scala a ivello di manutenzione e supporto del parco hardware e software installato ha il suo bel peso pure li.
LMCH è offline   Rispondi citando il messaggio o parte di esso
Old 01-07-2018, 08:56   #19
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 23659
Quote:
Originariamente inviato da LMCH Guarda i messaggi
Giusto, ma era il lato costo + consumi ad essere più rilevante in fascia bassa e li non c'era storia.
All'epoca a Intel non interessava quella fascia bassa.

I primi Atom, come già detto, erano in-order a 2 vie: per fare "di meno" Intel avrebbe dovuto rispolverare il design del 486 o addirittura del 386. Cosa che ha fatto un po' di anni dopo con la famiglia Quark.
Quote:
Quello è un confronto che usa benchmark "classici" e non casi d'uso tipici dei dispositivi tipo smartphone e tablet, dove le cpu non girano a lungo a pieno carico (e dove l'efficienza energetica a pieno carico è meno rilevante).
Permettimi: si parlava (anche tu l'hai fatto) di prestazioni, e quindi quei test erano perfettamente pertinenti.
Quote:
Vuoi dire che il maggior consumo di batteria nei casi d'uso reali non era un problema?
Lo era, certamente, ma per altri motivi.

Primo, Intel non usava (e non usa ancora) processi low-power.

Secondo, Intel non aveva nulla di simile al big.little, che è nato apposta per ridurre i consumi.

Per il terzo vedi sotto.
Quote:
La retrocompatibilità non era un problema, ti sto scrivendo con un tablet android con cpu x86 e non ho mai avuto problemi legati ad app che non girano su x86, nonostante Intel abbia mollato tablet e smartphone da anni.
Questo tablet l'ho preso per il display da 12", si noti bene, non per il tipo di cpu che ha (a cui è abbinata una batteria da 12000mAh, si noti bene)
La retrocompatibilità, invece, era un problema, perché la stragrande maggioranza dei binari (mi riferisco alle app che usano l'NDK qui. Non a quelle Java, che ovviamente non hanno di queste problematiche) che scaricavi/chi dal Playstore sono ARM, e Intel ha dovuto mettere in piedi un emulatore allo scopo (si chiama Houdini), che purtroppo è tutt'altro che perfetto, oltre a richiedere costante manutenzione (causa nuove API di Android e/o nuove app che non funzionano bene con la versione attuale e necessitano di apposite patch).

Questo ovviamente va incidere, e pure molto, sulla batteria, visto che non soltanto il gioco (perché in realtà sono quasi tutti giochi le app che usano NDK, e che quindi sono CPU-intensive) deve girare, ma deve farlo con un emulatore sotto che genera codice tutt'altro che ottimizzato (i compilatore JIT online non possono certo fare miracoli, a meno di impiegare ENORMI risorse per tracciare il funzionamento globale del codice. Cosa che ha senso fare, e si fa, soltanto AoT: quando si compila il sorgente).

Tirando le somme, con questi tre handicap mi pare ovvio che i consumi fossero più elevati.

Con Apollolake Intel è riuscita a ottimizzare meglio il processo produttivo (pur rimanendo HP e non LP) e la microarchitettura, migliorando di conseguenza anche i consumi, ma incredibilmente ha deciso di uscire dal mercato del mobile (in pratica senza nemmeno provare). Bah...
Quote:
Anche lato server esistono il lato legacy e le economie di scala a ivello di manutenzione e supporto del parco hardware e software installato ha il suo bel peso pure li.
Non è un mistero che già da tempo Google faccia girare tranquillamente i suoi server anche su piattaforme POWER di IBM, come pure sia interessata e stia lavorando anche con RISC-V. Architetture che non hanno nulla a che vedere con x86/x64.

Se ci riesce Google, che ha business estremamente variegati in ambito server, vuol dire che il legacy, almeno in quest'ambito, non incida un granché...
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Non ho più tempo di frequentare il forum. Eventualmente, contattatemi in PVT.
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 02-07-2018, 18:43   #20
LMCH
Senior Member
 
Iscritto dal: Jan 2007
Messaggi: 3857
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
All'epoca a Intel non interessava quella fascia bassa.

I primi Atom, come già detto, erano in-order a 2 vie: per fare "di meno" Intel avrebbe dovuto rispolverare il design del 486 o addirittura del 386. Cosa che ha fatto un po' di anni dopo con la famiglia Quark.
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Permettimi: si parlava (anche tu l'hai fatto) di prestazioni, e quindi quei test erano perfettamente pertinenti.
Non erano pertinenti ai casi d'uso di quei dispositivi, in cui i profili di utilizzo davano un vantaggio a chi seppur con prestazioni minori e consumi più alti con le cpu al 100% riusciva aconsumare meno negli altri scenari molto più frequenti.

(consumo batterie nei casi d'uso reali)
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Lo era, certamente, ma per altri motivi.

Primo, Intel non usava (e non usa ancora) processi low-power.

Secondo, Intel non aveva nulla di simile al big.little, che è nato apposta per ridurre i consumi.
Già, su questo concordo perfettamente.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Per il terzo vedi sotto.

La retrocompatibilità, invece, era un problema, perché la stragrande maggioranza dei binari (mi riferisco alle app che usano l'NDK qui. Non a quelle Java, che ovviamente non hanno di queste problematiche) che scaricavi/chi dal Playstore sono ARM, e Intel ha dovuto mettere in piedi un emulatore allo scopo (si chiama Houdini), che purtroppo è tutt'altro che perfetto, oltre a richiedere costante manutenzione (causa nuove API di Android e/o nuove app che non funzionano bene con la versione attuale e necessitano di apposite patch).

Questo ovviamente va incidere, e pure molto, sulla batteria, visto che non soltanto il gioco (perché in realtà sono quasi tutti giochi le app che usano NDK, e che quindi sono CPU-intensive) deve girare, ma deve farlo con un emulatore sotto che genera codice tutt'altro che ottimizzato (i compilatore JIT online non possono certo fare miracoli, a meno di impiegare ENORMI risorse per tracciare il funzionamento globale del codice. Cosa che ha senso fare, e si fa, soltanto AoT: quando si compila il sorgente).
Anche questo è vero, ma già con i Cherry Trail il problema "retrocompatibilità ARM" ormai non esisteva più (almeno per app recenti).
In quel periodo sviluppavo app per industria e domotica in cui si andava pesantemente di NDK (per far girare sorgenti C++ codificati in origine per dispositivi desktop ed embedded "fissi") e nonostante si andasse pesanti ed in profondità gli unici dispositivi che davano problemi erano quelli Samsung con SoC Marvell (driver GPU scritti con il cuo, c'era un bug di inizializzazione che veniva re-introdotto ad update alterne, non so se dipendesse da chi gestiva il firmware in Samsung o in Marvell).

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Con Apollolake Intel è riuscita a ottimizzare meglio il processo produttivo (pur rimanendo HP e non LP) e la microarchitettura, migliorando di conseguenza anche i consumi, ma incredibilmente ha deciso di uscire dal mercato del mobile (in pratica senza nemmeno provare). Bah...
Su questo sono pienamente d'accordo, almeno su tablet da 10"..13" con display ad alta risoluzione (e batterie belle grosse) già i Cherry Trail si difendevano bene, specialmente se gli si faceva girare sopra qualcosa da "vero" tablet con UI complessa, grafica più pesante e maggior utilizzo di CPU e GPU a piena potenza rispetto al caso d'uso "smartphone".

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Non è un mistero che già da tempo Google faccia girare tranquillamente i suoi server anche su piattaforme POWER di IBM, come pure sia interessata e stia lavorando anche con RISC-V. Architetture che non hanno nulla a che vedere con x86/x64.

Se ci riesce Google, che ha business estremamente variegati in ambito server, vuol dire che il legacy, almeno in quest'ambito, non incida un granché...
Se è per questo sia Google che Microsoft lavorano pure sul design di nuove cpu (tipo il progetto EDGE di Microsoft, da non confondere con il browser Edge).

Lo fanno sia per avere sia uno strumento di pressione su Intel quando si tratta di discutere dei costi delle cpu che per avere un piano B (o anche C e D) nel caso discutere non basti più.

Ma non si cambia tipologia di cpu giusto per il gusto di farlo o solo perche si hanno prestazioni superiori senza considerare altri fattori (altrimenti negli anni '90 le cpu Alpha avrebbero spazzato via gli x86).
LMCH è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


The Division 2: come va con 17 schede video The Division 2: come va con 17 schede video
VOIspeed UCloud, il centralino virtualizzato di TeamSystem VOIspeed UCloud, il centralino virtualizzato di ...
moto g7 Plus, recensione: uno dei migliori smartphone midrange del 2019 moto g7 Plus, recensione: uno dei migliori smart...
Fujifilm XF10: APS-C da taschino. La videorecensione Fujifilm XF10: APS-C da taschino. La videorecens...
Samsung Galaxy S10+: il miglior regalo agli utenti per il decimo anniversario. La recensione Samsung Galaxy S10+: il miglior regalo agli uten...
Oracle mostra la sua visione di smart ci...
Il corso essenziale di Adobe Photoshop C...
Vampire: The Masquerade - Bloodlines 2 a...
UE4 avrà il Ray Tracing dal 26 ma...
Archos Play Tab, un super-tablet da 21,5...
Nuova grafica di Steam mostrata alla GDC
Dogfish SuperEIGHT: la birra per svilupp...
Tesla Model Y, online il configuratore i...
Heavy Rain, Beyond e Detroit saranno esc...
Toshiba ha reso più sicuri i note...
Tamron: lo sviluppo per ottiche per Cano...
Un cortometraggio realizzato con Unreal ...
Panasonic Toughbook T1 e Toughbook N1 so...
Windows 7, fine degli aggiornamenti di s...
Sekiro: Shadows Die Twice ora disponibil...
LibreOffice 6.2.0
HyperSnap
Internet Download Manager
Opera Portable
Opera 58
AIDA64 Extreme Edition
Mozilla Thunderbird 60
PassMark BurnInTest Professional
PassMark BurnInTest Standard
Dropbox
Chromium
Driver NVIDIA Creator Ready 419.67 WHQ
Radeon Software Adrenaline Edition 19.
K-Lite Codec Tweak Tool
NTLite
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 06:02.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Served by www2v
1