Version imprimable du sujet

Écrit par : Lionel 18 Oct 2017, 10:50

Microsoft et Qualcomm ont dévoilé leurs plans pour sortir l'an prochain un ordinateur portable doté d'une puce ARM.
Ces machine fonctionneront autour d'un processeur Snapdragon 835 que l'on retrouve déjà dans des smartphones comme le Galaxy S8 de Samsung.
Ces machines utiliseront un Windows spécifique, mais seront capable de faire tourner des applications X86 quand même grâce à une couche d'émulation.
Ces machines profiteront de leur format plus large que celui d'un smartphone pour assurer une autonomie de plusieurs jours.

Apple travaille très certainement aussi sur une piste similaire qui diminuerait sa dépendance face à Intel et lui donnerait plus de liberté pour créer ses machines uniques.
Le fait de commencer à développer ses propres solutions graphiques mobiles milite dans ce sens car Apple maîtrisera alors peu ou prou toute l'électronique de ses produits et pourra proposer ses pendants aux Core X d'Intel.

http://macbidouille.com/news/2017/10/18/microsoft-et-qualcomm-sortiront-des-ordinateurs-portables-arm-dici-la-fin-de-lannee

Écrit par : Hebus 18 Oct 2017, 11:27

Un 835 ? ça ne risque pas de faire léger ?

Écrit par : raoulito 18 Oct 2017, 11:36

je ne suis pas certain que le premier à sortir ce que tout le monde pressent soit le futur gagnant. On ne parle pas d'un nouveau concept (type ipad ou chrome book), ni d'une nouveauté premium (le processeur ne se voit pas.. le prix sans doute..)
Confiance en apple: lorsqu'ils sortiront cela ce sera bien fichu et très bien pensé (ils ont connu des ratés, peu sur les tout nouveau nouveau produits)

Écrit par : Lionel 18 Oct 2017, 11:52

DISONS QUE TU N'ES PAS SUPER OBJECTIF NON PLUS

Écrit par : vlady 18 Oct 2017, 11:54

J'ai une petite machine Raspberry Pi 2 ! sous linux qui joue le rôle d'une sorte de sandbox et d'une station de téléchargement. C'est pas la joie mais c'est utilisable. Un petit portable (ou, encore mieux, un petit box de taille Apple Tv 4K) avec Snapdragon 835 me fais saliver d'avance. Surtout si on arrive à y caser un linux. Surtout si le prix est attractif.

Écrit par : raoulito 18 Oct 2017, 11:54

je suis optimiste ?

Écrit par : Claude-1300 18 Oct 2017, 12:03

Il leur arrive quoi, chez Qualcomm ?
Ils prennent le mors aux dents ?

Déjà on a droit à leurs pubs identifiant bien que "ce que vos smartphone font, c'est Qualcomm qui l'a fait"...

Nouveau boss ?

Écrit par : DonaldKwak 18 Oct 2017, 12:33

Intel va enfin avoir la paix. Les siphonnés de la théorie du complot vont enfin pouvoir comparer deux plateformes et non une plateforme existante et une autre fantasmée

Ce sera surement un très bonne solution pour ceux qui veulent faire du web, email, skype et quelques applications portées sur ARM qui feront que cet ordinateur sera plus versatile qu'une tablette. Par example, il semble qu'Office 365 soit disponible en natif sur cette machine.

Pour l'émulation x86, je ne vois pas bien l'intérêt, à part pour de tous petits utilitaires. Si les grosses applis n'existent pas sur ARM, j'ai du mal à croire qu'on ait envie de l'émuler. Faire tourner Photoshop en émulé, je ne le sens pas. Bien sur que ça marche vaguement si on ouvre une image sans calques et sans objets dynamiques (et dans ce cas, il y a surement mieux que Photoshop). Mais avec de gros fichiers, j'ai du mal à croire que cela ne s'écroule pas.

Écrit par : dtb06 18 Oct 2017, 12:34

Et moi j'ai le RaspberryPi 3, je lui ai mis l'écran tactile officiel 7'', et franchement je trouve aussi que ça tourne très bien. On peut lancer du LibreOffice, du Gimp, ou lire des vidéos 1080p.
Je suis surtout impressionné par le navigateur web : sous Chromium, même les sites un peu lourds n'ont pas de ralentissement à l'affichage quand on scrolle.
Après le système est super optimisé, arrivé sur le bureau Linux avec le Wifi et le Bluetooth intégré, on est à environ 135Mo de RAM consommés.


Et pour revenir à Windows, la vidéo est là :
https://youtu.be/A_GlGglbu1U

Écrit par : DonaldKwak 18 Oct 2017, 13:11

Dans le monde du HPC certains se posent la question : https://www.hpcwire.com/2017/10/10/hpc-chips-veritable-smorgasbord/

Écrit par : zed_bill 18 Oct 2017, 13:30

Ca va être d'une réactivité ! J'ai hâte de voir ça.

Écrit par : iAPX 18 Oct 2017, 13:35

Pourquoi faudrait-il émuler photoshop pour l'utiliser?

On n'émule pas une CPU PowerPC pour utiliser Photoshop sur un Mac actuel, autant que je sache, pourquoi le faire sur un ordinateur ARM?

