La spécification du C++17 n'intègrera pas les concepts

Merci @Pyramidev pour cette remarque sur les VLAs.

"alloca" devrait faire aussi bien, non ?
http://man7.org/linux/man-pages/man3/alloca.3.html

Si c'est le cas, on a donc les VLA comme syntaxical sugar du C99.

Citation:

---

(parmi celui que j'ai donné provenant de chez Intel)

---

Quelles optimisations possibles en C ne l'est pas en C++ ?

On en revient toujours au même, comment pouvez-vous taxer le C++ comme un gouffre de performance quand tout ce qui est possible en C l'ai aussi en C++ ? :weird:

Citation:

---

Premièrement c'est faux, la libc =/= libc++ =/= libstdc++

---

Ça c'est sous le pingouin, pas chez le papillon. Et encore, je suis pas un spécialiste de la banquise mais d'autres pourront vous donnez bien des moyen pour faire des choses sans même aucune de ces librairies (comme en C d'ailleur).

Citation:

---

un C++ enthusiast comme toi devrait le saluer.

---

Un développeur système sait que les API d'OS sont majoritairement des API C qui oblige à maitriser le C++, donc le malloc, qui fait partie du C++ aussi bien que du C.

Je ne dis pas que le C++ est l'Alpha et l’Oméga des langages, mais le C n'a pas un pouvoir magique non plus.

Si le new ne fait plus rentrer les performances dans les clous, un simple #define pour utiliser une mécanique adaptée, comme un malloc, mais quitte à faire de l'optimisation on va se laisser pousser la barbe et faire un truc aux petits ognons avec le temps gagné lors de la conception/implémentation du reste du projet.

Le C n'est pas magique, et j'ai l'impression de voir beaucoup de charlatans.

malloc est tellement différent de new qu'il peut être utilisé pour le surcharger et qu'il est utilisé en interne dans certaines implémentations :roll:
http://en.cppreference.com/w/cpp/mem...w/operator_new
http://stackoverflow.com/questions/2...oc-free#240308
En fait la seule différence c'est vraiment l'appel au constructeur de la part de new après l'allocation. Donc si t'as des constructeurs triviaux/POD (ce qui est le cas en C où tu ne peux pas avoir autre chose), ça change strictement rien. Si t'as un constructeur non trivial, ben tu le payes. :calim2:

Citation:

---

Quelles optimisations possibles en C ne l'est pas en C++ ?

---

Pourquoi est-ce que je devrais encore perdre mon temps à répondre à des gens qui ne prennent même pas la peine de lire les liens qu'on leur donnent? L'article montre qu'on peut réaliser des optimisations en analyser le code machine généré et en l'améliorant. A aucun moment il n'est question de C ou de C++.

Citation:

---

En fait la seule différence c'est vraiment l'appel au constructeur de la part de new après l'allocation.

---

C'est une bonne raison pour préférer new (avec l'exception behavior).

Citation:

---

Envoyé par bacelar

Moi, la seule chose qui n'est pas possible en C++ (officiellement en plus) mais en possible en C, c'est le VLA.
Et on est d'accord que le VLA, c'est juste du syntaxical sugar et que cela ne change rien aux "performances", non ?

---

Citation:

---

Envoyé par bacelar

"alloca" devrait faire aussi bien, non ?
http://man7.org/linux/man-pages/man3/alloca.3.html

Si c'est le cas, on a donc les VLA comme syntaxical sugar du C99.

---

En C, par rapport à alloca(), oui, les VLA sont du sucre syntaxique.
Mais alloca() n'est standard ni en C, ni en C++, contrairement aux VLA qui sont standards en C99 (mais pas en C++).

Citation:

---

Envoyé par Pyramidev

VLA qui sont standards en C99 (mais pas en C++).

---

Les VLA sont biens dans la norme de C99 mais ils sont optionnels en C11.

Citation:

---

Envoyé par Ehonn

Les VLA sont biens dans la norme de C99 mais ils sont optionnels.

---

Pour être précis, ils sont devenus optionnels en C11, mais en C99 leur support n'était pas optionnel (même si tout le monde ne les a pas implémentés, d'où le passage en optionnel).

Merci pour l'info, j'édite mon message.

Citation:

---

