Reprise du message précédent :
il y en a qui doivent commencer à flipper chez Intel avec cette annonce

Faut bien le vendre d'un point de vue marketing aussi.
 
Puis avec un octocore ARM HDG (i.e. avec des cœurs performants), c'est sur qu'on devrais avec des perfs correct vs. du x86 2C/4T qu'on a dans ce même budget de TDP. Même si d'ici la dispo des 835 Intel risque d'avoir aussi des choses en 10nm à proposer.

qui dit que c'est sans le 64 bits ?
l'actuel 64 bits c'est du x86-64, "x64" c'est un raccourci d'écriture, c'est l'architecture lancée par AMD au départ, par opposition au IA-64 d'Intel qui n'a pas pris
x86 n'implique pas spécialement 32 bits : ça peut être du 16 aussi
et win32 c'est l'API Windows NT, utilisée aussi par les apps 64 bits

 
Le 835 existe sur un smart actuellement ou est ce encore dans les cartons ?

Il me semble avoir lu qu'il serait lancé début 2017

edit : dans l'article windowscentral

Prévu sur les S8, OnePlus 4 entre autres.
 
Sauf que comme c'est du 10nm TSMC, on est pas sur que ce soit forcement dispo en masse en temps et en heure. Mais bon c'est en bonne voie.

c'est pas du 10nm TSMC mais du 10 nm Samsung justement
http://www.frandroid.com/marques/q [...] e-en-10-nm

Sachant que le commentaire qui va avec la vidéo a l'air faux, dans la vidéo le mec va voir les propriétés systèmes et on voit qu'il tourne avec un Snapdragon 820. C'est encore plus prometteur  