Et pourquoi donc faire tourner Photoshop sur des PC qui promettent d'être très largement en-dessous des 500$?
Un peu comme dire que la nouvelle voiture économique Tata à 3500$ n'ira pas aussi vite sur circuit qu'une Porsche ou une Ferrari, ça semble une maladie ici, alors que la plupart des gens utilisent principalement des navigateurs comm application le plus souvent, un client email et quelques rares applis simples (ou dont ils n'utilisent que peu de fonctions).

Et attendons surtout de comparer, à prix égal, ce qui sera donné d'un coté et de l'autre, avec un profil d'usage correspondant au placement prix du produit (au lieu de considérer que tous utilisent Photoshop, du tracé de rayon multithreadé, des DB ou autres VMs sur un PC à 300$!), je pense qu'on pourrait bien être surpris par Qualcomm et encore plus par Apple!

PS: il semble déjà que l'autonomie soit au moins le double des mêmes appareils avec CPU x86, avec des http://www.zdnet.com/article/microsoft-in-final-stages-of-windows-10-snapdragon-pc-development/!

Écrit par : Sethy 18 Oct 2017, 13:46

L'équation est simple, Intel est face à un mur et voit son avance fondre le temps que les autres atteignent également ce mur.

D'autre part, l'explosion de l'informatique domestique a considérablement déplacé la "médiane" des besoin des utilisateurs vers le bas. Depuis le Core 2 Duo, qui était déjà bien au dessus de ce besoin médian, toutes les évolutions des CPU sont totalement inutiles à la moitié au moins des utilisateurs (et même parfois d'autres. Si j'ai un Hack, j'ai aussi un petit MacBook Air dont la puissance est certainement largement au dessus de mes besoins d'utilisation de cette machine la).

Dès lors voir apparaitre des Windows ARM est vraiment dans l'air du temps d'une part. C'est aussi vital pour Microsoft qui en se retirant du marché des Smartphone a aussi perdu sa tête de pont vers les objets connectés.

Écrit par : os2 18 Oct 2017, 13:47

ce qui aujourd'hui est la majeur partie du marché... pas pour rien que le mobile prend du terrain sur celui du pc

Écrit par : SartMatt 18 Oct 2017, 13:52

Parce que pour l'instant Adobe n'a pas sorti de version ARM. Et il me semble même pas qu'ils aient communiqué sur un projet de sortir une version ARM...

C'est pas du tout ce qui se dit aux dernières nouvelles, les machines ARM se retrouveront en concurrence frontale avec les ultrabooks x86 au niveau tarifaire : http://www.frandroid.com/marques/qualcomm/466010_windows-10-sur-qualcomm-snapdragon-nouvelles-puces-autonomie-sur-plusieurs-jours-nouveaux-fabricants-le-recap

Par rapport à des machines x86 au même prix, leur gros atout sera leur autonomie, mais sans doute au prix de performances moindres en natif, et encore plus en émulation.

Écrit par : DonaldKwak 18 Oct 2017, 13:53

J'en parle pour deux raisons :
- Je ne pense pas qu'Adobe porte Photoshop sous ARM dans les prochaines années
- La vidéo de Microsoft que l'on peut voir sur youtube montre Windows 10 ARM lançant Photoshop. C'est avec cet example qu'ils mettent en valeur l'émulateur x86-ARM.

Mais je suis d'accord avec toi. Pour le genre de machine visée, c'est inutile. C'était une manière de dire que je ne vois pas bien l'utilité de cet émulateur. Si Office sort en version ARM, ce sera déjà un grand pas de fait.

Écrit par : dtb06 18 Oct 2017, 13:56

Regarde la vidéo que j'ai mise au-dessus

Écrit par : os2 18 Oct 2017, 14:05

il y avait déjà eu de nombreuse machine très intéressante présenté par Pegatron, Foxconn, toshiba, lenovo, sharp autour de 2009, 2010...

il faut que la machine offre un avantage considérable face au x86 autrement ce derniers gagnera...

suffit de voir le succès des chromebooks en france par rapport au usa...

au final l'utilisateur ne peut rouler photoshop... mais est-ce qu'il le fait actuellement...


la tendance est au tout web de toute façon

le pc est en train de devenir un niche

on trouve de plus en plus d'environnement de développement... et ce n'est qu'un début

sachant que les gens achètent des laptops et les utilisent bien souvent comme des fixes... pas certain que ça soit un gros avantage

pour avoir testé plusieurs logiciels sous linux sous arm vs x86, les performances sont souvent bien moins bonnes en arm...

il y a les tests... et les applications utilisés tous les jours.. après pour du web... pas vraiment de grosse différences

après j'ai pas trop l'impression que les prix seront meilleurs que les x86... s'ils ne joue que sur l'autonomie... gros boff

Écrit par : siméon 18 Oct 2017, 14:07

Les préjugés...
C'est déjà tout à fait correct avec un Snapdragon 820, le 835 est bien évidemment au-dessus, voilà ce que ça donne avec un S820 (vidéo datant de décembre 2016):
https://www.youtube.com/watch?v=A_GlGglbu1U

Avec Snapdragon 835 :
https://www.youtube.com/watch?v=VeOQp5V7EgM

Écrit par : os2 18 Oct 2017, 14:16

quand tes attentes sont pas très élevé... certe...

la vidéo montre clairement que c'est pas très réactif... et cela sur des opérations de bases...

après ça va faire comme bien des gens avec les tablettes... ils achètes et après ils vont déchanté assez rapidement

Écrit par : dtb06 18 Oct 2017, 14:16

Je suis d'accord aussi, ce genre de machines n'est pas fait pour faire tourner Photoshop.
Par contre, ils le montrent car PS est réputé pour être quand même une bonne usine à gaz, donc on se rend quand même compte en regardant la vidéo que l'application se lance sans trop de problème.

Vraiment, je crois en ce genre de trucs maintenant.

MS avait eu une idée bizarre : faire de Windows une plateforme unique. Mais pour cela ils se sont bien gourés avec la version ARM. On se retrouvait avec une version Windows 10 pour x86, une version Windows 10 pour smartphone et une version Windows 10 pour tablettes ARM.
L'idée de départ n'était pas mauvaise : on pousse les développeurs à faire du multi-plateforme (les applications universelles du Windows Store). Seulement les développeurs n'ont pas suivi, et les clients non plus, car l'appellation "Windows" devenait trop complexe et on ne savait pas ce qui pouvait tourner sur une machine donnée.

D'où l'abandon de Windows RT et de Windows Phone.

Ici, c'est plutôt le contraire. On a une nouvelle architecture, mais on garde toute la compatibilité avec les applications existantes. C'est ce qu'a fait Apple avec Rosetta, et c'est ça qui fait que le public adopte le changement. Et le fait qu'Apple passe en x86 les a aussi sauvés, la possibilité d'installer ou de virtualiser Windows étant grandement responsable du fait que les Macs soient encore là.

La compatibilité Win32, ça ne sert pas à faire tourner en permanence des applications Win32. Ca sert à pouvoir faire tourner de temps en temps une application Win32 sans équivalent parce qu'on en a besoin. C'est ponctuel, mais pratique.

Il y a eu des rumeurs comme quoi Apple voulait faire un Mac sous ARM. J'espère pour eux qu'ils prendront la même direction que MS en gardant la compatibilité des applications, parce que sinon un Mac verrouillé sur le Store ça risque d'être le début de la fin...




Et en ce qui concerne les performances, certes, il y a des secteurs qui auront besoin de puissance, à savoir les calculs intensifs, le graphisme et la vidéo, mais dans tous les autres secteurs, le palier est atteint depuis plus de 10 ans. Je le vois dans mon boulot, un ordi de 2007 avec de la RAM et éventuellement un SSD fait presque la totalité des tâches dont on a besoin. Ce n'était pas le cas dans le temps, si vous aviez un ordinateur de 1994 durant l'année 1998, il y avait peu de chance qu'il fasse tourner Windows 98.
La majorité des usages s'est aussi déplacée vers le web. Et quand je vois que mon Raspberry Pi 3 acheté 28 euros arrive à surfer sans trop de souci, je me dis que le temps des processeurs ultra puissants est révolu. Le seul usage qui les maintient est le jeu vidéo.

Écrit par : WipeOut 18 Oct 2017, 14:49

Une news de chez Trump ?

Je ne vous comprends pas, vous râlez que les machines de chez Apple manque de puissance et vous voyer dans cette info le saint Graal ?

Ce laptop va être pour quel public ? Ceux qui on marre de la tablette ?
L'émulation de code x86 c'est le truc qui me gêne le plus. On la bien vue sur OS X comment les éditeurs on traîne pour quitter Rossetta, finalement c'est Apple qui a du forcer la chose.

Écrit par : SartMatt 18 Oct 2017, 14:52

Je confirme, notamment pour la partie Photoshop : j'utilise un Photoshop en accès distant sur une machine avec un Core i5 2500k et plusieurs VM qui tournent dessus, c'est plus rapide que dans la vidéo de présentation de Microsoft pour calculer un flou radial, alors que j'ai pris une image beaucoup plus grande (plus de 8 fois plus de pixels)...

Écrit par : PierreH 18 Oct 2017, 14:55

Ou rêveur ?
Chez Apple, les Rev A. ont presque toutes été des machines à éviter. Par contre sur les Rev B. ils ont presque toujours corrigé le tir.

En tout cas, ça doit les faire triquer dur chez Apple de pouvoir faire ça : un Mac aussi fermé qu'un iPhone et fini les conneries genre Hackintosh ou cartes graphiques hors de ce que le cercle aura béni. Beurk.

Écrit par : Lionel 18 Oct 2017, 15:36

Il y a 10 ans cela n'aurait pas été possible. Mais maintenant, l'essentiel des machines sont vendues à des particuliers qui ne créent pas, mais consomment. Cela va de youtube à Amazon en passant par quelques mails.
Le besoin de puissance n'évolue plus même si on continue à le vendre et qu'il fait vendre.
Les gars achèteront cette machine parce qu'elle peut faire tourner Photoshop, pas parce qu'il tourne bien. Microsoft a compris la leçon avec Windows pour smartphones. Il faut une logithèque, tant pis si les logiciels tournent comme des tortues, dans le meilleur des cas 99% de ceux qui feront tourner Photoshop là dessus l'auront piraté et l'utiliseront par mettre la tête de leur belle-mère sur une photo porno.

Si MS arrive à amorcer la pompe, Adobe portera alors ses versions de logiciels ARM vers Windows version ARM. On aura moins de fonctions (tout du moins dans un premier temps) mais plus de vitesse.

Écrit par : DonaldKwak 18 Oct 2017, 15:53

La question est de savoir ce que va apporter un Windows 10 ARM face à iOS et Android. Car ces deux derniers vont tout faire pour empêcher un Windows 10 ARM de marcher sur leurs plates bandes. À mon avis, parmi les 3 plateformes suivantes, y en a de trop, et la première et la dernière ligne sont déjà bien installées.
- Windows/macOS sur x86
- Windows sur ARM
- Android et iOS sur ARM

J'ai du mal à voir Windows sur ARM percer. Et rien n'empêche Android (et même iOS) d'intégrer des choses qui viennent des OS Desktop comme un clavier et une souris par exemple. On verra bien...

Écrit par : pmr115 18 Oct 2017, 15:56

Bonjour,
Avant de passer à une autre plateforme, j'aimerai que l'on tire le maximum de l'actuel. J'ai le sentiment que les applications ne sont que peu optimisées, que les développements s'arrêtent lorsque ça tourne sans plus sans optimisation de la mémoire, ni les multi coeurs et avec des compilateurs dont le souci est avant de faire tourner le maximums d'applications sur toutes les machines du constructeur.
Ce que l'on préserve s'est l'heure développeur et la rapidité de la mise sur le marché.

Écrit par : DonaldKwak 18 Oct 2017, 16:00

Eh oui. Il faut donner du boulot aux personnes qui optimisent les logiciels, et leur donner des sous. Plein de sous.

Comme disait Alain Chabat, écrivez à l'arc et envoyez nous des sioux. Pleins. https://www.youtube.com/watch?v=tnyZI-C1Ykg

Écrit par : pmr115 18 Oct 2017, 16:25

Je croyais naïvement que cela était compris dans les largesses que l'on octroye à Apple en fermant les yeux au moment de passer à la caisse.

Écrit par : os2 18 Oct 2017, 16:25

pour des applications à 1$ tu t'attends à quoi?

Écrit par : __otto__ 18 Oct 2017, 16:33

Il y a de forte chance que ce sit ton GPU et non ton CPU qui s'occupe du calcul...

Écrit par : SartMatt 18 Oct 2017, 16:36

Android gère déjà un clavier et une souris en fait (nativement, même sur un Android stock).

Le problème, c'est les applications, pas pensées pour ça. Ça va peut être un peu changer avec la disponibilité des applications Android sur Chrome OS, mais tant que Chrome OS ne représentera que quelques dizaines de millions d'utilisateurs face aux centaines de millions d'Android, ça ne pèsera pas lourd...

Écrit par : DonaldKwak 18 Oct 2017, 16:38

Les personnes qui savent optimiser correctement les logiciels sont très rares. À mon avis, le problème vient a plusieurs origines :

- L'abstraction a été au coeur du cursus de l'enseignement informatique dans les années 1990, 2000. On a construit des usines à gaz pour résoudre des problèmes qui très souvent n'existaient pas. Cela a surement eu des effets bénéfiques, mais cela a été dévastateur sur l'optimisation de code. Les codes optimisés étant souvent écrits en C/C++, l'ennemi numéro 1 est à mon avis la STL. C'est une longue histoire...
- L'optimisation fait l'objet de beaucoup de légendes urbaines avec des astuces qui pour la plupart n'ont jamais accéléré de code, ou alors accéléré du code produit avec des compilateurs des années 1970. Par exemple les personnes qui utilisent des pointeurs au lieu des indices en pensant que cela va aller plus vite, les personnes qui écrivent les boucles à l'envers car ils pensent que le test d'arrêt k !=0 est plus rapide que k < n, et toutes les âneries de ce genre. La raison de toutes ces âneries : les gens ne sont pas formés à utiliser des profilers. Du coup, ils optimisent sans jamais mesurer. C'est catastrophique : cela rend les codes lents et impossible à maintenir. Le dernier point pousse souvent les équipes à s'éloigner des techniques d'optimisation car ils en ont assez soupé de Joe le programmeur qui pense faire du bien à un logiciel et saccageant un code avec ses astuces pourries.

Après il y aussi le fait que certains outils ne sont pas simples à utiliser. Par exemple, écrire du code qui sera vectorisé par les différents compilateurs n'est pas toujours simple. Si on veut utiliser des outils standards, certains compilateurs le font très bien, d'autres pas du tout.

Écrit par : SartMatt 18 Oct 2017, 16:40

Sur la machine physique, il n'y a que l'IGP Intel, qui est officiellement non compatible d'après Adobe : https://helpx.adobe.com/fr/photoshop/kb/photoshop-cc-gpu-card-faq.html

Et même s'il était compatible, en passant par une VM je doute que ça soit toujours le cas... C'est moi qui avait fait l'installation initiale de la VM, je n'avais rien fait pour le support OpenCL, et je doute que l'utilisateur principal ait fait quoi que ce soit dans le genre depuis, vu que ça n'a pas l'air trivial.

Écrit par : vlady 18 Oct 2017, 17:04

Elle très bien la STL (surtout dans C++ 17), il faut juste savoir s'en servir (ne pas foutre les shared pointers partout, ne pas mettre les types élaborés directement dans les containers, utiliser les "move semantics", par exemple)...

Écrit par : DonaldKwak 18 Oct 2017, 17:25

C'est un long débat. Je reproche de nombreuses choses à la STL. Mais mon reproche principal est le suivant:

Il y a selon deux structures de données à maitriser en programmation : le tableau et la table de hachage. Le premier est très mal représenté dans la STL qui n'a que std::vector (qui est plutôt bien) pour l'allocation sur le tas et std::array pour l'allocation sur la pile. Il manque : des tableaux multidimensionnels (ne me parlez pas de ces horreurs qu'il y a dans Boost en consort), des std::vector avec "small array optimization" et bien d'autres choses que je ne détaillerai pas. Concernant la table de hâchage, il a fallu attendre le C++11 pour avoir std::unordered_map (2011 pour une table de hâchage, oui monsieur). Et le pire : son implémentation n'est pas optimale. Et le standard impose une telle implémentation. Impossible de faire une table de hâchage en OpenAdressing qui est ce qui se fait de mieux aujourd'hui en performance.
Donc, les deux structures les plus utiles sont très mal représentées. Maintenant, des trucs inutiles et lent, il y en a à la pelle : std::list, std::dequeue, etc. Pitié !!!
Maintenant qu'on sait qu'il y a globalement 2 types de structures de données utiles (à part des structures qui sont très spécifiques et qui n'ont pas grand chose à faire dans une bibliothèque standard), dites moi à quoi sert la programmation générique. Quelle est la dernière fois que vous avez voulu échanger une table de hâchage et un tableau ? Je ne comprends toujours pas l'intérêt de ce truc qui a selon moi une utilité toute relative dans un langage de bas niveau. Il y a bien sur des intérêts quand on se place à un plus haut niveau, mais le problème des programmeurs C++ c'est qu'ils se touchent un peu trop avec ces notions d'abstractions même quand c'est complétement inutile. Toutes ces abstractions rendent le travail du compilateur extrêmement difficile. Et ils jettent l'éponge le plus souvent.

Mais je préfère laisser parler Chandler Carruth qui s'occupe de la partie optimisation de LLVM et qui parle de cela bien mieux que moi : https://www.youtube.com/watch?v=fHNmRkzxHWs

Si vous voulez des structures de données efficaces, je vous conseille de voir celles utilisées par LLVM dans leur propre code. Chandler Carruth, encore lui, a un très bon talk la dessus : https://www.youtube.com/watch?v=vElZc6zSIXM

Je maintiens une bibliothèque libre qui implémente toutes ces idées. Et je peux te dire que cela va bien plus vide que toutes les implémentations de la STL que je connais (VS, libstdc++, libc++). Ils ne peuvent pas faire le poids car les spécifications de la STL (la librairie standard plus précisément), les empêche de faire toutes ces optimisations.
Exemple: L'insertion de toutes les villes de France avec leur population prend 3.9s avec ma table de hâchage, 4.8s avec celle de Google (Google Dense Hash Map) et 30.7s avec std::unordered_map de libstdc++. Oui, je mets un x9 à la librairie standard sur ce benchmark ! Et pour chercher la population d'une ville donnée, je suis 4 fois plus rapide que std::unordered_map. Je n'ai pas fait de benchmark avec le std::map que beaucoup utilisent encore car je ne souhaite ridiculiser personne :-)

Écrit par : Skwaloo 18 Oct 2017, 17:38

Il y a 7 an, aucun ARM n'avaient des perfs des x86 les moins performants. Aujourd'hui, des ARM arrivent à être aussi rapide que des x86 dans des ordi portables, alors que ces puces sont bridées par les contraintes de conso et dissipation de chaleur. Il y a donc de bonnes possibilités des les faire progresser en arrivant à la même dissipation qu'une puce d'ordi portable.
Mais le + important, ce n'est même pas les perfs max, c'est que les ARM arrivent à des perfs mini confortables pour un grand nombre de personnes (ce n'est pas PS qui guide la majorité des ventes). Et vu qu'il y a plusieurs fabricants d'ARM qui se font le guerre des prix ça fera gagner + d'argent aux fabricants d'ordi.
Le succès de RaspeberryPI est indéniable malgré que ce n'est pas utilisé pour PS. Et il est une limace par rapport au S835.



+1 en ce qui concerne les pc performants.
Le Huawei Mate10 Pro a un début de solution intéressante pour l'utiliser comme pc.




T'as fait de gros progrèèèès ! C'est vachement moins débile tes critiques envers les ARM ! J'ai peur que dans peu de temps tu leurs trouves même des avantages
Tu as testé un ARM de smartphone contre un x86 d'ordi ?
De dissipation équivalente ?
Avec un logiciels codé pour être optimisé pour x86 et juste recompilé pour ARM ?
Un pote est parvenu à faire aller une rPI3 + rapide qu'une TX2 sous Firefox. Pour ça, il a mis Alpine sur la rPI, et tout compilé avec Musl. On voit là qu'il y a encore de la marge avec de l'optimisation logiciel sur ARM.
Un autre pote trouve son Odroid-C2 rapide (+ rapide que son MacMini, le premier en Intel !). Qu'un x86 soit encore + rapide ou pas ? Il s'en fout carrément parce que là ça lui a coûté très peu à l'achat, très peu en fonctionnement, ça ne fait pas de bruit et ça ne prend pas de place. Pour lui aussi, by by le x86.




L’intérêt est de ne pas avoir à changer ses habitudes. Suivant l'importance du marché, il y aura des versions optimisé ARM.

...d'ailleurs j'ai lu que Micro$oft n'évoque pas d'émulation, mais de transformation du code x86 en réécrivant l'appli *.exe en code ARM dès la 1ère fois qu'elle sera exécuté. Donc ce sera fait une fois pour toutes, et ce ne sera pas la lenteur permanente d'une émulation.




Tu penses que ceux qui encodent des films + rapidement sur leur iPad Pro que sur leur Macbook déchantent rapidement ?!

Écrit par : os2 18 Oct 2017, 17:48

la journée que l'industrie du cinéma utilisera des ipad pro pour encoder on s'en reparle? ok

Écrit par : os2 18 Oct 2017, 18:05

ça c'était avant...

optimiser coûte cher et prend du temps.

c'est moins coûteux d'améliorer le hardware, encore plus vrai avec la venu du cloud

au niveau du langage le marché fonctionne avec des vm qui en production sera déployé sur des machines virtuelles... l'optisation "comme dans le temps" c'est pas mal mort

Écrit par : DonaldKwak 18 Oct 2017, 18:11

Vaut mieux entendre ça que d'être sourd. Je ne pourrai pas te convaincre sur ce forum car le chemin est trop long. Mais tout cela me fait réaliser chaque jour à quel point les gens n'ont toujours pas compris : http://www.gotw.ca/publications/concurrency-ddj.htm. L'article a maintenant 10 ans, et force est de constater que nombreux sont ceux qui ont plus de 10 ans de retard sur ce point. Pour enfoncer le clou, je vais même dire qu'ils ont 20 ans de retard car Niklaus Wirth disait il y a plus de 20 ans "Software is getting slower more rapidly than hardware becomes faster."

Écrit par : vlady 18 Oct 2017, 18:32

Je demande voir ton implémentation. Il y a combien de villes en France ? Quelque dizaines de milliers ? Si le compte est bon, mettre ça dans une unordered_map et cramer 3.9 seconds pour ça c'est déjà énorme (et 30.7 sec c'est juste ridicule) ! Ils font quelle tailles tes structures de villes ?

Écrit par : DonaldKwak 18 Oct 2017, 18:41

Pardon, tu as raison, ce benchmark n'est pas le benchmark des villes.

Ce benchmark correspond a insérer 50 000 000 entiers 64 bits (les clés, générées de manière aléatoire) et leur associer la valeur 0. On a donc un std::unordered_map<std::size_t, std::size_t>. Ca nous donne 78 ns par insertion avec ma table de hachage et 614 ns par insertion avec std::unordered_map. Le problème de std::unordered_map, c'est qu'elle fait un malloc à chaque insertion. Celle que j'utilise n'en n'a pas besoin car cette table de hachage est basée sur un tableau préalloué. Le gros problème de std::unordered_map, c'est que c'est basé sur des listes chainées (l'API impose cela, donc pas moyen de faire sans) et donc c'est catastrophique pour les malloc lors de l'insertion et pour les lignes de cache lors de la recherche d'un élément. Mais regarde le premier talk de Chandler Carruth. Il explique cela très bien (et en plus il met bien en valeur que l'API de std::unordered_map est nulle).

