Link alla notizia: https://www.hwupgrade.it/news/portatili/grazie-a-snapdragon-notebook-windows-con-l-autonomia-di-uno-smartphone_72797.html

HP e ASUS annunciano i propri primi PC portatili basati su SoC della famiglia Snapdragon, capaci di una autonomia di funzionamento ben più elevata di quello a cui siamo stati abituati sino ad ora

Click sul link per visualizzare la notizia.

facciamo anche un confronto sulle prestazioni offerte?
no, perche' la batteria della mia calcolatrice dura MESI...

facciamo anche un confronto sulle prestazioni offerte?
no, perche' la batteria della mia calcolatrice dura MESI...

esatto... anche perchè il mio lenovo 2in1 z8350 dura già più di uno smartphone e costa meno di uno snap 835 :sofico:

Piuttosto ci gireranno le distro linux?
Faranno un porcaio come i tablet atom o ci sara' modo di fare decentemente il boot?

Su Geekbenck che è multi piattaforma, lo snap 835 fa circa 2000 sul singlecore e 7000 punti sul multicore @2GHz, non sarà un test completo ma dice molto sulla potenza, e aggiungerei: mica male XD

Piuttosto ci gireranno le distro linux?
Faranno un porcaio come i tablet atom o ci sara' modo di fare decentemente il boot?

Io vorrei farci girare VAX o OS/2 invece.

Si ma esattamente come gira win10 su un ARM?
Hanno riscritto win 10 specificatamente per ARM?

E se così è come funzionano i tradizionali softwasre per win? (non le app)
Vengono emulati?

no...

mmm.. ok.
Quindi come fa a girare su ARM? E' in emulazione anche il SO? :mbe:

Macchè, il sistema operativo (e roba tipo office immagino) sono ricompilati per ARM, mi pare ci sia anche una ISO di win 10 1709 per ARM da qualche parte.

Rilasciano anche i cumulativi per ARM64
https://www.catalog.update.microsoft.com/Search.aspx?q=kb4051963

ma se wind 10 sta su snapdragon, perche non posso metterlo su uno smarphone, con la tipe C puoi attaccare un monitor esterno, hai tutte le connettività per tastiera e mouse, praticamente diventa un pc tascabile!

Allora signori, prima che si scateni il pandemonio, lasciate parlare che ho seguito la conferenza e sono un tantinello più informato:

- La piattaforma è Snap 835 e non la 845 presentata ieri, perché altrimenti questi device li avremmo visti a Natale dell'anno prossimo;

- La piattaforma è Win 10 S, in grado di avviare tutti gli applicativi disponibili nel MS Store (WinRT, UWP, app Desktop)... per poter installare programmi desktop al di fuori del MS Store, occorre fare l'upgrade (gratuito fino a settembre 2018) a Win 10 Pro;

- Mierson ieri ha detto esplicitamente che tali dispositivi godranno di una versione di Office 365 particolarmente ottimizzata.

- Quado viene eseguito per la prima volta un programma desktop tradizionale, il compilatore Jitter ricompila l'eseguibile, convertendo le chiamate al processore x86 in chiamate verso ARM: in tutte le esecuzioni successive, dunque, tali programmi avranno prestazioni native!

- A inizio anno, durante un'altra conferenza MS, fu mostrata una macchina ARM con Snap 820 che eseguiva abbastanza bene Photoshop completo, compiendo un ritocco al volo in diretta: dopo un anno e con un processore più potente, possiamo ritenere che le prestazioni possano essere accettabili pure per compiti non proprio basici.

- Questa autonomia enorme serve soprattutto a consentire di attivare il Connected Stand-by senza drenare troppo la batteria, come mi è capitato di vedere sui miei Surface e, in generale, su tutti i dispositivi con processori x86: in questa maniera potremo avere device che, anche a schermo spento, siano pronti a ricevere notifiche e a notificarcele in tempo reale, senza veder calare la batteria a vista d'occhio.

-Il NovaGo dovrebbe già uscire a breve, anche perché sono già disponibili i prezzi (599$: 4 / 64 | 799$: 8 / 256), mentre l'HP sarà disponibile in primavera.