Envoyé par Bousk

Mué enfin, je connais personne de sensé qui n'essaye pas de limiter un peu chacun de ces aspects. Même si "on s'en moque" du cpu ou de la ram, on va pas s'éclater à en utiliser plus que nécessaire. :roll:


Et t'as une quelconque étude, article ou quoi qui prouve que c'est bien/mieux ?
Par exemple, coder en assembleur certaines parties, à part pour montrer qu'on connait l'assembleur et qu'on fait du code non/dificilement portable, y'a un intérêt pour les perfs ? Parce que bon on est en 2016 et les compilos sont désormais bien puissants hein.
De même, allouer la mémoire en C ? Parce que tu crois vraiment qu'un malloc fera mieux qu'un new ? Et quoi de mieux au juste ? :calim2:

---

Par exemple fait un comparatif. utilise opencv avec et sans la librairie de primitive intel ( ou toutes les op matricielles sont codé en asm) tu verras la différence, c'est flagrant, comme d'un coup on un meilleur fps qui permet de faire de la reconnaissance poussé en temps reel.

j'ai jamais parlé d'appeler des fonctions c comme malloc en c++, je dis juste que j'ai des source en c qui sont compilé en c pour des structure de donnée ou des algorithme particulier et prévu pour être le plus performant possible en logique et en implémentation, et qui sont donc compilé via le compilateur c et intégrés dans un prog qui est écrit globalement en c++.

Ceci étant si c'est utile pour la mémoire ou le cpu, certaine méthode qui reviennent souvent selon ce que le profileur me dira sont codés en asm.

On sera toujours meilleur que le compilateur sur un besoin précis. le compilateur assemble des pattern asm pour des fonction c++, c'est de la compilation générique un peu, alors que nous on peut aller a l'essentiel de notre besoin en minimisant les call et les jump et les registers uses.

évidemment quand on code en asm, il faut avoir en tète les plateformes et leur spécificités.

j'en ai pas parlé parce que ça me semblait évident.

Salut,

Citation:

---

Envoyé par Aiekick

On sera toujours meilleur que le compilateur sur un besoin précis. le compilateur assemble des pattern asm pour des fonction c++, c'est de la compilation générique un peu, alors que nous on peut aller a l'essentiel de notre besoin en minimisant les call et les jump et les registers uses.

---

Ca, ca reste encore à voir...

Les compilateurs disposent d'heuristiques de plus en plus précises pour les optimisations à effectuer. Qu'il s'agisse d'optimiser la taille de l'exécutable ou la vitesse (ou de trouver le meilleur "juste milieu").

Je ne dis pas que nous ne pourrons surement pas trouver certaines optimisations, à des points très particuliers, que les compilateurs auront peut être évitées (parce que les heuristiques étaient peut être justement "antagonistes" sur ce point particulier), mais je dis que, s'il en reste effectivement (et, à titre personnel, je serais sans doute bien en peine de trouver ces points particuliers), le gain réellement observé a de très fortes chances d'être purement anecdotique.

D'abord parce que nous en arrivons réellement à des micro optimisations, ensuite qu'il ne suffit pas forcément de se dire "je vais remplacer telle instruction par telle autre : l'une prend X cycles et l'autre en prend Y de moins". En effet, il n'est pas impossible que les Y "cycles de plus" soient très largement amortis par un "truc" ou un autre qui survient quelques instructions plus tôt (ou plus tard) et qui rend impossible l'utilisation de l'instruction "de remplacement".

Ceci dit, je te comprends : il est toujours utile de gagner quelques cycles d'horloge "partout où c'est possible"... Mais si c'est pour ne les gagner qu'une fois "de temps en temps", il est très largement préférable de s'intéresser à des points clairement identifiés comme susceptibles de poser problème.

Et, de toutes manières, avant d'en arriver à accepter ces micro optimisations (et, de manière générale, avant d'accepter d'avoir de l'asm inliné dans mon code, qu'il soit C ou C++), je crois sincèrement que je préférerai m'assurer que mes algorithmes soient, effectivement, les plus corrects possibles. Et, dans les cas les plus douteux, je commencerai sans doute par essayer de limiter les caches misses ;)

https://blogs.msdn.microsoft.com/vcb...ode-optimizer/