Google en a tellement marre de la librairie standard du C++ qu'ils font la leur (pour des raisons politiques, ils prennent des pincettes et ne critiquent pas la librairie standard, mais bon, il ne faut pas longtemps pour comprendre qu'ils en ont ras la casquette). Elle s'appelle https://abseil.io, et cela a été annoncé il y a quelques semaines. Il n'y a pas encore de table de hachage, mais elle devrait arriver bientôt. C'est une priorité pour eux.

Écrit par : iAPX 18 Oct 2017, 19:04

On est d'accord , mais j'ai deux points à amener (allez 3 !)

1. Photoshop existe en version limitée sur plateforme ARM, nativement
2. Qui sait ce que Adobe a porté ou même optimisé sur plateforme ARM, voir en utilisant OpenCL, en dehors des fonctions de base?!?
3. WTF?!? C'est quoi l'idée d'utiliser un logiciel qui coute plusieurs fois le prix d'un ordinateur destiné à surfer sur le web ou utiliser des services en ligne???

Si un ordinateur doit tout faire, mettez moi l'autonomie de l'iMac et du Mac Pro, ou même la qualité de communication 4G/LTE des MacBook Pro, ou les performances avec plus de 1000VM du Mac Mini de base (après tout IBM sait faire ça en x86) ?
Ça n'a tellement aucun sens!

