Le 14/04/2020 à 13h 51

Donc la seule source c’est le CTO de NSO, une des boîtes les moins respectables du monde (bien après FB), qui se trouve être en procès avec FB. Le CTO peut bien raconter n’importe quoi puisqu’il ne sera jamais expulsé vers les US, et qu’il raconte des discussions informelles donc improuvables, ok.
 
L’article dit “En 2017, deux représentants de Facebook avaient demandé à la société israélienne NSO de leur fournir une technologie susceptible de permettre au réseau social de mieux pouvoir surveiller les utilisateurs de terminaux Apple, révèle Motherboard.”, c’est pas exactement la même chose, l’honnêteté intellectuelle ça existe.

Via le VPN cité (qui n’a rien à voir avec NSO), FB connaissait bien l’usage de WhatsApp, qui était très gros en dehors des US. En dehors des US, la plate forme depuis longtemps ultra dominante est.. Android, l’article mentionne que le VPN marchait très bien sur cette plate forme (rappel: VPN et usagers payés par FB en échange d’avoir accès aux données pour stats, éminemment critiquable mais qui n’a rien à voir avec NSO). Donc FB ayant eu besoin de NSO (qui fonctionne par ailleurs à “petite” échelle, il n’y a pas tant de journalistes que ça à trucider ou d’opposants politiques à emprisonner), c’est objectivement assez peu crédible.

Sinon je suis un vieux lecteur de PCI, ça doit dater d’il y a 15 ans, c’est pas de gaieté de cœur que je vous reprends sur des questions de journalisme, c’est clair.

Le 08/04/2020 à 17h 12

source, PCI/NextI ? C’est ce que NSO raconte, il y a une autre source crédible ou vous relayez juste ce qu’ils disent ? Vous mélangez deux histoires, celle du VPN qui était effectivement très discutable (mais légale) et étayée par des faits, et ce que NSO (une boîte bien, bien pourrie moralement) vient de raconter pour essayer de se sortir d’un procès avec WhatsApp. Curieux de savoir si vous avez vraiment des infos sérieuses ou si c’est juste parce que c’est rentable de taper sur FB ?

Disclaimer: je bosse chez FB, qui a sans doute plein de défauts mais fourni aussi un service gratuit et identique à tout le monde, riche ou pauvre, du Nord au Sud, on ne peut pas en dire autant de tout le monde.

Le 31/03/2017 à 10h 54

c’est plutôt un an les RSU d’habitude

Le 31/03/2017 à 10h 52

si tu veux absolument parler de (ou à) Carmack, tu peux venir travailler chez Oculus sinon.. " />

Le 31/03/2017 à 10h 50

‘un verdict’ != ‘ce dernier verdict, qui n’a rien à voir avec Luckey par ailleurs mais que je cite parce que Carmack est dedans’, pas forcément clair pour tous ceux qui n’ont pas tes pouvoirs omniscients.
Papier sur Luckey mais c’est pas moi qui y cite Carmack pour rappel, je réagis juste à cette citation un peu hors contexte… Je sais que c’est une référence facile, un peu un passage obligé quand on écrit une actu sur Oculus (même si ça n’apporte pas grand chose sur le fond, qui est que Luckey dégage officiellement)

Le 31/03/2017 à 09h 34

La seule condamnation liée à Carmack est celle du ‘copyright infringement’ (ce que j’avais traduit par ‘vol de code’), ce pourquoi FB a été condamné à 50M.

 Carmack n’est pas concerné par le reste, la condamnation pour le NDA concerne Luckey avant la création d’oculus en fait (mais facebook est condamné parce que le jury considère qu’oculus a pris la suite des efforts précédents de luckey), la violation de trademark concernait Luckey, Iribe et Oculus d’avant Carmack.
 
 A mon sens ce n’était pas très clair dans l’article, dans lequel on a l’impression que tout est lié. La condamnation dans laquelle apparaît Carmack concerne 10% de la somme en jeu, et 2.5% de la valeur d’Oculus lors du rachat par Facebook. Comme Carmack est une figure visible c’est facile de le mettre en avant, mais mon point était que ça ne traduisait pas vraiment bien le procès.