AMHA la cible c'est le 835 pour x ou y raisons, mais pour l'instant sans 835 dispo, ils dev. sur autre chose (vu le boulot je pense que ça fait plusieurs mois/années qu'ils sont dessus).

Ils travaillent déjà sur le Snapdragon 835 en interne (ils ont plusieurs dev-kit qui tournent)

Oui clairement. Ce que je veux dire, c'est que le truc a l'air fluide, et réussit à faire tourner Photoshop... sur un 820. Donc avec un 835 qui sera apparemment le SoC utilisé pour les premiers produits W10 ARM grand public, ça risque de dépoter    
 
Sachant que pour l'instant ça reste du SoC mobile conçu pour le mobile, et un peu pour les tablettes. Avec la dissipation de chaleur qui est bien plus simple sur des formats plus grands (grandes tablettes, pc portables), Qualcomm pourrait sortir des SoC plus costauds j'imagine (augmenter la taille du GPU notamment).
 
Reste à voir le planning, mais j'imagine que ce sera un peu short pour la Creator's update. Du coup on aurait :
- Au printemps, la Creator's update avec probablement une Surface Pro 5 en Kaby Lake. Et peut-être le Surface Book 2.
- En fin d'année, une grosse mise à jour avec l'arrivée de W10 complet sur ARM, accompagnée d'une Surface 5 (non pro) en ARM ? Avec peut-être un Surface Phone, mais seulement si la partir W10 ARM marche au poil et que MS se sent confiant pour avoir un Surface Phone qui répond aux attentes ?

C'est... hallucinant
 
Photoshop CC n'est pas aussi fluide/rapide dans un W7 virtualisé sur mon MacBook Air  

 
Après, c'est pas non plus la même techno, c'est pour ça que j'y crois.
 
Actuellement, sur ton Macbook air tu fais réellement de la virtualisation. De la virtualisation "toute bete" je dirais. Tu demandes à ton système d'émuler un autre systeme. De virtualiser un processeur, de la ram etc. Un ordi complet.
 
 
De ce que je comprends de ce qui est présenté, ce n'est pas vraiment de la virtualisation. On est plus proche d'un Wine que d'un Virtualbox.
Le but n'est pas de virtualiser un processeur ni rien. Ils partent du principe de faire tourner des .exe windows. Les exe ne font pas appels aux registre mémoires directement, ne font pas appel aux pattes du processeurs, les exe ne font appel qu'aux interfaces windows qui gerent ça. Il "suffit(*)" de faire en sorte que windows ARM réponde aux exe de la même manière que le ferait Windows x86.
 
 
(*) Oui pour le coup c'est bien ça le plus compliqué dans l'histoire, on est bien d'accord
 
 
Alors oui, c'est énormément de boulot de faire ça. Par contre oui, s'il font ça, les performances montrées ne me paraissent pas déconnantes.

Pour des softs compilés en vrai code natif (i.e. pas des programmes .NET) les exe ne font justement pas qu'appel à des interfaces Windows, il y a du code directement lié à l'architecture du CPU.
Bon après c'est peut-être pas super dur à émuler du fait que justement il n'y a que ça à émuler, et que tout le reste de l'OS tourne en natif (interfaces Windows inchangées). Du coup c'est plutôt l'inverse de Wine, mais l'un comme l'autre n'ont qu'une partie à émuler, et pas tout le système comme VirtualBox.
La partie la plus lourde dans VirtualBox et compagnie c'est peut-être justement faire tourner l'OS ; ensuite les softs en eux-même tournent assez bien. Un truc qui a tendance à être lent c'est par exemple tout ce qui est lié à l'affichage ou aux opérations dans un disque virtuel, encore un problème qu'on n'a pas ici (géré en direct par les drivers de l'OS)

C'est donc très orienté pro, effectivement. Ou ça peu bouffer dans l'assiette de la gamme surface pro grand public. Ça sent la cannibalisation, ces extensions de gamme.

A mon avis c'est de l'émulation "à la picokernel" comme ils font avec WSL

Aurais tu des liens vers un peu plus d'explication? Ca m'intéresse.
 
Merci

Euh... toutes les interfaces sont en effet connectées sur les API mises à disposition par Microsoft, mais il reste toute l'algorithmie embarquée dans l'appli (le "core" ), qui elle est compilée dans un vrai code natif x86 (et optimisé x86).
Et qui est même compilée en embarquant toutes les spécificités de l'architecture cible pour laquelle elle est compilée. Une appli compilée en Win32 x86_64 SSE4, tu peux toujours te brosser pour la faire tourner sur une CPU x86_32 sans SSE4 en ne touchant qu'aux libs Windows...

Là, tu me décris le fonctionnement d'une app UWP sur ARM : une appli en bytecode, indépendante de toute architecture, qui est executée sur une architecture spécifique à l'aide d'un socle qui se charge de l’interfaçage.
(même fonctionnement pour une appli Java finalement)

Non, le WSL, c'est faire fonctionner un OS A x86 dans un OS B x86... les deux OS étant sur la même architecture x86.
Là, c'est faire fonctionner un OS A x86 dans un OS A ARM : l'architecture est différente entre le système hôte et le système fils.

Et c'est ça toute la difficulté

https://blogs.msdn.microsoft.com/ws [...] -overview/

Merci

 
Alors en checkant dans les méandres de l'internet, voilà ce que j'ai trouvé :
- du temps de Windows NT 3.5 (et 4.0 je crois), DEC avait developpé FX!32 pour ses DEC Alpha => le principe était de faire tourner un binaire Intel x86 sur du DEC Alpha.
- c'était un hybride émulation et transcodage du code
=> pendant la phase 100% émulé on avait des perfs entre 40 et 50% entre le code émulé et le code natif DEC Alpha.
=> après la première execution et un code partiellement transcodé, on avait des perfs jusqu'à 70% de celle d'un code natif DEC Alpha.
 
Sauf qu'un DEC Alpha était plus perfs qu'un Intel de l'époque, du coup on avait des perfs qui tenaient la route.
 
La l'ARM est moins perfs que l'Intel en IPC. Du coup au mieux on pourra rivaliser en perf/W (et pas 100% sur), mais en perf brute j'y crois moyen. Parce que même un SoC comme un Apple A10 aurai au mieux l'IPC de 70% un Haswell. Et admettons que les coeurs d'un 835 soit 80% de l'IPC de l'Apple (ça serait déjà miraculeux avec un design 8 cœurs), on aurai donc 1 coeurs 835 = l'IPC de 56% d'un Haswell, donc ~50% celui d'un Kaby Lake (gloups ).
 
Alors ca reste gérable sur une charge multithreadé (p'tet même que ça donnerai des résultat supérieur à un Kaby Lake 2C/4T d'entré de gamme).
 
Mais bon faudrai quand même du binaire natif pour avoir des perfs correcte je pense.

 
Et je ne dis pas le contraire.
 
On dit juste que les perfs montrées dans la video sont très bonnes et bien meilleures que ce qu'on aurait avec de la virtualisation. ça ne va pas à l'encontre de 50% d'un haswell.
 
Si je compare les temps de chargement de CC dans la video, c'est comparable à ce que j'obtiens sur ma Yoga book en atom. Bref, c'est cohérent quoi.
 
Ce n'est pas parcequ'on dit "wouah, les performances sont incroyables et bien meilleures que de la virtualisation" qu'on sous-entend que ça tabasse un i7

A mon avis, dans un premier temps au moins les SoC Qualcomm concurrenceraient les Atom et non les Kaby Lake, parce que niveau prix il me semble qu'ils sont plus proches des premiers.

Et sur toute une partie (OS,  notifications, connectivité...) tu n'as pas de problématique d'émulation et donc pas de perte de performance. Et l'ARM a d'autres avantages...

LinkedIn est officiellement chez Microsoft maintenant
http://www.monwindows.com/blog/maj [...] 10913.html

Signature d'un nouveau partenariat entre ms et here
http://360.here.com/2016/12/15/mic [...] -services/
Aucune idée par contre en quoi il diffère de l'ancien

Je pense que c'est juste un renouvellement .

À priori, pas que. Ça semble aussi étendre le deal à tous les services ms et ça leur permettra d'utiliser d'autres services de herse
https://www.neowin.net/news/microso [...] r-services
 
Au passage, ms passe des accords avec plusieurs services de carto pour créer un nouveau "graph"
https://www.neowin.net/news/microso [...] g-partners

Un bon article expliquant comment ms a porté sql server sur linux
http://arstechnica.com/information [...] -to-linux/

On sait pourquoi ms a acheté un rein LinkedIn ? Pour sa base de donnée abonnés ? Pour en faire le fondement de son propre réseau sociel ? Juste pour le nom ou pour faire chier Google   ?

MS a passé un accord avec TomTom aussi

Mystérieux, ces accords. A moins de vouloir intégrer dans Windows ces services nativement ? Et même là, il y avait d'autres moyens.

C'est justement un peu expliqué dans mon second lien

Vu la merde des softs TomTom, à la rigueur vaux ptet mieux pour eux de vendre leurs cartes a des gens qui savent faire...

LinkedIn a le vent en poupe, Microsoft essaie de chopper le truc au passage.
 
Comme Skype à l'époque

en espérant qu'il n arrive pas la meme que skype et nokia, les acquisitions c est pas trop leurs trucs

Il est arrivé quoi à Skype?

des bugs, un interface horrible du coup malgré moulte efforts une perte constante d'utilisateurs, dommage pour un logiciel précurseur. Linkedin se sera probablement pareil les 24mds ne seront jamais récupéré, les synergies ne sont pas tres claires.

 
FoxPro (1)
Forethought (2)
Visio
Hotmail
FolderShare (3)
Dynamics
Rare
nTrig (4)
..
 
Il y a des rachats dont tu entends même pas parler, dans le seul et unique but d'améliorer un de leur produits, genre FastSearch&Research, dans l'unique but de l'integrer à Sharepoint, sans parler de tous les ERP locales pour integrer à Dynamics etc..
 
Ils font 15 rachats par an, normal qu'ils se plantent sur un certain pourcentage.
 

 
ça a toujours été le cas, ça fait juste plaisir aux gens de pouvoir désormais mettre ça sur le dos de MS. C'était beaucoup moins bienvenu de critiquer ces problèmes quand c'était LE concurrent de Msn.
 
 
 

 
Tout le monde semble l'oublier, mais Google n'a pas su faire mieux de Motorola.  
Ils ont même fait pire, puisqu'ils l'ont acheté 12Milliards, pour le revendre 2Milliard un an plus tard, en n'ayant absolument rien fait avec.
La perte sèche est bien plus élevée que MS-Nokia (7Milliards à l'achat, et même s'ils n'ont pas réussi, ils ont essayé d’en faire quelque chose et ont vendu du smartphone).
 
Je comprends pas pourquoi le bashing là-dessus et rien sur google.  
Ah si, MS c'est le méchant, et google le gentil. Pardon, j'oubliais.
 
 

Une autre précision. Pour des sociétés de cette taille, toutes les acquisitions ne sont pas faites pour générer du cash. Pour savoir si cela a fonctionner, encore faudrait il connaître l'objectif recherché.