Coûter moins cher, probablement bien moins cher à performance égale, et avoir beaucoup plus d'autonomie, on reporte au moins 2X plus d'autonomie, peut-être plus, toujours en coutant moins cher, ça va toucher beaucoup de gens, pas nécessairement ceux qui achètent un MacBook Pro retina 15" 16Go/2To en France, mais même en France il y a des gens qui ont moins de moyens, et dans les pays émergents ça risque de changer la donne aussi!

Tout ça me fait penser à la compagnie Indienne Tata, où, en France, tout le monde se moquait de sa voiture à 3500$ avec économies de bout de chandelles (le génie ayant présidé à la conception de la Twingo originelle, poussé un cran plus loin!).
Tata ayant racheté Jaguar et relancé la marque très fort, ça doit beaucoup moins faire rigoler maintenant, meme pour les snobs

Écrit par : vlady 18 Oct 2017, 19:09

Ouf, je comprend mieux maintenant. Avec un nombre d'éléments pareil il peut y avoir des bricoles (resolution des collisions, re-tripatouillage des buckets et rehashing notamment). Je suppose que std::unordered_map::reserve() donne rien de probant.

Écrit par : DonaldKwak 18 Oct 2017, 19:19

Non, car dans std::unordered_map le tableau ne contient pas les couples (clé, valeur), mais un pointeur vers des listes chaînées. Du coup, tu es obligé de payer la prix des indirections et du malloc, même avec un reserve. Voici le code de benchmark (GoogleBenchmark) avec std::unordered_map. Ce n'est peut-être pas le code qui a été fait dans le benchmark de l'époque, mais l'idée est là. Il y a bien un "reserve" à la création de la table de hachage.