Le 31/03/2017 à 09h 08

En résumé de l’article, le jury a donné à Zenimax:

• 250M pour violation de marque déposée
  


• 200M pour NDA
  


• 50M pour ‘vol de code’, parce qu’ils considèrent qu’il a eu des copier/coller (ou quasi) avec du code que Carmack avait. C’est presque rien, par rapport à la valeur publique de rachat de Oculus par exemple, et c’est parce qu’en fait ce code ne vaut pas grand chose
  
  Il n’y a rien pour de l’IP, rien n’appartient à Zenimax contrairement à ce qu’ils réclamaient

Le 31/03/2017 à 09h 01

Ellierys a écrit :

Carmack a bien été reconnu coupable de “conversion de propriété intellectuelle” par la cour. Il n’a seulement pas été condamné au versement de dommages à ce titre. Par contre il doit 50 millions pour “violation de marque déposée et pour tromperie sur l’origine d’un produit”

Les claims de Zenimax concernant l’IP reliée à la VR ont été complètement rejetés, ce qui est passé est lié à du copyright & NDA, rien à voir avec du fond.
 
Explication relativement claire, ma formulation n’était pas bonne dans le commentaire ci-dessus, je fais une différence entre le ‘vol de code’ et la reconnaissance que l’IP ne vient pas de Zenimax
 
 

Le 31/03/2017 à 08h 33

L’article est un peu bizarrement formulé, Carmack a bien été relaxé de l’accusation de vol de code, qui était un peu ridicule. Luckey et Iribe avaient été condamnés par rapport au NDA signé et pas respecté avec Zenimax, et par rapport à leurs démos sur Doom si je me souviens bien, pas du tout le même type d’IP.
Sinon ça fait quelques temps que Palmer n’était pas vraiment visible chez oculus, pas une grande surprise

Le 15/03/2017 à 16h 11

ça ne tue pas grand chose à mon avis, la clientèle de l’OC sera contente de pouvoir le faire, mais les puces dans le 1800 sont quand même meilleures et n’ont pas besoin d’OC, pour tout un tas de gens (professionnels ou gens pressés) c’est suffisant pour payer 200e de plus.

Le 14/12/2016 à 14h 28

GrosBof a écrit :

Bah non, on en sait rien justement. C’est pas leur 2 comparatifs douteux qui permettent de le savoir.
Donc au contraire ça pue même des fesses leur affaire qu’ils n’aient rien eu à présenter de probant.
 
Il faut attendre les benchs (et les prix).


On ne sait pas tout, mais on ne sait pas rien (c’est logiquement très différent). Il y a une marge d’erreur liée aux conditions de test, mais elle n’est pas si énorme vu qu’on a le temps de calcul et la consommation. Les deux (handbrake et blender) sont open source, donc probablement recompilés pour ce CPU en particulier (ce qui ne sera pas le cas des vieux programmes legacy), mais on a quand même une bonne idée des perfs

Le 14/12/2016 à 11h 44

C’est quand même pas mal, pour une fois, non ? Les promesses ont l’air tenues en termes de perfs, c’est encore un peu tôt pour avoir les prix, mais vu d’où AMD partait en termes de perfs c’est quand même une sacrément bonne nouvelle.
Ça fait plusieurs générations qu’Intel se rate, sans trop de conséquences en termes de part de marché, bien content de voir de la concurrence arriver par le bas (ARM), en latéral (puces Apple déjà plus rapides que les puces ultrabook Intel) et par le haut donc on dirait, pas trop de raison de râler pour moi (à part pour des détails assez prévisibles, si la fabrication en masse n’est pas encore commencée AMD ne connaît pas les yields donc ses marges donc les prix)

Le 18/10/2016 à 09h 19

il était supporté “downstream” (en patchant le noyau), maintenant les modifications ont été ramenées à la source (upstream), et il est supporté avec le code source standard :)

Le 15/09/2016 à 10h 53

c’est drôle de voir swift bouger, ils suivent un peu l’approche de Go (une seule manière de faire quelque chose) en opposition à C/C++ (n manières de faire la même chose). Les deux ont des avantages

Le 01/09/2016 à 09h 52

