Discussion :

[bacelar]

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.

(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++ ?

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

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.

[Bousk]

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

[RPGamer]

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

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

[Pyramidev]

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 ?

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

[Ehonn]

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.

[gl]

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

[Ehonn]

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

[Aiekick]

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.


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 ?

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.

[Aiekick]

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.

[koala01]

Salut,

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

[Bousk]

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