Écrit par : SartMatt 18 Oct 2017, 19:21

Encore une fois, je le répète : le "bien moins cher à performances égales" n'est vraiment pas à l'ordre du jour pour l'instant...

On parle de prix autour de 650€ HT EN CHINE pour les premiers modèles. Donc plus cher que des machines x86 à performances égales. Mais avec beaucoup plus d'autonomie à prix égal.

D'ailleurs, ni Microsoft ni Qualcomm n'avancent l'argument du prix, ils communiquent sur l'autonomie et la connectivité 4G...

Écrit par : vlady 18 Oct 2017, 19:40

Je suis d'accord, la STL a ses défauts et cotés obscures (elle n'est quasiment jamais utilisée dans l'industrie de jeux video) mais pour la vaste majorité de projets elle convient très bien. J'ai regardé le code de MongoDB et ça utilise stl à mort. L'essentiel ce n'est pas la rejeter "en bloc" mais s'en servir comme une base (surtout pour des applis de grande envergure) et corriger des imperfections et des "edge cases" à coup d'optimisation spécifiques ou des libs externes qui idéalement doivent être stl compatibles (comme Qt par exemple). En ordre général, j'ai horreur des standards parallels que chaque boite bricole en interne.

Écrit par : iAPX 18 Oct 2017, 19:44

Pourquoi la connectivité c'est pas la performance?
L'autonomie ça n'est pas la performance?

Quelle est la puissance du MacBook Pro retina 15" pour relever des courriels qui n'a pas d'accès WiFi, ni un partage de connexion Bluetooth?

Quelle sont ls performances du MacBook Pro retina 15", sous n'importe quel bench, comparé au nouveau produit Microsoft/Qualcomm, quand il n'est pas branché sur le secteur et sa batterie vide?

Dans les deux cas, ce nouveau produits sera infiniment plus performant, grâce à sa connectivité et son autonomie. Incomparablement meilleur pour une fraction du prix!

Écrit par : SartMatt 18 Oct 2017, 19:49

La connectivité, c'est de la fonctionnalité plus que de la performance.
Et l'autonomie, toi même tu ne l'a pas mis dans les performances, puisque tu parles de beaucoup plus d'autonomie à performance égale...

Écrit par : vlady 18 Oct 2017, 19:55

Ils vont se servir pour se remplir les poches. Le consommateur gagnera rien. Apple a largement ouvert la voie dans la direction "à chaque génération tu payera plus cher pour en avoir moins" et les autres suivrons avec joie dans la conception de toute sorte de machins très fin : Pro, Plus Pro, Plus Mieux Pro (où plus ou pro veut dire "plus cher").

Écrit par : DonaldKwak 18 Oct 2017, 19:56

Je comprends ta position. Mais le problème est qu’il manque tellement de choses basiques comme (pour mon usage) :
- Tableaux multidimensionnels
- Une bibliothèque de formatage de chaines de caractères facile à utiliser, genre format du Python
- Un support correct de l’unicode
- Des exceptions bien utilisées. Je ne suis pas fan des exceptions mais pourquoi si on en met, l’ouverture d’un fichier qui n’existe pas n’en envoie pas une ?