Moins bien que Hubic, qui ne pose pas de conditions sur le contenu pour un peu moins cher.. (10TB ‘seulement’ pour 50€/an) Leur client n’est pas fou sous Linux, mais il a le mérite d’exister par aillleurs

Le 25/07/2016 à 09h 53

tar/gz pour installer un programme, c’est quand même le degré zéro de l’élégance, de la robustesse ou de la propreté. Presque aussi mauvais que la méthode Windows d’aller chercher un binaire sur le net packagé avec un installeur en carton. Donc non, je ne me plains pas de mon côté, les soft distribués en tar.gz partent avec un pied dans la tombe, c’est le genre de trucs que “j’installerais” (si un dump dans /opt ou autre peut s’appeler ‘installer’) en me pincant le nez

Le 28/04/2016 à 21h 00

ninja + ccache sur un ramdisk " /> miam miam

@guy02 :
- Intérêt ci-dessus, c’est effectivement super casse-pieds quand tu codes.

• Un autre intérêt, c’est pour de l’intégration continue, quand le code de tout le monde est compilé en permanence à chaque commit (envoi incrémental sur un serveur). Ça permet de détecter les erreurs plus tôt, mais dans ce cas un compilateur 30% plus rapide peut te sauver un serveur (exemple pratique dans ma boîte : je code sous linux, mais notre code doit être cross-platform, windows/mac/linux. Du coup mes commits sont testés à chaque envoi sur les autres plate-formes, et souvent ça casse, alors que c’était invisible sur ma machine (par exemple si j’utilise quelque chose qui n’est pas géré par le compilo microsoft). Les serveurs qui font ça se retrouve à faire des centaines ou milliers de compilations par jour, alors un compilo 50% plus rapide c’est pas mal..
  


• Un dernier intérêt pour la compilation rapide, c’est qu’à un moment ça devient mieux de compiler puis d’exécuter plutôt que d’interprêter directement un truc moisi. On perd un peu au début, mais ensuite c’est tellement plus rapide que ça vaut le coup. C’est ce qui se passe sur le Web avec le JIT (Just-In-Time, compilation à la volée). Si la compilation prend trois plombes, ça ne marche pas
  
  Après chacun ses priorités, tu peux avoir des secteurs d’activités dans lesquels la vitesse du binaire est effectivement le plus important

Le 28/04/2016 à 20h 12

“Performant” pour un compilo, ça peut prendre pas mal de colorations différentes :

• binaire plus ou moins rapide
  


• binaire plus ou moins gros
  


• compilation plus ou moins rapide
  


• support des standards
  
  Le compilateur de Visual Studio (msvc) est super lent (plus que gcc, c’est dire… surtout qu’il ne connait pas ccache par exemple), les binaires de sortie sont à ma connaissance comparables à gcc, mais il est super en retard sur le support des standards (C++11 vient tout juste d’être supporté). Par contre Clang (llvm) met tout le monde d’accord sur la vitesse de compilation, de loin

Le 28/04/2016 à 20h 07

blague ? Vulkan c’est une API C, qui n’a pas grand chose à voir avec C++14 (dommage, ça la rendrait sans doute plus digeste). Des interfaces C++ existent, mais pas grand chose à voir avec GCC dans tous les cas.
 Si c’est le support HSA qui te fait penser à ça, c’est pas trop pour le même but a priori : Vulkan est orienté graphismes et très bas niveau (vise à maximiser l’utilisation GPU pour du rendu), alors que le support HSA est plutôt pour le calcul (ou les tâches lourdes et parallélisables en général, mais pas que graphisme) et vise à remonter l’abstraction, à rendre l’utilisation conjointe CPU/GPU plus facile (par exemple en fusionnant les espaces mémoire CPU/GPU)

Le 28/04/2016 à 20h 03

Toutes depuis 4.8 effectivement il me semble, mais le support par défaut était resté à C++98 (il fallait passer le flag -std=c++11 pour activer). Je ne sais pas quoi en fait (" />), mais quelques cas doivent être gérés différemment par les deux standards, et l’idée était de garder la rétro-compatibilité. 

Le 28/04/2016 à 20h 01

Sans doute pas trop d’intérêt, la compilation c’est une tâche pleine de branches, pas spécialement adaptée aux GPU (SIMD : Same Instruction Multiple Data, autrement dit tout le monde fait la même chose ou presque).

Le 25/04/2016 à 18h 04

Pour info, noir = no IR = pas de filtre IR = sensible IR

Le 08/03/2016 à 09h 40

Uther a écrit :

 Comme je disais plus haut, Rust oblige a réfléchir a ce qu’on fait de la mémoire, mais du coup on a pas plus a s’en inquiéter. Noter les lifetime est il est vrai déroutant au début, mais quand on s’y est fait c’est pas vraiment compliqué. Vu le temps que j’ai passé à débugger des erreurs mémoire louches en C++, je suis convaincu que ça en vaut la peine.
 
Un GC apporte une partie de la sécurité de Rust sans avoir a réfléchir à la mémoire, mais on a un runtime qui fait perdre le coté système du langage : le comportement bas niveau est beaucoup moins prédictible, il y a un impact sur les  performances et l’intégration avec d’autre langages devient hasardeuse voire impossible.
 


Hmm ok, il faudra que j’y consacre un peu plus de temps alors. L’argument de sécurité mémoire ne me convient pas complètement, tous les projets récents en C++ passent par des tests en CI et des vérifications par valgrind ou thread/memory sanitizers par exemple, ce qui doit arriver pas très loin de la sécurité de Rust. Je suis un peu pragmatique là dessus, pourquoi pas un peu plus de sécurité inhérente si ça ne devient pas un calvaire à coder, j’avais un peu testé Rust et le côté calvaire l’avait emporté, sans doute à tort. Une bonne IDE de conseillée ?
 

Le 07/03/2016 à 23h 32

HarmattanBlow a écrit :

La gestion des références en Rust n’est pas plus compliquée que la gestion de la mémoire en C++ : ce sont les mêmes questions qui se posent. La différence est qu’avec Rust la question du cycle de vie est explicitée dans le système de types, ce qui est une excellente chose par rapport au C++, notamment pour la libisilité et la maintenabilité.

Maintenant soit tu as besoin d’un langage où la mémoire est gérée manuellement et dans ce cas il te faut C, C++, Rust, Ada ou autre, soit ce n’est pas le cas et ces langages sont complètement inadaptés et il te faut leur préférer un langage avec ramasse-miettes. Ces derniers conviennent à la très grande majorité des besoins mais pas à tous. Notamment lorsque la latence est problématique voire inacceptable et soumise à une exigence de preuves, ou sur les plateformes matérielles rudimentaires ou en mode kernel.

La comparaison avec le Go est dénuée de sens. Peut-être as-tu été intoxiqué par le marketing de Google qui le présentait comme un “langage système”, ce qui a toujours été une absurdité.


Non, ça ne poutre pas, sauf si tu estimes que les effets secondaires sont un tel problème pour toi qu’il justifie d’ajouter des couches et des couches d’abstraction (complexité accidentelle++++).

En revanche il y a de bonnes idées, comme le fait de laisser le compilo décider de l’ordre d’exécution et que tout soit expression. Mais ne te laisse pas intoxiquer par la propagande Haskell.

Si la question de la complexité t’intéresse, out of the tar pit est l’un des meilleurs papiers jamais écrits dans notre domaine.


Pas besoin de spécifier de temps de vie en c++, c’est plus lisible et plus rapide à programmer, même si ça se fait au prix de la fiabilité. Rust est objectivement plus compliqué de ce point de vue, une simple structure qui stocke des pointeurs est pénible à écrire.
La comparaison avec Go vient de la jeunesse des langages de mon côté, des petits écosystèmes et des usages pas encore bien définis. Je travaille principalement en c++ et python, les deux ont des points forts très clairs, rust n’en est pas là. Les langages n’arrivent pas dans le vide, plein de gens savent faire du python et veulent du plus rapide par exemple, ils vont naturellement considérer java, go, rust ou c++.  En quoi est-ce que Rust est vraiment bon, c’est quoi la “killler app ?” Sûr OK, c’est un peu court. Pas vraiment plus concis que c++11, moins naturellement concurrent que Go, c’est une comparaison qui en vaut une autre, utiliser un “language système” est rarement un prérequis.

Le 07/03/2016 à 15h 09

Langage intéressant IMHO, un peu testé, mais la gestion des références est à s’arracher les cheveux (définir le scope des références à la main est très bizarre par exemple).
 Dommage qu’à vouloir faire du ‘safe’ on arrive à quelque chose moins simple à programmer que du Go par exemple, sans être forcément plus fiable (à moins que quelqu’un puisse me contredire, je n’attends que ca).

Le 27/01/2016 à 08h 57

un programme en espace utilisateur qui bloque le pc, c’est pas forcément normal.. Au delà des critiques sur l’OS, c’est peut être aussi signe que firefox n’y est pour rien

Le 16/12/2015 à 11h 41

je ne dis pas autre chose

Le 16/12/2015 à 10h 03

c’est juste un jeu intéressant à quantité de travail égale. Un truc qui prend deux fois plus de ram pour faire la même chose, c’est un handicap (je ne dis pas que c’est toujours le cas). Par contre c’est clair que l’OS a intérêt à utiliser le max de Ram, par exemple pour cacher les accès disques, donc comparer la conso finale n’a pas trop de sens (pas à travail égal justement)

Le 16/12/2015 à 10h 01

les extensions vont se réinstaller je pense, et pas de soucis pour le 64bits de leur côté, elles ne sont pas en natif mais en script (elles ne vont pas voir la différence 32-64bits pour la plupart)

Le 19/11/2015 à 16h 52

gros +1

Le 19/11/2015 à 10h 01

Pas grand chose pour du c++ pour l’instant, mais j’imagine que ca peut progresser. Ca ressemble beaucoup à Atom, je ne suis pas sûr de comprendre pourquoi est-ce qu’ils ne sont pas repartis de là. Syndrome du ‘Not invented here’ ? Sinon moyennement d’accord avec les commentaires initiaux sur Visual Studio, pas mal mais loin de la perfection à mon avis, surtout dès que tu bosses dans un environnement cross-platform. Certains trucs me manquent en passant de VS à QTCreator (Image Watch par exemple), et réciproquement (Vue d’ensemble des membres d’une classe, profiling valgrind super simple et efficace, support cmakelists, refactoring), ils sont loins d’avoir une IDE parfaite.

Le 16/11/2015 à 13h 41

Ce test là est une bonne blague, ils ont dû sortir une vielle build de GeekBench d’il y a dix ans, avec un compilateur complètement différent. Aucune raison pour que la fpu diffère normalement, mais c’est sûr que si tu testes une compilation avec et sans SIMD par exemple, le score n’est pas le même.
Les tests sont seulement intéressants pour les jeux, là c’est comparable puisque c’est ce que les clients ont, mais c’est pas nouveau (longtemps que phoronix reporte les mêmes chiffres, sauf pour les jeux steam). Pour ces derniers, sans doute un problème de compositing toujours en service dans Steam OS quand le jeu est lancé, parce que sinon les tests de Valve comme ceux de Phoronix montrent toujours des perfs au moins égales sous linux avec Gnome/KDE/.. Ca n’enlève pas les problèmes pour les autres jeux par contre

Le 21/09/2015 à 15h 06

réessaye, pour super meat boy il n’y a rien à faire, ca marche tout seul (idem pour la majorité des jeux j’ai par ailleurs, ca a carrément progressé)

Le 21/09/2015 à 15h 04

Petit rappel à toutes fins utiles, l’enquête hardware de Steam n’est pas vraiment ‘OS agnostique’ personne ne la voit passer sous linux mais elle reste citée comme un indicateur fiable du nombre de personnes impliquées… Les chiffres de ventes sont sans doute plus fiables (mais pas encore publiques avec Steam, on peut se rabattre sur les Humble Bundle pour avoir une meilleure idée), en attendant mieux vaut ne rien dire que d’écrire des bêtises..

Le 19/05/2015 à 15h 46

ErGo_404 a écrit :

Le problème c’est que dans les environnements “contraints” tu n’as pas toujours accès à un compilateur qui suit la dernière norme.

Maintenant si ce que tu dis est vrai, j’aimerais bien avoir un tuto qui couvre directement le C++ “moderne”. J’en suis effectivement resté au C++ “surcouche de C”, en sachant que le C lui même ne me convenait pas.


tu auras à mon sens une bonne  idée des changements avec ca (rapide hein, ca ne couvre pas tout. Ensuite avec la lib standard, tu peux vraiment faire plein de choses proprement

Le 19/05/2015 à 15h 27

HarmattanBlow a écrit :

// Parmi les étudiants ayant assisté à 90% des cours on retient les 20 avec la meilleure note moyenne
var étudiantsSélectionnés = étudiants

   where présenceAuCours > 90     

   order by notes.Average()    

   take 20    

Amuse-toi à écrire ça en C++.

avec des lambdas et la std, c’est trivial

Le 19/05/2015 à 15h 25

HarmattanBlow a écrit :

Beau ?! Le C++ “moderne” ?! Qu’est-ce qu’il ne faut pas entendre ! Désolé mais cette phrase prouve que tu n’as pas fait l’effort d’aller voir ailleurs.

Non une gestion mémoire semi-automatisée avec des annotations de vingt caractères n’est PAS beau. Non ces itérateurs de cinquante caractères dont l’interface empêchent l’écriture d’un beau code ne sont pas beaux. Surtout pas à l’heure où les langages modernes, eux, font tous ça avec zéro caractères et adoptent les substitutions de chaîne, le pattern matching, les types algrébriques, linq et les continuations de listes, l’inférence de types, les types structurels anonymes, etc. Le tout avec des compilations instantanées parce que le modèle de compilation n’a plus à être compilable avec 32ko de mémoire.

Quand j’entends “C++ moderne” j’entends un politicien souffrant d’Alzheimer raconter à ses électeurs qu’on est encore jeune à cent ans. Ben voyons !

Le C++ est une horreur. Un anachronisme encore nécessaire pour un moment, dont les remplaçants tardent à émerger, mais un anachronisme toxique aussi moderne que Cobol. Et beaucoup de grands noms de l’industrie qui codent en C++ en sont convaincus, voire par exemple le célèbre diaporama Sweeney expliquant de quel langage l’industrie du JV aurait besoin aujourd’hui. Et je ne parle même pas du monde des OS où tout le monde s’acharne à bâtir un remplaçant vu l’inadaptation pure et simple d’un langage aussi invérifiable que le C++ à l’écriture d’un OS.

Arrêtez de prendre la défense de ce langage. Scandalisez-vous plutôt qu’en 2015 il n’y ait pas encore de vraie alternative pour la prog bas-niveau / haute performance / portable.

• compilation > super rapide avec clang, sinon un petit ccache est bien efficace. Pas un problème en pratique
   - inférence de type > jette un oeil sur c++ d’après 1995, tu as le droit de te renseigner sur ce que tu commentes. “auto”, c’est pour la poubelle ?
  
  
  
  
  • gestion mémoire ‘semi automatisée’ : la gestion des pointeurs est quand même super simple maintenant, et ca te donne des gains en perfs dont d’autres langages peuvent encore rêver
    
  
  
  • la plupart de tes critiques sur du code trop verbeux concerne les templates. Tu as le droit de ne pas les utiliser..
    
  
  
  • pas allé voir ailleurs ? Sans doute pas assez, j’utilise Python tous les deux jours, j’ai un peu utilisé Java et C#. Je n’ai sans doute pas vu toute la ménagerie pour autant, mais l’utilité de c++ n’est sans doute pas non plus au niveau que tu décris, et je ne suis pas le seul à le penser. 
    
     Maintenant si tu dis que tel ou tel langage super exotique fait ‘évidemment’ beaucoup mieux, reste :
    
  
  
  • à le prouver
    
  
  
  • à avoir un écosystème qui le rend utilisable (l’inconvénient de partir de zéro, on ne gagne pas à tous les coups)
     
  
  

Le 19/05/2015 à 13h 05

J’ai parlé de ‘finalité’ grand public, pour être précis.. Et je maintiens, tout le monde ne peut pas se reposer sur un Unity, ca n’existe pas dans tous les domaines ou ca peut ne pas coller avec le business model. Exemple trivial qui explose tes 1% : l’écrasante majorité des applis iPhone était codée jusqu’il y peu en objective-c, un langage.. compilé. Ca représente du monde, iOS
Autre exemple
 

Le 19/05/2015 à 12h 45

le code c++ serait quasi-exactement le même évidemment..

Le 19/05/2015 à 12h 44

Ah mais je ne suis pas contre Python, au contraire, je l’utilise beaucoup. Comme je le disais plus tôt, il faut de tout pour faire un monde, ca dépend vraiment des applications cherchées.

 @brazomyna : tu y gagnerais quand même à voir ce qu’il se passe à l’extérieur de ton secteur d’activité.. “1% de code réellement contraint par le temps réel”, c’est assez risible pour le coup, je ne sais même pas si ca vaut le coup de réagir.. Je bosse ici, et le C++ est un peu utile par exemple, alors que la finalité est relativement simple / grand public. On est nombreux dans ce cas… (le code était initialement en C#, encore utilisé parfois pour prototyper, la différence de perfs avec C++ doit être dans les 10x et on est contraints par le CPU dans pas mal de scénarios…)

Le 19/05/2015 à 12h 13

ErGo_404 a écrit :

S’il propose les mêmes performances tout en étant plus simple à écrire, la réponse à ta question est évidente.
Le C/C++ sont des plaies, il faut être très rigoureux dans son écriture et il faut faire soi même des choses qu’un bon compilation/machine virtuelle pourraient très bien faire tout seuls. En contrepartie ils n’y a pas mieux pour maîtriser son application au poil et pour les performances.


c++ une plaie ? Qu’est-ce qu’il ne faut pas entendre :) c’est plus vraiment ce qu’on apprenait à l’école, avec des malloc et free dans tous les sens hein. Faut regarder du code moderne, c’est _beau_ ! (ok, si on commence à templater ca pique un peu les yeux)

Le 19/05/2015 à 11h 41

ca dépend complètement de ton application, le fait de se foutre des perfs. Si la valeur ajoutée de ta boîte est dans une fonction cpu-limited ou power-limited, alors les langages tels que le c++ ont tout leur sens. Dire que c’est marginal comme domaine, c’est un peu rapide… Certains domaines n’ont pas de middleware qui font le sale boulot, comme unity, et dans ce cas il n’y a pas le choix, il faut mettre les mains dans le cambouis. Il faut de tout pour faire un monde :)
 

Le 19/05/2015 à 11h 38

ca dépend de la taille de la base de code.. Je ne doute pas que C puisse être super rapide si tu fais tout à la main (par définition, au pire tu prends ce que sort le compilo, au mieux tu améliore, donc globalement tu améliores forcément), mais en pratique tu as des limites en temps de développement et en nombre de personnes impliquées. C’est aussi ce à quoi Rust tente de répondre : faire du code rapide en temps limité, avec une équipe limitée. Les problèmes en temps infini, ce n’est pas super intéressant…
Du coup je suis curieux de ce benchmark : si c’est sur des trucs classiques (algos de tri, ..) alors le c++ peut très bien être aussi optimisé que le c, en y passant du temps (le c est plus ou moins inclus dans le c++, donc par définition tu peux faire aussi rapide) . Si ce n’est pas sur des trucs si classiques que ca, avec une grosse base de code, alors je suis curieux de voir les détails.

Le 19/05/2015 à 10h 52

Il y a quand même une bonne différence de perfs, on n’est pas prêts de passer sur Rust dans ma boîte dans ces conditions… Je suis surpris de voir c++ plus lent que c par contre

Le 19/05/2015 à 10h 49

+1 globalement, mais pas forcément dans les détails..
l’impact du code managé sur les perfs doit être plus ou moins constant en pourcentage, pas du tout en valeur absolue. Si le processeur est tel que tu n’as besoin que d’une fraction de ses perfs, alors effectivement tu te  fous que le code soit managé ou pas. Si tu es dans une situation CPU-limited (super courant sur du mobile par exemple), alors les 10% que te bouffe le code managé fait mal aux fesses. C’est pas pour rien que les moteurs de jeux sont en c++, ou plus globalement les applications temps réel qui touchent à l’image par exemple.

Globalement je pense que ca converge de toute facons :

• le code managé te permet souvent d’appeler des libs binaires pour garder les performances du natif (par exemple un jeu scripté en C# qui appelle une lib de rendu binaire, à la Unity), et dans ce cas l’overhead pratique peut être nul pour ton application, et tu as tous les avantages du managé
   
  


• les langages natifs progressent vers plus d’abstraction (c++¹¹⁄₁₄, Rust donc, avec des threads et des smart pointers en natif), et améliorent leur syntaxe. Par exemple un même code en C++14 et en Java ne sera pas toujours plus long en C++..
  
  La grosse différence est surtout que dans un cas l’optimisation est offline (la compile) ou online (la VM), sachant que même ca peut être un peu flou (genre Android ART et compile AOT)
   
  
   
  
  
  

  brazomyna a écrit :
  

  
  

   Le problème de perf, c’est pas les pointeurs en soit, c’est la notion de “bound checking” qui va avec dans les langages qui proposent une abstraction complète de tout ce qui touche à l’accès mémoire.  Et ce problème de perf en est de moins en moins un:
  

  - l’impact de ce genre de pratique sur la charge CPU est constant
  

  - la puissance dispo des CPU augmente régulièrement
  

  
  

  Donc en proportionnel, sans rien faire de spécial, juste en laissant faire le temps, l’impact relatif devient de plus en plus négligeable sur les perfs globales d’un soft.
  

  
  

  Même principe pour d’autres concepts. D’une façon générale, c’est pas pour rien que le managé est très utilisé aujourd’hui et l’était peu il y a 15 ans: tout simplement parce que l’overhead était important à l’époque, mais devient tellement négligeable qu’il devient de moins en moins justifiable de se passer de tout ce qu’apportent les langages managés.
  

  
  

  Restent un ou deux contre-exemples dans des domaines très spécifiques qui sont l’exception et non la règle ; et surtout les petits débats des Kevin dans la cours de récré. Ceux-là croient encore que la qualité d’un développeur se mesure au caractère bas-niveau du langage qu’il manipule.
  

   
  

   
  

  
  

Le 19/05/2015 à 10h 40

Thanks !

Le 19/05/2015 à 09h 47

intéressé, un peu curieux de voir à quel point c’est rapide et sûr. C++ c’est quand même bien amélioré question rapidité de codage avec les derniers /11 et /14, mais j’imagine bien qu’il est possible de faire mieux. Un peu surpris qu’il soit possible de faire aussi rapide que c++ sans jouer avec les pointeurs, j’attends des benchmarks :) (quelqu’un a testé ?)

Le 08/04/2015 à 08h 12

Pas d’accord, je pense comme @HarmattanBlow que c’est déconnecté de la réalité, l’open source a fait ses preuves sur des gros projets. Dans les technos web même pas la peine d’en parler tellement c’est évident, l’open source est la règle, mais même dans des trucs c++ un peu plus bas niveau, des libs comme boost, thrust ou opencv sont largement utilisées (dans mon champ de compétences en tout cas). Je suis dans une grosse startup (15 personnes), heureusement qu’on utilise de l’open source. La garantie microsoft sur les produits, je ne suis pas sûr que ce soit vraiment un facteur de décision, à part peut être pour quelques vieux DSI restés en 1980
 

Le 07/04/2015 à 15h 35

Hmm, j’avais regardé Rust il y a quelques temps, c’est bien le truc qui n’est toujours pas fini ? Je ne dis pas qu’il n’y a pas mieux que c++11, mais il a le mérite d’exister :) Sinon le threading a l’air assez facile, mais le problème c’est aussi le contenu : tu fais quoi avec Rust ? Il existe des libs ? C’est aussi le souci avec ces nouveaux languages, sympa mais c’est rare que tu refasses tout de zéro, tu prends aussi des libs existantes dans la vraie vie. Plus facile d’innover aussi quand tu te fous de la compatibilité ascendante..

Le 07/04/2015 à 15h 11

ok pour hpx sinon, je ne connaissais pas, mais c’est une lib ? je vais regarder ca, merci pour l’info, on dirait du boost en plus digeste