07 Giugno 2018
Aggiornamento 22/06
WinFuture ha avuto modo di snocciolare ulteriori dettagli attorno a Snapdragon 1000, il prossimo SoC Qualcomm dedicato ai computer Windows on Arm. Per prima cosa viene confermato il codice SDM1000, quindi non ci sono dubbi sulla nomenclatura che verrà adottata dal chip, così come è stato appurato il TDP di 12 Watt ipotizzato in precedenza.
Una novità importante riguarda il fatto che il SoC verrà alloggiato in un socket, quindi non sarà integrato nella scheda madre del prodotto. Stando a quanto emerso, la piattaforma di sviluppo è attualmente equipaggiata con 16GB di memoria LPDDR4X e due moduli di memoria UFS 2.1 da 128GB ciascuno.
Insomma, Snapdragon 1000 potrebbe essere il primo SoC Arm in grado di competere ad armi pari con alcune delle soluzioni Intel pensate per la stessa categoria di prodotto. Ora non si parla più di un chip proveniente dal mondo smartphone e riadattato all'utilizzo su PC, bensì di una piattaforma che nasce appositamente per supportare al meglio Windows on Arm.
Articolo originale del 7 giugno
Snapdragon 1000 potrebbe essere il più ambizioso passo compiuto Qualcomm nel mondo dei PC basati su Windows on Arm. Avvistato pochi giorni fa, poco prima del debutto di Snapdragon 850, il SoC in questione dovrebbe essere dedicato esclusivamente all'impiego nei portatili sempre connessi. Oggi emerge un nuovo rumor riportato da WinFuture che ci suggerisce quella che potrebbe essere una delle caratteristiche chiave di Snapdragon 1000: un TDP da ben 12 Watt.
Se ciò dovesse essere confermato, si tratterebbe del primo SoC Arm ad esibire un TDP solitamente ad appannaggio dei chip Intel dedicati ai portatili. La mossa di Qualcomm sembra essere proprio una sfida diretta allo strapotere della casa di Santa Clara in ambito Windows.
Un chip Arm con un TDP da 12 W potrebbe impiegare core molto più grandi e complessi di quelli attualmente presenti sugli smartphone e persino sul più recente Snapdragon 850, il quale non si spinge oltre i 6,5 W. Qualcomm potrebbe far affidamento sul processo produttivo a 7nm di TSMC, applicato alla propria variante custom dei nuovi core Cortex-A76, spingendoli verso frequenze vicine ai 3,0GHz per un periodo di tempo decisamente superiore rispetto a quanto possibile su smartphone e tablet.
Qualcomm ha dalla sua la possibilità di offrire SoC capaci di autonomie impressionanti in ambito Windows, senza rinunciare alla presenza di modem di classe Gigabit sempre attivi. Intel non starà sicuramente a guardare e già nelle scorse ore ha dimostrato particolare interesse verso la realizzazione di nuove proposte a basso consumo, probabilmente basate sul suo processo produttivo a 10nm (non comparabile con i 7nm di TSMC).
Commenti
E ripeto il TDP è un dato tecnico non commerciale, i commercianti lo hanno trasformato in altro a livello commerciale.
Snapdragon di solito neanche lo fornisce.
Sei tu che confondi i dati di progettazione con quelli commerciali.
Al pubblico arriva sempre e comunque quello commerciale, a prescindere da chi sia il produttore. Resta comunque una scelta totalmente discrezionale.
Se per OS intendi Windows, e non vedo come altro potrebbe essere visto che parliamo di Windows on ARM, allora è a 32 bit.
Se invece intendi che AL DI FUORI del sistema di emulazione Intel potrebbe venir eseguito codice PE compilato per ARM 64, allora sì può essere fatto.
Ma questo non fa del sistema operativo nulla di diverso da un 32 bit.
Ma l'os è a 64bit. È un fatto inconfutabile.
Mi sa che ti sei fatto confondere dai sensi commerciali. Non sta al produttore decidere come calcolarlo, é il punto di riferimento per il progetto termico è tale deve essere.
Solo intel si è inventata il suo tdp, tutte le altre case, amd in testa fornisce il vero tdp
Facciamo così: guardati i test di CPU Intel e poi dimmi che il TDP dichiarato dia il worst case.
Ma chi se ne frega.
Il TDP è utile per i desktop, perché ti serve come indicazione per psu e raffreddamento. E da sempre per il TDP conviene guardare i test.
Sui notebook non è mai stato davvero rilevante se non in modo indicativo.
No, dipende dal produttore. In generale sono um ottimo compromesso tra consumi e prestazioni.
è migliore in efficienza a basse prestazioni, lo scaling non è lineare
Scaffale ™
E le marmotte confezionano cioccolata
Ma qualche informazione sull'Adreno?
Immagino che su Snapdragon 1000 sarà integrata una GPU altrettanto valida da concorrere con una Nvidia MX150.
Ottimi non direi.
E generano parecchio calore.
Sta diventando insostenibile la cosa di anno in anno.
In entrambi i casi ti devi fidare fino a quando non uscirá un report tdpgate (dopo il dieselgate ci manca anche questo)
No rappresenta la Potenza termica da dissipare non il calore infatti si misura in watt (non leggere Wikipedia che la scrivono dei cani).
Il riferimento della TDP é il worst case che è la massima Potenza che deve essere dissipata quando il processore è mandato a massimo regime, quella a cui si riferiscono tutte le "persone normali".
Intel ha dato una sua definizione di TDP commerciale (precisando che i progettisti DEVONO fare riferimento alla sezione termica del datasheet dove forniscono il vero tdp), amd la chiama ATP.
L'alimentatore lo prendi sovradimensionato sui consumi stimati della somma delle componenti. Se lo prendi usando il TDP come valore esatto vedrai come ti si spegnerà il pc come alzi il carico.
Comunque sei libero di non credermi. Quello che ho scritto lo puoi leggere in qualunque recensione di hardware.
Ps: il TDP è in tutte le schede tecniche. Solo nei SoC per smartphone non lo trovi da quel che ho visto fino ad ora, ma perché tu utente ci faresti poco.
Ni, alla fine dipende sempre da quanto il produttore vuole essere onesto.
Nah. I Core M sono generalmente ottimi per efficienza. Se si vuole solo l'autonomia si punta sulle CPU ULV, i Core M sono pensati per dare anche prestazioni quando serve.
Beh... no.
In che senso è comunque a 64 bit?
Ai fini di Windows e del software Win32 è a 32 bit.
Io posso avere pure una CPU a un milione di bit, ma se poi questo milione di bit lo uso per emulare una CPU a 32 bit il sistema che viene eseguito lì sopra vedrà 32 bit.
Il milione di bit lo vedrebbe solo il software compilato nativamente per quella CPU perchè non passerebbe per l'emulatore (vero in parte, perchè eventuali chiamate a sistema verrebbero poi gestite a 32 bit perchè l'OS guest è a 32 bit).
E' una presa in giro con la quale si sta tentando di infinocchiare il cliente. Tutto è basato sul ragionamento che prima o poi le maggiori software house inizieranno a compilare per ARM, un po' come in passato sostenevano prima che avrebbero iniziato a programmare per UWP e quando videro che NESSUNO programmava per UWP cominciarono a fire che avrebbero fatto i porting tramite Centennial,
Nessuno programma in UWP, nessuno fa porting Centennial in UWP e nessuno compilerà mai per ARM. Non esistono condizioni di mercato sufficienti a giustificare i costi.
Ok, ma il sistema è comunque a 64bit
Baci & Abbracci
Molto divertente... Tu invece sei laureato in comicità
Nessuno lo mette in dubbio.
Laureato in lettere?
Avrai studiato te su Wikipedia, io ho studiato all'università
No, non hai spiegato proprio nulla.
Cosa c'entrano gli obiettivi?
Non è che un obiettivo abbia un qualche influsso sulla categoria architetturale, semmai lo avrà sui dettagli implementativi.
A me invece sembra più che evidente di trovarmi dinanzi l'ennesimo sciocco con una cultura wikipediana, che prima scrive una castroneria e poi invece che scusarsi continua a cercare il modo di uscirne.
L'implementazione è differente solo a livello di decodifica, la parte seguente cambia solo per il numero di operandi (solitamente 2 per x86 e 3 per ARM)
Non ha senso dire "un RISC che emula un CISC"! Te l'ho già detto è spiegato.
Il clock e l'ipc sono gli obiettivi principali quando si progetta una microarchitettura, è evidente a questo punto che non sai una mazza di quello che dici.
Davide, ARM è già migliore di x86 da diversi anni in quanto efficienza (non è l'unico RISC ad esserlo...). Questo però non è detto basti per imporsi in un mercato già fortemente monopolizzato e con un'ecosistema solido. Vedremo.
In che senso non valgono?
Il fatto che un RISC emuli un CISC implica un disegno del processore differente proprio a causa dell'ISA.
Un ISA (Instruction Set Architecture per i neofiti) CISC ed un ISA RISC portano con sè una implementazione in termini di porte completamente differente, ma questo è assolutamente evidente per chi conosce come sono costruiti i microprocessori mentre evidentemente NON lo è a quanti (ad es. l'autore del post a cui rispondevo) dicono che in una architettura Intel al crescere dell'Instruction Set cresca in modo corrispondente la complessità architetturale perchè la maggior crescita è solo nel microcodice.
Ancor meno c'entrano le velocità di clock, la velocità & co., cosa introdotta da te.
La tua mi è sembrata una contestazione fatta per il puro gusto di contestare o, più probabilmente, è la contestazione fatta da uno che poi di è andato a leggere tra cose su Internet e si è accorto do aver scritto una bestialità.
Essere un RISC che emula un CISC cambia tutto a livello di architettura, intendendo con questo proprio il disegno del processore.
Sono il clock e la velocità a non entrarci assolutamente niente.
Credo tu abbia le idee un po' confuse. ;)
Che non è un RISC che emula un CISC, e soprattutto fa di microcodice solo per le istruzioni molto complesse, se lo facesse per tutte te lo sogni il clock a 4.0 ghz e l'ipc di 3.7, non arrivi a 1 nell'ipc e non arrivi a 1 ghz come velocità (più è grande il microcodice più è lento l'accesso).
Ho appena detto RISC e CISC sono proprietà dell'ISA, all'interno sia i RISC che i CISC hanno unità di decodifica che trasformano l'istruzione dell'ISA nei segnali di controllo interni e portano avanti solo quelli, per cui è una differenza che inizia al fetch e finisce al decode.
I segnali di controllo interni non costituiscono un'ISA quindi non valgono i discorsi del tipo "CISC emulato da RISC".
già ARM è migliore ci vuole sempre tempo e anni :) mi piacerebbe usare questo processore snap dragon 1000 spero sia 8 cores o magari 10 sarebbe bello ma ci arriveremo
Un'ora fa mi hai detto che confondevo i dettagli implementativi con il set di istruzioni sotto un mio post che diceva ESATTAMENTE le stesse cose che hai appena scritto.
Che succede, hai dato una rapida occhiata a Wikiperdia? :)
Mio post:
"Ma gli Intel non sono dei RISC che emulano dei CISC gestiti da microcodice?"
Quali sarebbero i fatti?
Il sistema operativo identifica sè stesso come Windows 10 32 bit e Microsoft stessa dice che NON esegue software 86 a 64 bit.
Devo dedurre che tu hai informazioni certe riguardo al fatto che Microsoft stia mentendo sul suo stesso prodotto?
... e tutto questo cosa c'entra con l'essere un RISC che emula un CISC eseguendo un micro codice?
tue supposizioni sbugiardate dai fatti.
No, quella non credo sia soggetta a brevetto.
In Intel i percorsi dell'architettura 32 bit e quella 64 bit furono differenti, mi pare di ricordare che in qualche modo ci sia entrata anche AMD ma è passato tanto tempo e io non mi sono mai interessato alla vicenda, comunque nulla di strano che sia brevettato solo uno dei due instruction set.
No, non funziona così.
La CPU emulata è x86_32 e quindi può eseguire unicamente software x86_32 in modalità emulata, e difatti anche il sistema operativo è il Windows 86 per x86_32.
Può eseguire codice s 64 bit ma solo al di fuori dell'emulazione, quindi codice ARM64, ma non esite software commerciale compiato per ARM64 e neppure esiterà mai, così come non esiste e non esisterà mai software commerciale scritto o portato su UWP.
Nota che sempre più spesso si compila per i soli target Intel a 64 bit perchè supportare anche l'architettura inferiore crea seri problemi nella scelta degli algoritmi da usare.
Anche un semplice sort, se deve essere veloce sul serio, viene scritto in modo differente se l'architettura sottostante e a 32 o a 64 bit e supportarle entrambe introduce un sacco di lavoro in più e di complicazioni.
Adesso partono quelli del RISC vs CISC e che "x86 è in realtà RISC".
Lo diciamo una volta sola per tutti: la complessità è in relazione all'ISA, non all'implementazione.
Per tutti quelli che "all'interno è.. etc" ricordo che per le microarchitetture a pipeline in order o out of order perdono l'istruzione all'inizio dello stadio "Decode" e portano avanti solo i segnali di controllo orizzontali per le unità di esecuzione durante tutti gli eventuali stadi, va così per tutti: per ARM, per Intel, per Apple, per AMD.
No è a tutti gli effetti un bel niente di tutto cio.
L'os gira a 64bit, le uwp a 32 e 64 bit, le win32 a 32bit. Fine. Sono fatti, che piacciano o meno.
Che poi si possa discutere su quanto sia limitante il solo supporto alle win32 a 32 bit è pacifico, ma il sistema è a tutti gli effetti a 64bit.
Sono fatti, inutile discuterne ancora.
Se il problema fossero le royalties non esisterebbe neanche l'emulazione a 32bit
Dovrebbero migliorare il prima possibile questo aspetto.
Alla fine sono passati 20 anni...
L'OS gira su un processore avviato a 64 bit che esegue codice ARM64 per emulare un x85_32, quindi è a tutti gli effetti un 32 bit sia per quel che riguarda il sistema operativo che per la CPU CISC (x86) che lo supporta.
Le UWP non esistono, dunque il problema non si pone.
? Risc o cisc è una proprietà dell'ISA, non dell'implementazione.
Da quando sono in pipeline le istruzioni interne sono come per tutti i segnali di controllo in orizzontale, quindi Word da 200/300 bit.
Quanto al "non si fanno pagare" la normativa internazionale sui brevetti impone ai detentori del brevetto di concederne l'utilizzo dietro un "equo compenso"
Cosa si debba intendere con "equo compenso" non è specificato, quindi da sempre le aziende sono state libere di fissare il loro "equo compenso" ad un livello tale da trasformarlo in una sostanziale impossibilità.
Se Intel ha voglia di chiedere mille dollari per ogni copia di emulatore commerciale in grado di SSE e VT-X non esiste modo di impedirlo, è quello che hanno sempre fatto e continuano a fare tutti.
Va da sè che senza SSE non si mette sul mercato proprio nessun Windows 10 a 64 bit (e ormai neppure nessun applicativo, visto che TUTTI compiliamo flaggando il supporto ad SSE).
Confondere dettagli implementativi con il set di istruzioni.
Il set di istruzioni x86 è un set complesso, inconsistente e lungo da decifrare, la CPU ha problemi in molti casi a decodificare le istruzioni in un solo ciclo, per cui tutte le microarchitetture attuali usano un grosso buffer di istruzioni già decodificate che nei cicli permette di spegnere le 4 unità di decodifica per core.
Per il set interno non ha senso parlare di caratteristiche e regolarità in quanto si tratta semplicemente di Word enormi contenenti tutti i segnali di controllo della CPU nelle varie fasi, segnali di controllo che differiscono da generazione a generazione e che non ha senso rilasciare.
Arm ha un ISA più regolare e più consistente per cui ha meno problemi di timing in decodifica e ha decoder più piccoli.
Il resto son cagate, quello che dovrebbe fare Intel è buttare le modalità vecchie dell'architettura (virtual x86, real mode, le istruzioni privilegiate per cambiare task, etc), in modo da semplificare la decodifica.
L'os gira a 64bit, le uwp pure, le Win 32 a 32bit
"Esiste software applicativo PC compiato ARM 64? risposta: SI.
Sul sistema viene eseguito un OS a 64 bit? risposta: SI."
La risosta è NO ad entrambe, non esiste software PC compilato per ARM ed il sistema operativo è il normalissimo Windows 10 a 32 bit.
Può eseguire software compilato per l'instruction set specifico del suo processore, basta che il proocessore stesso venga avviato in modalità 64 bit.
Una CPU avviata in modalità 64 bit può eseguire sia software 64 bit che software 32 bit, che in questo caso è quello del sistema operativo stesso
Non può eseguire software PE 64 in versione x86_64, ma solo ed esclusivamente per limitazioni legali legate ai brevetti Intel.
Micorosoft già domani mattina potrebbe distribuire la versione completa a 64 bit, solo che Intel le farebbe immediatamente causa.