Par contre des ennuis, on en a:
- Des objets indebuggables : depuis quand un iterateur sur un vecteur (et donc un pointeur) est plus facile à debugger qu’un index ? L’enfer que tu prends quand tu entres dans une fonction et que tu te retrouves dans le code de la STL avec une pleiade d’appel pour généralement ne rien faire.
- Des types non signés partout qui rendent fous les optimiseurs de code
- La signature de std::min qui prend deux references et qui renvoie une reference, même avec des entiers. Va demander à un expert C++ ce que fait : const int a = std::min(b + 1, c + 2); Tu vas bien rire et tu comprendras pourquoi pas mal de compilateurs crashent avec ce genre de code (par exemple dans une region OpenMP). Explique moi aussi pourquoi le standard oblige à convertir un float x en double avec std::pow(x, 3). Si tu veux je peux y passer la nuit. Cette bibliothèque a été écrite par des incompétents de bonne volonté, mais des incompétents quand même. Par contre j’aime bien le langage C++ (sans la partie librairie).

Je continue ? Franchement, il faut avoir un penchant masochiste pour aimer tout cela.

Bref, tout ce dont j’ai besoin n’est pas présent. Et ce qu’il y a dans la STL ne m’est pas vraiment utile. Je fais comment ?

Écrit par : dtb06 18 Oct 2017, 20:09

Bon vous êtes bien gentils, je vous comprends, on est dans un forum pro.
Mais avouez franchement que du calcul intensif ou même du Photoshop, on passe directement dans une niche. Combien d'utilisateurs font du Photoshop avec de grosses images et pleins de calques ? A mon avis 5% des utilisateurs.

