IPB

Bienvenue invité ( Connexion | Inscription )

3 Pages V  < 1 2 3 >  
Reply to this topicStart new topic
> Microsoft et Qualcomm sortiront des ordinateurs portables ARM d'ici la fin de l'année, Réactions à la publication du 18/10/2017
Options
__otto__
posté 18 Oct 2017, 16:33
Message #31


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 1 253
Inscrit : 28 Mar 2011
Membre no 165 999



Citation (SartMatt @ 18 Oct 2017, 15:52) *
Citation (os2 @ 18 Oct 2017, 15:16) *
la vidéo montre clairement que c'est pas très réactif... et cela sur des opérations de bases...
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)...

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


--------------------
Je suis plus Charlie depuis que
je suis écouté

Mac Plus, SE 30, mac si, mac ci,mac lc (1,2,3,4), ppc (presque toutes les machines sauf les G5), imac 2011, macbook pro 2012
i7 3.4ghz, 16 go ram, ssd 512 Mo, 1 To HDD, GTX 1080 + GTX 980 histoire de dire, bref un pulvérisateur de mac pro!
Et mon nouveau beau joujou : 2080 Core + 260 NVIDIA TESLA K20X 4,1 To de RAM et quelques centaines de To stockage! et accessoirement ça chauffe bien!
Go to the top of the page
 
+Quote Post
SartMatt
posté 18 Oct 2017, 16:36
Message #32


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (DonaldKwak @ 18 Oct 2017, 16:53) *
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.
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...


--------------------

Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 16:38
Message #33


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (pmr115 @ 18 Oct 2017, 17: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.


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.

Ce message a été modifié par DonaldKwak - 18 Oct 2017, 16:41.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
SartMatt
posté 18 Oct 2017, 16:40
Message #34


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (__otto__ @ 18 Oct 2017, 17:33) *
Il y a de forte chance que ce sit ton GPU et non ton CPU qui s'occupe du calcul...
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/pho...u-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.


--------------------

Go to the top of the page
 
+Quote Post
vlady
posté 18 Oct 2017, 17:04
Message #35


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 627
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (DonaldKwak @ 18 Oct 2017, 17:38) *
Citation (pmr115 @ 18 Oct 2017, 17: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.


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.


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)...


--------------------
Macbook 16" M1 Pro 32GB/1TB + Studio Display, Dell Precision 3640 i7-10700K/32GB, Fedora 36 Linux, Casque Sony WH-1000XM4, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 17:25
Message #36


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (vlady @ 18 Oct 2017, 18: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)...


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 : Chandler Carruth "Efficiency with Algorithms, Performance with Data Structures"

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 : Chandler Carruth “High Performance Code 201: Hybrid Data Structures"

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 :-)

Ce message a été modifié par DonaldKwak - 18 Oct 2017, 17:37.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
Skwaloo
posté 18 Oct 2017, 17:38
Message #37


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 497
Inscrit : 16 Oct 2005
Membre no 48 046