- Lenovo terrà la sua personale conferenza al CES a riguardo.



Se mi dovesse venire in mente qualcos'altro, lo farò sapere.
Su YouTube ci sono già varie recensioni.

;)

ma se wind 10 sta su snapdragon, perche non posso metterlo su uno smarphone, con la tipe C puoi attaccare un monitor esterno, hai tutte le connettività per tastiera e mouse, praticamente diventa un pc tascabile!

Ecco... quello è il primo passo per creare il Surface Phone/Courier.

L'anno prossimo sì che ci divertiamo... è appena uscita la notizia dell'ANSA che Apple abbia pure lei brevettato un dispositivo pieghevole.

;)

Altra cosa:

- E' appena sbarcata la suite di Affinity sul MS Store e verso la primavera arriverà iTunes e la suite Adobe al gran completo (per ora c'è già Adobe Photoshop Elements 2018 nuovo nuovo).
SOmmando ciò ai tanti applicativi desktop che vengono continuamente aggiunti al MS Store e che stanno ricevendo una vera e propria 'rinascita' per l'occasione... diminuiscono sempre di più i motivi per fare l'upgrade a WIn 10 Pro.

;)

Prezzi fuori di testa, 800€ per una macchina 8/256 non sta ne in cielo ne in terra, compri un portatile vero che dura 10 anni ed esegue software a 64bit.

Su Geekbenck che è multi piattaforma, lo snap 835 fa circa 2000 sul singlecore e 7000 punti sul multicore @2GHz, non sarà un test completo ma dice molto sulla potenza, e aggiungerei: mica male XD

cavoli :eek: ho fatto una prova dei miei

i5-4210U 3200-5600
z8350 950-2500

se riescono a pompare un po la frequenza single core grazie alla maggior area dissipante del notebook potrebbe essere una bella batosta per i sistemi x86

cavoli :eek: ho fatto una prova dei miei

i5-4210U 3200-5600
z8350 950-2500

se riescono a pompare un po la frequenza single core grazie alla maggior area dissipante del notebook potrebbe essere una bella batosta per i sistemi x86

Si beh calma. Geekbench è tutto fuorchè un test affidabile.
Io di default manco lo prendo in considerazione, specie se poi si va a fare paragoni in multipiattaforma.

Da considerare poi la questione emulazione vs sistema nativo e software nativi x86.

Non voglio mettere le mani avanti ad ogni costo ma consentimi del fondato scetticismo.
Aspetto di vedere una prova dei fatti piu concreta.

una parte e' emulata, una parte e' riscritta. quanto grande e dove sia posizionato il livello emulato e' soggetto a varie interpretazioni. ufficialmente, le DLL sono sicuramente riscritte (tutte? boh). per il resto *non si sa*
Probabilmente tutto il codice di Windows/Microsoft (incluse applicazioni e DLL) sarà nativo ARMv8, mentre le applicazioni x86 (dunque di terze parti) saranno emulate ma quando useranno DLL di sistema verrà effettuato un tunnelling x86/x64 <-> ARMv8, in modo da eseguire codice nativo ARMv8 il più possibile, riducendo l'impatto dell'emulazione. Il tutto similmente a quanto avviene con la XBoxOne e l'emulazione dei giochi della XBox360.
- Quado viene eseguito per la prima volta un programma desktop tradizionale, il compilatore Jitter ricompila l'eseguibile, convertendo le chiamate al processore x86 in chiamate verso ARM: in tutte le esecuzioni successive, dunque, tali programmi avranno prestazioni native!
No, proprio per come l'hai descritto è chiaro che non è possibile avere prestazioni "native".

E' il classico compilatore JIT che converte frammenti di codice, ma stavolta da x86/x64 a ARMv8; avrà quindi una cache (blocchi che ospitano i frammenti convertiti; probabilmente c'è un buffer di dimensione fissa preallocato, come capita in questi casi) e politiche di flushing & riutilizzo dei blocchi.