Alors si on se place dans le logique du pognon (j'essaye en général de ne pas le faire), ça ne sert à rien à MS ou Apple de vendre des stations de travail performantes.

Moi je vous le dis : le seul truc qui sauve les pros, ce sont les gens qui jouent. Parce qu'eux demandent de la puissance à gogo. Et là on est sur des dizaines de pourcent d'utilisateurs. Enlevez les joueurs et vous pourrez payer vos cartes graphiques 10 fois plus cher. Enlevez les joueurs et vos processeurs à 4 ou 10 cores, aucune boîte ne les produira.

Donc Apple et compagnie font miroiter des solutions "Pro", mais en vérité ils recyclent leurs plateformes de jeu à pas cher. C'est d'ailleurs pour ça qu'Apple est mal à l'aise avec les pros actuellement : ils n'ont plus de joueurs donc quand ils sortent un ordi comme le MacPro, ils ne peuvent avoir que des espoirs de vente très très très limités. Les autres (Hp, Dell, etc...) ciblent à 90% le grand public. Vous croyez qu'il y aurait encore des cartes graphiques du style Tesla si le développement chez NVidia ne leur servirait pas à améliorer leurs cartes grand public ?

On le voit d'ailleurs car la plupart du temps il est plus facile de travailler avec un i7 et une 1080Ti (composant grand public) qu'avec du Xeon et du Quadro. Et les différences entre les composants pro et grand public deviennent minimes, on recycle ou on castre les puces au max et on vend du service.

Écrit par : DonaldKwak 18 Oct 2017, 20:15

Entièrement d'accord avec toi.

Mais est-ce qu'une tablette ne suffit pas aux 95% restants ? Quitte à les rendre un peu plus versatiles. Si c'est le cas, est-ce que ce Windows 10 ARM a vraiment un intérêt ?

Écrit par : iAPX 18 Oct 2017, 20:32

Pas sûr pour taper quelque-chose, mais peut-être te méprends-tu entre un facteur de forme, qui amène des usages différents et un niveau de performance, pas nécessairement différent?!?

Ou dis autrement, à performances similaire, un gros SUV et une petite voiture n'ont pas le même usage...

Écrit par : vlady 18 Oct 2017, 22:57

Tu fais comme la personne qui a écrite une excellente lib pybind11. Tu compètes le manque tout en préservent l'esprit stl (les conventions de nommage des méthodes, la cohérence des noms, genre "size", ...), tu implémentes les itérateurs (ça évite de se planter avec les indexes dans les boucles for) etc. Pourquoi ? Pour que les autres puissent comprendre et intégrer ton travail plus facilement. Je n'aime pas spécialement stl mais c'est un standard, il n'y a rien d'autre, malheureusement. Moi, je trouve C++ dépassé, plein de verrues, de bidouilles et de compromis à deux balles. Je préfère des langages plus modernes, Rust notamment, qui a été une révélation pour moi et j'espère que un jour il remplacera C++, Swift est très bien aussi.

T'as regardé ça ?

https://github.com/electronicarts/EASTL

Just pour étayer un peu plus mes propos, voici comment Google décrit Abseil :

Abseil is an open-source collection of C++ code (compliant to C++11) designed to augment the C++ standard library.

Écrit par : amike 19 Oct 2017, 05:13

Cette affaire n'a pas l'air de faire beaucoup d'étincelles : le cours de Qualcomm ne bouge pas, Intel ne dévisse pas plus, et Microsoft semble avoir trouvé une nouvelle façon de perdre les milliards de ses vaches à lait dans une nouvelle danseuse...

Le seul message marketing qu'arrivera le nouveau couple diabolique à faire passer au grand public, c'est de dire qu'ils ont fait un meilleur chromebook qu'Alphabet

AMHA, le problème est plus du coté du contenant(encore un ordinateur portable !) plutôt que le contenu (tout aussi innovant qu'il soit).

Écrit par : DonaldKwak 19 Oct 2017, 06:59

- EASTL et consorts : J'ai bien entendu étudié la EAST et les tentatives similaires. La raison d'existence de la EASTL est liée aux allocateurs de mémoire qui sont une catastrophe dans la STL puisqu'ils n'ont jamais été pensés pour allouer de la mémoire mais plutôt pour une vieillerie des architectures Intel (les far pointers). Du coup, ils ont essayé de trouver une solution à cela. Une autre solution se trouve dans la BDE de Bloomberg (C'est https://github.com/bloomberg/bde). C'est plutôt leurs idées qui sont implémentées dans les dernières versions de la STL. Personnellement, je n'aime ni l'une, ni l'autre et j'ai implémenté ce dont j'ai besoin directement dans mes conteneurs : par exemple la possibilité de ne pas initialiser les éléments de l'équivalent du std::vector<double>, ou de les initialiser à NaN en mode debug, ou encore la possibilité d'avoir la mémoire allouée sur les lignes de cache qui sont aussi les adresses de registres vectoriels. Les allocateurs spéciaux sont un problème majeur de la STL car dès que tu les utilises, tu change le type de ton objet et donc tu perds toute la compatibilité avec les librairies extérieures !!! De toute manière, je pense qu'il n'y a qu'une seule façon portable de communiquer avec une bibliothèque : faire du C.

- Esprit de la STL : J'ai oublié de te dire l'essentiel, à savoir que la plupart des personnes qui utilisent ma bibliothèque font du calcul scientifique, chose pour laquelle le Fortran est encore considéré comme une bonne solution (ce qui est en partie vrai, mais le Fortran devient ingérable dès qu'on sort du numérique, et les outils liés aux Fortran sont beaucoup moins développés qu'en C++). Les indices, ceux qui utilisent ma bibliothèque en sont tous très friands. On a rien trouvé de mieux pour se déplacer dans un tableau, une image, etc. De plus, comment écrit-on cela avec des itérateurs: for (int i = 1; i < n - 1; ++i) { a[i] = b[i - 1] + b[i] + b[i + 1] }.
Une autre raison est que ceux qui utilisent ma bibliothèque ne sont pas Computer Scientist. Et ils sont très contents de ma chaine de caractère qui stocke tout en UTF8 et les utilitaires de lecture/écriture des fichiers qui font la conversion de manière transparente en UTF16 lorsqu'on est sous Windows (le même code compile sous Linux, macOS et Windows). Je les empêche d'accéder au k-ème caractère (pas de [k]) car cela n'a pas de sens en unicode. Je les empêche aussi de faire des choses suboptimales avec les chaînes de caractères comme s1 + s2 + s3 + s4. À la place, il faut faire join(s1, s2, s3, s4) et c'est beaucoup plus efficace. Bref, l'avantage que j'ai de vivre en dehors de la STL, c'est d'empêcher mes utilisateurs d'utiliser pleins de fonctions de la STL qu'il ne faut surtout pas utiliser, pour des raisons de bug latent ou de performance.
Mais, j'ai bien sur des itérateurs sur certains de mes conteneurs comme l'équivalent des std::vector, car j'ai envie d'utiliser std::sort qui est très bien.

- Portabilité de la performance : Une chose que je considère aussi très importante est la portabilité de la performance. Et c'est un gros problème avec la STL car elle est implémentée différemment selon les plateformes. std::string est un très bon exemple avec les différentes manières de faire des "small string optimization". Par exemple sous libc++ (clang), l'accès s[k] est beaucoup plus couteux que sur libstdc++ (gcc) car s[k] se demande toujours si s est une petite ou une grande chaine de caractères. Bref, la manière dont est codée la STL influence la manière dont on code pour avoir la performance optimale. L'avantage de ma bibliothèque est qu'elle compile sous VS, clang, gcc, intel, PGI sur Windows/Mac/Linux et que quand on a optimisé pour une plateforme, on a en général optimisé pour toutes les autres.

- Abseil : Effectivement, c'est ce que Google écrit. Il ne faut pas oublier que Titus Winters qui s'occupe d'Abseil fait partie du "standard committee" du C++ et donc doit prendre des gants avec la STL. Reste qu'une des premières choses qu'il a promis, c'est une table de hachage, un truc qui existe déjà dans la STL... Si c'est pas un "remplacement" ça... Il y a déjà un remplacement de std::string_view aussi. Bref, c'est quand même pensé pour remplacer les parties de la STL que Google n'aime pas.

Mais je comprends tout à fait ta position qui a beaucoup de sens. Je suis juste dans un marché de "niche" pour le C++, un marché où le Fortran n'était pas si mal (avec bien sur toutes ses limitations) et ou les itérateurs apportent plus d'ennuis que de solutions. Enfin, Rust et Swift sont très bien (pas pour faire du calcul scientifique, mais pour beaucoup d'autre choses) mais le C++ se compile n'importe où, ce qui est un avantage considérable.
Reste quand même que tous les projets que je connais où la performance est un facteur important font soit du C, soit du C+ (du C++ sans la STL; John Carmack fait ce genre de choses), soit du C++ en remplaçant une grande partie de la STL (LLVM est un exemple). Cela met en valeur un des grands problèmes du C++ : le fait qu'il y a autant de façon de programmer le C++ que de programmeurs. C'est un problème considérable, mais c'est aussi ce qui fait que le C++ a eut son succès. Si on considère que c'est un problème, je ne crois pas qu'il faille jeter la pierre aux programmeurs, mais plutôt à ceux qui ont décider d'intégrer les conteneurs et toutes ces choses de bas niveau non pas dans le langage mais dans la librairie standard.

Écrit par : Skwaloo 19 Oct 2017, 07:16

???!!!
Il existe un fabricant qui pense à ce marché lilliputien pour fabriquer leur ordi ?!
Un fabricant arrive à vivre grâce à ce marché ?!
Tous les x86 vendus correspondent très bien à cette utilisation ?!

Tes besoins personnels sont certainement très loin des machines les + réclamées par les utilisateurs. Le fantasme d'avoir toujours + de performances phénoménales n'est pas le centre du marché. Il se vend près de 3 fois + d'iPad que Mac...un hasard ?...

Écrit par : jakin1950 19 Oct 2017, 07:40

De nombreux projets industriels ont fait flop
C'est le consommateur qui achètera ou pas
Il y. À plusieurs marchės
La tablette est bien pour consulter et taper quelques lignes
Un portable a des besoins fonction de son utilisation : j'ai une nvidia 1080 sur le mien pour la vidéo
Ma femme a un MacBook Air

Un étudiant a besoin d'un portable avec clavier pouvant faire tourner une version légère d.Office
Qu'il soit avec un processeur Intel ou arm n'a pas d.importance: prix et autonomie sont les 2 critères importants

Mon gendre architecte utilisé un Surface
J'ai vu des chanteurs utiliser un iPad pour les bandes sons et les paroles

Les utilisations sont très différentes

Écrit par : Hebus 19 Oct 2017, 09:59

@Vlady

Ha que tu est conventionnel... un peu de fantaisie !

Je n'ai jamais aimé le C++ et pourtant j'en ai bien fait 12 ans à 100% sur des gros projets, j'en ai fait à une époque n'ayant pas de generic... on en faisait avec des macros et l'opérateur ##, mais n'ayant jamais aimé ça j'ai du le faire mal.
Il est vrai qu'avant de faire du C++ en 93, j'avais fait 5 ans d'Ada et je jouais avec ObjectiveC et Mathematica depuis plus de 3 ans, ça n'aide pas.

Bien que j’ai apprécié bossé 5 ans sur une application CORBA et Qt, Corba l’enfer en C++ mais Qt, très inspiré par le design de NeXTStep était un bel outil, et en effet le fait qu’ils respectent dans leur struct un certain pattern stl facilitait les choses.

Je ne suis sans doute pas assez hacker pour comprendre pourquoi STL est aussi compliqué, et dès qu’une lib demande à ce que tu traces avec le debugger pour savoit pourquoi ça merde... c’est qu’il y a une couille dans le potage... on a assez de la complexité de nos propres projets pour avoir en plus à se taper la complexité du code des libs que l’on utilise.

Actuellement je me bas avec la profusion de style de containers dans les libs Scala/Java ... une sorte d'entropie qu'ils estiment contrôlée grace aux usines à gaz de gestion de paquets et de versions dans lesquelles on ne se retrouve plus... putain je dois être trop vieux !

Donc je comprends un peu l’approche de DonaldKwak... y a un moment pour faire baisser l’entropie et controler les performances... il vaut mieux faire le truc soi même.



Il faut pouvoir...

Écrit par : iAPX 19 Oct 2017, 11:34

+1 ça doit être un truc de vieux, je suis exactement du même avis, à des moments faut se sortir les doigts du cul, et même certaine implémentations que j'ai réalisées, extrêmement basiques, ont pu se révéler plus performantes, à un ordre de magnitude ou deux (!!!), face à de grosses solutions packagées.

Écrit par : vlady 19 Oct 2017, 12:55

Justement ce qu'on me reproche tout le temps c'est être en trop avance et aimer trop les nouveautés. Mais on est pas toujours seul au monde et chaque réalisation de divise en 2 parties : une agréable (innovante, créative, ...) et une autre, chiante, qui peut bouffer du temps infini. Et cette deuxième partie, je préfère la torcher à coup de stl (si c'est possible bien évidemment), pour faire quelque chose de robuste et maintenable et en temps raisonnable, pour dégager plus de temps pour le travail intéressant. Aller vers l'avant ça m'intéresse. Me prendre pour un génie et continuellement réinventer la roue non.

Écrit par : DonaldKwak 19 Oct 2017, 13:06

Il suffit de la réinventer une seule fois. En puis, si on a pas un ego gros comme un camion, qu'est-ce qu'on fait avec un Mac et une certaine admiration (raisonnée bien sur) pour Steve Jobs ?

Et puis sérieusement, vlady, personne n'a critiqué ta manière de faire. C'est très bien. Par contre, on pourrait facilement être offensé par tes propos.

Écrit par : vlady 19 Oct 2017, 16:05

Désolé, ce n'était pas mon intention, je te pris de m'excuser.

Sinon, je n'ai aucune admiration pour Steve Jobs. J'ai commencer ma carrière sur le matériel Sun et sur un vrai Unix (Solaris) et c'est pour cette raison (Unix et je méprise leur OS avant cette époque) je suis venu sur la plateforme Apple. Quand macOS cessera définitivement d'être un Unix de "très bonne facture" je changerai sans aucune hésitation.

Écrit par : Hebus 19 Oct 2017, 16:31

Ha... bof j’ai fais du Sun très tôt... j’avais accès à des Sun 3 entre 86 et 88 puis des Sun 4 à l’INRIA... des machines Apollo avant qu’ils soit rachetés par HP... des machines HP/Appolo aussi... des stations Sony également sans compter la NeXT station acheté par mon boss pour que je ne parte pas trop vite ... , tout ça avant 91/92 donc...

Rien de fantasmagorique... un systeme sans belles applications ce n’est rien... sauf si on adore le shell et sendmail.cf

Écrit par : DonaldKwak 19 Oct 2017, 16:44

C'est pas bien grave.

Sinon j'ai fait du Solaris en 1997 et je suis venu chez Apple en 2002 le MacBook de l'époque sur lequel j'ai voulu mettre Linux. Quand j'ai vu qu'OSX était très bien (j'adorais les fontes, comme quoi, ça tient à peu de choses), je l'ai laissé.

Écrit par : vlady 19 Oct 2017, 18:01

Quand j'ai commencé, c'était des Sparkstation 5 (les boite à pizza) comme sur l'image (3 stations empilés)

https://en.wikipedia.org/wiki/SPARCstation_5#/media/File:Sparcstack.jpg

J'avais une comme ça avec un moniteur Sony Trinitron, exactement comme sur l'image, Solaris et Motif dessus. Et avec une souris optique !!!
J'ai adoré ce matos.

Écrit par : DonaldKwak 19 Oct 2017, 18:08

Même boites à pizza chez nous en 1997. Et la souris optique et son tapis bizarre, genre "métallique".

Écrit par : Hebus 19 Oct 2017, 18:49

Entre 93 et 97 des SGI, pizza box, Indigo (la pizza box 170000Fr), Motif et OpenGL... et machines NeXT et PC sous NeXTStep

logiciel en C++ avec au départ la lib Interviews qui est devenue Fresco sous X11R6... j'ai fini par reprendre les .h de NeXTStep, Interview était trop complexe et buggée, et on a codé notre propre toolkit en C++ ... notre propre Rtti et une techno d'action plus rapide que le switch/case utilisé dans Qt (pointeur d'objet et fonction membre avec un cast sauvage à la clef qui fonctionnait car toutes nos classes avait la même classe mère) ... archivage d'objets, UI en Motif, OpenGL et PostScript... pour l'impression... soft réécrit avec la YellowBox par une partie de l'équipe pour le revendre à une boite de production de dessin animés Belge, Neurones... épique !

Après ça en 98/99 redirigé sur un projet qu'on a réalisé sur des PowerMac 8600/9600 sous Rhapsody (NeXTStep au look Mac OS 8/9 et sur des PC avec la YellowBox.... OpenStep sous winshiote

Écrit par : DonaldKwak 19 Oct 2017, 20:21

En parlant de processeur, les premiers retours des AMD Epyc (c'est comme les Ryzen mais pour les serveurs) sont assez nets : la bande passante mémoire par coeur est très bonne, a peu près 50% meilleure que chez Intel. Donc c'est très utile dans certains cas. Par contre les effets NUMA (Non-Uniform Memory Architecture) dûs au fait qu'un processeur contient de nombreuses tuiles de 8 coeurs font que c'est quasi improgrammable de manière optimale dès que les coeurs doivent communiquer entre eux. Bref, c'est pas AMD qui va faire peur à Intel sur le marché des serveurs...

Les Xeons Skylake (et Basin Falls pour les iMac Pro, et Core i7/i9 enthousiastes) avec leur communication entre les coeurs héritée des Xeon Phi KNL sont très loin devant.

Écrit par : downanotch 20 Oct 2017, 07:51

Oui, avec un très fin quadrillage dessiné dessus…

Écrit par : DonaldKwak 20 Oct 2017, 10:04

Oui c’est bien ça. La belle époque. On parlait encore en ancien francs...

Écrit par : Hebus 20 Oct 2017, 10:20

Et on croyait que Sun serait là pour longtemps...

Ils était à Velizy d'ailleurs, encore en 2000/2001

Écrit par : DonaldKwak 20 Oct 2017, 10:34

En 2001 justement, j’étais dans un centre de recherche d’une grosse boite aux USA et les seuls qui trouvaient leur SUN genial, c’était quand même ceux qui s’étaient ruiné à acheter leur matos. Je me souviens d’ailleurs avoir fait une présentation de Linux. On me regardait avec scepticisme.

On avait d’ailleurs un gros cluster qui faisait tourner SETI@home 90% de son temps. L’admin système voulait les trouver ces martiens !!! C’est à cette époque que j’ai vu tourner OSX pour la première fois. Je trouvais ça plus cool que les SUN.

Écrit par : Skwaloo 2 Nov 2017, 14:52

Mais Intel prévoit des ARM exceptionnellement performant !!!...MDR
Intel montre que les archi des x86 sont mauvaises !

http://www.tomshardware.fr/articles/arm-soc-intel-smartphone,1-65852.html