Citation (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...


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.


Citation (os2 @ 18 Oct 2017, 14:05) *
le pc est en train de devenir un niche

+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.



Citation (SartMatt @ 18 Oct 2017, 14:52) *
pour avoir testé plusieurs logiciels sous linux sous arm vs x86, les performances sont souvent bien moins bonnes en arm...

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 laugh.gif laugh.gif laugh.gif
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.



Citation
Pour l'émulation x86, je ne vois pas bien l'intérêt, à part pour de tous petits utilitaires.

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.



Citation (os2 @ 18 Oct 2017, 14:16) *
après ça va faire comme bien des gens avec les tablettes... ils achètes et après ils vont déchanté assez rapidement

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



--------------------
Go to the top of the page
 
+Quote Post
os2
posté 18 Oct 2017, 17:48
Message #38


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 624
Inscrit : 21 May 2002
Membre no 2 515



Citation (Skwaloo @ 18 Oct 2017, 18: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.

présent de vrai application et pas juste des tests bidon pour épater le décideur pressé ou le geek du dimanche

Citation (os2 @ 18 Oct 2017, 14:16) *
après ça va faire comme bien des gens avec les tablettes... ils achètes et après ils vont déchanté assez rapidement

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


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


--------------------
Steve Job: Les bons artistes copient, les grands artistes volent, nous avons toujours été sans scrupule lorsqu'il s'agit de voler de grandes idées.
Go to the top of the page
 
+Quote Post
os2
posté 18 Oct 2017, 18:05
Message #39


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 624
Inscrit : 21 May 2002
Membre no 2 515



Citation (DonaldKwak @ 18 Oct 2017, 17:38) *
Citation (pmr115 @ 18 Oct 2017, 17: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.


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.


ç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

Ce message a été modifié par os2 - 18 Oct 2017, 18:06.


--------------------
Steve Job: Les bons artistes copient, les grands artistes volent, nous avons toujours été sans scrupule lorsqu'il s'agit de voler de grandes idées.
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 18:11
Message #40


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (os2 @ 18 Oct 2017, 19: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


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 : "The free lunch is over". 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."

Ce message a été modifié par DonaldKwak - 18 Oct 2017, 18:16.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
vlady
posté 18 Oct 2017, 18:32
Message #41


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 627
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (DonaldKwak @ 18 Oct 2017, 18:25) *
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 :-)


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 ?


--------------------
Macbook 16" M1 Pro 32GB/1TB + Studio Display, Dell Precision 3640 i7-10700K/32GB, Fedora 36 Linux, Casque Sony WH-1000XM4, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 18:41
Message #42


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (vlady @ 18 Oct 2017, 19: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 ?


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

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 Abseil, 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.

Ce message a été modifié par DonaldKwak - 18 Oct 2017, 18:59.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
iAPX
posté 18 Oct 2017, 19:04
Message #43


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 371
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Citation (Lionel @ 18 Oct 2017, 10: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.

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 wink.gif

Ce message a été modifié par iAPX - 18 Oct 2017, 19:18.


--------------------
Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
Go to the top of the page
 
+Quote Post
vlady
posté 18 Oct 2017, 19:09
Message #44


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 627
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (DonaldKwak @ 18 Oct 2017, 19:41) *
Citation (vlady @ 18 Oct 2017, 19: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 ?


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

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 Abseil, 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.


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.


--------------------
Macbook 16" M1 Pro 32GB/1TB + Studio Display, Dell Precision 3640 i7-10700K/32GB, Fedora 36 Linux, Casque Sony WH-1000XM4, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 19:19
Message #45


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (vlady @ 18 Oct 2017, 20:09) *
Je suppose que std::unordered_map::reserve() donne rien de probant.


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.

Code
static void unorderedMap(benchmark::State& state) {
  const std::size_t n = 50'000'000;
  std::vector<std::size_t> v{n};
  std::size_t k = 1234567891;
  for (std::size_t i = 0; i < n; ++i) {
    v[i] = k / 2;
    k = 93u * k + 117u;
  }

  while (state.KeepRunning()) {
    std::unordered_map<std::size_t, std::size_t> map{n};
    for (std::size_t i = 0; i < n; ++i) {
      map[v[i]] = 0;
    }
  }
}


Ce message a été modifié par DonaldKwak - 18 Oct 2017, 19:20.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
SartMatt
posté 18 Oct 2017, 19:21
Message #46


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (iAPX @ 18 Oct 2017, 20:04) *
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!
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...


--------------------

Go to the top of the page
 
+Quote Post
vlady
posté 18 Oct 2017, 19:40
Message #47


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 627
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (DonaldKwak @ 18 Oct 2017, 20:19) *
Citation (vlady @ 18 Oct 2017, 20:09) *
Je suppose que std::unordered_map::reserve() donne rien de probant.


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.

Code
static void unorderedMap(benchmark::State& state) {
  const std::size_t n = 50'000'000;
  std::vector<std::size_t> v{n};
  std::size_t k = 1234567891;
  for (std::size_t i = 0; i < n; ++i) {
    v[i] = k / 2;
    k = 93u * k + 117u;
  }

  while (state.KeepRunning()) {
    std::unordered_map<std::size_t, std::size_t> map{n};
    for (std::size_t i = 0; i < n; ++i) {
      map[v[i]] = 0;
    }
  }
}



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.

Ce message a été modifié par vlady - 18 Oct 2017, 19:42.


--------------------
Macbook 16" M1 Pro 32GB/1TB + Studio Display, Dell Precision 3640 i7-10700K/32GB, Fedora 36 Linux, Casque Sony WH-1000XM4, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
iAPX
posté 18 Oct 2017, 19:44
Message #48


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 371
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Citation (SartMatt @ 18 Oct 2017, 14:21) *
Citation (iAPX @ 18 Oct 2017, 20:04) *
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!
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...

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!


--------------------
Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
Go to the top of the page
 
+Quote Post
SartMatt
posté 18 Oct 2017, 19:49
Message #49


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 32 183
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (iAPX @ 18 Oct 2017, 20:44) *
Citation (SartMatt @ 18 Oct 2017, 14:21) *
Citation (iAPX @ 18 Oct 2017, 20:04) *
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!
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...
Pourquoi la connectivité c'est pas la performance?
L'autonomie ça n'est pas la performance?
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...

Ce message a été modifié par SartMatt - 18 Oct 2017, 19:49.


--------------------

Go to the top of the page
 
+Quote Post
vlady
posté 18 Oct 2017, 19:55
Message #50


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 627
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (SartMatt @ 18 Oct 2017, 20:21) *
Citation (iAPX @ 18 Oct 2017, 20:04) *
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!
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...


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").


--------------------
Macbook 16" M1 Pro 32GB/1TB + Studio Display, Dell Precision 3640 i7-10700K/32GB, Fedora 36 Linux, Casque Sony WH-1000XM4, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 19:56
Message #51


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (vlady @ 18 Oct 2017, 20:40)
En ordre général, j'ai horreur des standards parallels que chaque boite bricole en interne.


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 ?

Ce message a été modifié par DonaldKwak - 18 Oct 2017, 20:06.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
Guest_dtb06_*
posté 18 Oct 2017, 20:09
Message #52





Guests






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.
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 18 Oct 2017, 20:15
Message #53


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (dtb06 @ 18 Oct 2017, 21:09) *
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.
...


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 ?


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
iAPX
posté 18 Oct 2017, 20:32
Message #54


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 15 371
Inscrit : 4 Jan 2006
Lieu : dtq
Membre no 52 877



Citation (DonaldKwak @ 18 Oct 2017, 15:15) *
Citation (dtb06 @ 18 Oct 2017, 21:09) *
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.
...


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 ?

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...


--------------------
Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
Go to the top of the page
 
+Quote Post
vlady
posté 18 Oct 2017, 22:57
Message #55


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 2 627
Inscrit : 26 Jun 2010
Lieu : Paris
Membre no 155 873



Citation (DonaldKwak @ 18 Oct 2017, 20:56) *
Citation (vlady @ 18 Oct 2017, 20:40)
En ordre général, j'ai horreur des standards parallels que chaque boite bricole en interne.


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 ?


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.

Ce message a été modifié par vlady - 18 Oct 2017, 23:14.


--------------------
Macbook 16" M1 Pro 32GB/1TB + Studio Display, Dell Precision 3640 i7-10700K/32GB, Fedora 36 Linux, Casque Sony WH-1000XM4, iPhone 6s 64GB
Go to the top of the page
 
+Quote Post
amike
posté 19 Oct 2017, 05:13
Message #56


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 506
Inscrit : 9 Aug 2012
Membre no 178 091



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 laugh.gif

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).
Go to the top of the page
 
+Quote Post
DonaldKwak
posté 19 Oct 2017, 06:59
Message #57


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 392
Inscrit : 15 Aug 2017
Membre no 202 990



Citation (vlady @ 18 Oct 2017, 23: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.


- 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 ici). 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.

Ce message a été modifié par DonaldKwak - 19 Oct 2017, 07:42.


--------------------
"Dites, monsieur le président, c'est vrai que comme dit mon papa vous nous espionnez sur internet ?"
"Il exagère. Et puis c'est pas ton père d'ailleurs"
Go to the top of the page
 
+Quote Post
Skwaloo
posté 19 Oct 2017, 07:16
Message #58


Macbidouilleur de bronze !
**

Groupe : Membres
Messages : 497
Inscrit : 16 Oct 2005
Membre no 48 046



Citation (os2 @ 18 Oct 2017, 18:48) *
Citation (Skwaloo @ 18 Oct 2017, 18: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.

présent de vrai application et pas juste des tests bidon pour épater le décideur pressé ou le geek du dimanche

Citation (os2 @ 18 Oct 2017, 14:16) *
après ça va faire comme bien des gens avec les tablettes... ils achètes et après ils vont déchanté assez rapidement

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


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

???!!!
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 ?...


--------------------
Go to the top of the page
 
+Quote Post
jakin1950
posté 19 Oct 2017, 07:40
Message #59


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 569
Inscrit : 5 May 2005
Lieu : La Rochelle
Membre no 38 497



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


--------------------
Fan d'Apple depuis l'apple 2 c

Derniers produits Apple achetés : 1 MacBook Air pour ma femme , 2 iphone 8
Passé à Windows en 2015.

Je continue à suivre macbidouille
Nostalgie d'une époque que les moins de 70 ans ne peuvent pas connaître
Go to the top of the page
 
+Quote Post
Hebus
posté 19 Oct 2017, 09:59
Message #60


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 7 134
Inscrit : 24 Sep 2015
Lieu : Pays d'Aix
Membre no 196 570



@Vlady

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

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...

Ce message a été modifié par Hebus - 19 Oct 2017, 10:35.


--------------------
Bobo du Pays d'Aix et Fanboy Apple
Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3 >
Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 28th March 2024 - 22:12