Per cui ci sarà SEMPRE l'overhead dovuto alla compilazione di frammenti di codice x86/x64, che capita ogni tanto, e che ha un certo impatto prestazionale (già il solo disassemblare codice x86/x64 non è certo una passeggiata).

Ma anche se fosse possibile una compilazione AoT (Ahead-of-Time: tutto il codice x86/x64 ricompilato alla prima esecuzione, come capita con le applicazioni .NET), in ogni caso ci sarebbe sempre l'overhead dovuto all'emulazione del funzionamento di x86/x64, che è un'architettura molto diversa da ARMv8.
Per essere chiari, se compiliamo un sorgente compilato per x86/x64, e poi prendiamo il binario corrispondente e lo ricompiliamo AoT per ARMv8, non sarà mai a poi mai uguale o ugualmente efficiente rispetto allo stesso sorgente compilato direttamente per ARMv8; nella maniera più assoluta.
- A inizio anno, durante un'altra conferenza MS, fu mostrata una macchina ARM con Snap 820 che eseguiva abbastanza bene Photoshop completo, compiendo un ritocco al volo in diretta: dopo un anno e con un processore più potente, possiamo ritenere che le prestazioni possano essere accettabili pure per compiti non proprio basici.
Aspettiamo test più accurati fatti dalle redazioni di riviste o siti come questi.
Si beh calma. Geekbench è tutto fuorchè un test affidabile.
Io di default manco lo prendo in considerazione, specie se poi si va a fare paragoni in multipiattaforma.

Da considerare poi la questione emulazione vs sistema nativo e software nativi x86.

Non voglio mettere le mani avanti ad ogni costo ma consentimi del fondato scetticismo.
Aspetto di vedere una prova dei fatti piu concreta.
Concordo. Proprio Geekbench è un benchmark sintetico che non dice nulla.

Poi bisognerà anche vedere come se la caverà quest'emulatore con codice SIMD x86/x64 di nuova generazione, come AVX/-2: già AMD, che ha un processore nativo x86/x64, non riesce a star dietro ai processori Intel quando vengono eseguite applicazioni che fanno un consistente uso di queste nuove estensioni SIMD (Intel ha prestazioni fino a TRE volte superiori).

E' arrivato il momento di farci girare qualche applicativo / bench cpu bound serio, al posto di quella ciofeka falsa di GeekBench.

Si ma esattamente come gira win10 su un ARM?
Hanno riscritto win 10 specificatamente per ARM?

mai sentito parlare di windows10 su smartphone?
e gli smartphone sono x86?
quindi la risposta è banale ;)

mai sentito parlare di windows10 su smartphone?
e gli smartphone sono x86?
quindi la risposta è banale ;)Non è Windows 10 Mobile.
E' l'apposita versione per ARM che hanno sperimentato pochi mesi fa proprio con l'835, con l'esecuzione degli applicativi x86 tramite emulazione.



Tratto dall'articolo :
Cuore della proposta Qualcomm è il SoC Snapdragon 835, per il quale Microsoft ha sviluppato una specifica versione di sistema operativo Windows 10 che sia compatibile.

...- Quado viene eseguito per la prima volta un programma desktop tradizionale, il compilatore Jitter ricompila l'eseguibile, convertendo le chiamate al processore x86 in chiamate verso ARM:
scusa l'ignoranza assoluta, ma se un exe x86 viene ricompilato x arm vuol dire che quando lo installi da qualche parte c'è pure sorgente?:confused:

scusa l'ignoranza assoluta, ma se un exe x86 viene ricompilato x arm vuol dire che quando lo installi da qualche parte c'è pure sorgente?:confused:

Non e' necessario il sorgente.
In questi casi il codice binario x86 invece di essere decodificato dalla cpu viene letto da un compilatore come se fosse un sorgente (codificato in binario invece che come testo) e le istruzioni x86 "decodificate in software" vengono convertite in un formato intermedio simbolico che poi viene poi compilato in codice binario per ARM.

E' in poche parole come quando si fa la compilazione JiT oppure AoT del bytecode CIL di .Net o del bytecode JVM di Java, solo che invece di usare un bytecode "ottimizzato per essere ricompilato" si usa il formato delle istruzioni x86 (che non e' stato ottimizzato per questo e quindi è più complesso da gestire, specialmente perche invece di una VM "pulita" ha come modello di esecuzione quello delle cpu x86 con tutte le loro peculiarità).

ma se wind 10 sta su snapdragon, perche non posso metterlo su uno smarphone, con la tipe C puoi attaccare un monitor esterno, hai tutte le connettività per tastiera e mouse, praticamente diventa un pc tascabile!

calcola che in macchine del genere possono farli andare a freq più alte che negli spazi risicati dei cellulari non si può.

calcola che in macchine del genere possono farli andare a freq più alte che negli spazi risicati dei cellulari non si può.

Se non spremi la gpu, la frequenza cala di ben poco, l'835 è un soc veramente poco energivoro.

Non e' necessario il sorgente.
In questi casi il codice binario x86 invece di essere decodificato dalla cpu viene letto da un compilatore come se fosse un sorgente (codificato in binario invece che come testo) e le istruzioni x86 "decodificate in software" vengono convertite in un formato intermedio simbolico che poi viene poi compilato in codice binario per ARM.

E' in poche parole come quando si fa la compilazione JiT oppure AoT del bytecode CIL di .Net o del bytecode JVM di Java, solo che invece di usare un bytecode "ottimizzato per essere ricompilato" si usa il formato delle istruzioni x86 (che non e' stato ottimizzato per questo e quindi è più complesso da gestire, specialmente perche invece di una VM "pulita" ha come modello di esecuzione quello delle cpu x86 con tutte le loro peculiarità).
Diciamo che è molto più simile alla JVM di Java, che compila frammenti di bytecode quando gli servono, e quindi senza compilazione AoT (come invece capita con .NET).

Una compilazione AoT di un eseguibile x86/x64 (ma vale per qualunque qualunque architettura) in genere non è possibile, perché normalmente un binario non si porta mai dietro sufficienti informazioni per identificare tutti i pezzi di codice / funzioni / metodi al suo interno.

Per ottenere tutte queste informazioni non basta partire dal punto di avvio (entry point in gergo) e tracciare via via tutte le routine eseguite: funziona bene soltanto per codici molto semplici, che contengono esclusivamente istruzioni di salto a funzioni/metodi statici (le istruzioni referenziano direttamente la locazione di memoria da eseguire).
Ma il codice di un'applicazione "di spessore" usualmente impiega puntatori a funzioni/metodi e tabelle di puntatori a funzioni/metodi, che potrebbero anche cambiare valore durante l'esecuzione; in questi casi non si può far altro che tracciare l'esecuzione finché non si arriva all'istruzione di salto che fa uso del puntatore a funzione, leggere finalmente l'indirizzo a cui saltare, e se non è stato ancora compilato provvedere ad analizzare il frammento e convertirlo finalmente in un frammento dell'architettura nativa.

Dunque, e per concludere, una compilazione AoT di un binario "non banale" si potrebbe fare se e solo, durante tutte le volte che è stato eseguito, alla fine si è riusciti a mappare tutti i suoi frammenti di codice. In questo caso, avendo ormai la mappa di tutto, sarebbe possibile tirare fuori direttamente un eseguibile per l'architettura nativa, buttando via il binario originale.

C'è una sola eccezione a tutto questo discorso, ed è rappresentata dalle applicazioni che generano codice dinamicamente. Ad esempio WinUAE, un emulatore Amiga, che compila dinamicamente codice Motorola 68K in frammenti x86 o x64 (a seconda del binario utilizzato). In questo caso l'applicazione x86/x64 genera ed esegue al volo frammenti di codice x86 o x64, a seconda di quando gli servono. Questo significa che una compilazione AoT di WinUAE x86/x64 per ARMv8 non sarà mai possibile (per essere precisi, sarebbe possibile convertire l'intero binario x86/x64, ma il JIT x86/x64 -> ARMv8 dovrà essere sempre attivo per intercettare i casi in cui venga richiamato codice x86/x64 generato dinamicamente).