Le topic de la programmation, string, chaînes, cuir et compagnie

**newbie06** · 29/09/2013, 11h36

Je me disais qu'il y a un autre compilo sous Linux qui devrait être pas mal niveau support C++: icc. Je ne sais pas trop où ils en sont du support des features C++11, mais au niveau front-end ça devrait être de bonne qualité.

**Tomaka17** · 29/09/2013, 11h56

M'étonnerait que ce soit gratuit (ni abordable d'ailleurs) même sous Linux.

**newbie06** · 29/09/2013, 12h48

Envoyé par Tomaka17

M'étonnerait que ce soit gratuit (ni abordable d'ailleurs) même sous Linux.

C'est gratuit sous certaines conditions, sinon je ne l'aurais pas proposé.

**DeadFish** · 30/09/2013, 18h31

Vous conseillez quoi comme IDE pour un noobzor puissance 42 ? C'est pour faire du C, du Java (pas taper) et du langage d'assemblage ARM sur une machine x86. Jusqu'ici je faisais tout à la main (éditeur de texte + console), ça m'allait très bien mais il parait que je gagnerais à utiliser des outils plus performants (j'ai failli pleurer la première fois qu'on m'a parlé de debugger). Tout le monde n'a qu'Eclipse à la bouche, mais je trouve que c'est une usine à gaz en plus de ne pas être très ergonomique (sûrement une question d'habitude). NetBeans peut-être ?

**weedkiller** · 30/09/2013, 19h54

Bon je commence : emacs.

. (surtout si tu veux faire de l'assembleur

)

**Awake** · 30/09/2013, 19h58

En léger il y a SublimeText de vraiment bien. Pas certain que se soit l'IDE idéal (

) pour tes besoins par contre.

**Tomaka17** · 30/09/2013, 20h11

Personnellement quand je code en C++ j'écris le code sous SublimeText 2 et je fais des alt+tab vers Visual C++ (qui est lui aussi un IDE) pour compiler et débugger.

À mon avis tu peux faire pareil avec Eclipse, c'est à dire écrire le code avec un éditeur que t'aimes bien et utiliser eclipse juste pour débugger.

**Møgluglu** · 30/09/2013, 21h12

Sinon, si l'éditeur de texte et le terminal te conviennent, pourquoi changer ?

**Badger** · 30/09/2013, 22h03

y'avait code::blocks aussi, je ne sais pas ce que c'est devenu.

**war-p** · 01/10/2013, 08h39

Code block est pas mal pour les pauvres... Sinon VS, il y a pas mieux mais c'est pas sur que ça soit adapté.

**flo900** · 01/10/2013, 09h40

Envoyé par war-p

Code block est pas mal pour les pauvres... Sinon VS, il y a pas mieux mais c'est pas sur que ça soit adapté.

Ah mais si c'est juste une question d'argent, y'a pas ~~plus cher~~ mieux qu'Xcode.

**Patate** · 01/10/2013, 19h27

J'utilise VS Express pour C# et C++ et c'est vraiment pas mal !

**Tomaka17** · 01/10/2013, 22h35

Herb Sutter veut passer std::async en deprecated

**rOut** · 01/10/2013, 23h56

Ouais, ils se rendent compte qu'ils ont un peu foiré la standardisation de la concurrence. Les threads c'était bien il y a 10 ans, maintenant c'est les tâches qu'il nous faut.

D'ailleurs je me demandais s'il n'y avait pas une similarité à faire tourner un paquet de threads, orchestrés sur un ensemble de cpus par le systèmes, et faire tourner un paquet de tâches sur une thread pool dans une application. Mis à part que l'on contrôle l'orchestration, est-ce que ça vaut vraiment le coup d'ajouter un layer d'abstraction supplémentaire ?

**Tomaka17** · 02/10/2013, 07h42

J'suis pas spécialiste du sujet, mais je pense que si tu fais pop 10 thread pour 10 tâches, vu la quantité de locking qu'il faudra, ce sera pas très efficace.
Le max de perf sera de toute façon atteint avec un thread par core, donc pourquoi en avoir plus ?

Et je crois qu'ils ont prévu une classe en C++14 pour faire une liste de tâches à exécuter dans un thread.

**moimadmax** · 02/10/2013, 07h51

Je suis pas expert mais du point de vu du développeur, c'est plus simple de faire un thread par tâche, que d'essayer de les dispatcher dans 4 threads en fonction de leur charge. Après ça va être le rôle de l'Os de les dispatcher sur le CPU en fonction de leur charge et des core qu'il a sous le coude.

**rOut** · 02/10/2013, 08h39

Envoyé par Tomaka17

J'suis pas spécialiste du sujet, mais je pense que si tu fais pop 10 thread pour 10 tâches, vu la quantité de locking qu'il faudra, ce sera pas très efficace.
Le max de perf sera de toute façon atteint avec un thread par core, donc pourquoi en avoir plus ?

Et je crois qu'ils ont prévu une classe en C++14 pour faire une liste de tâches à exécuter dans un thread.

Tu n'as pas plus ou moins de locking à faire dans un thread que dans une tâche, si ton thread représente la tâche unitaire à exécuter. Le max de perf sera atteint lorsqu'il y a exactement autant d'éléments de travail à exécuter que d'éxécuteurs. Que ton élément de travail soit un thread ou soit une tâche et que ton exécuteur soit un CPU ou un thread dans une pool.

L'avantage que je vois d'utiliser un thread pour une tâche est qu'il y a déjà une notion de switch de thread, qu'un thread en sleep ne va pas empêcher les autres de tourner (alors que si tu fais sleep dans une tâche, tu niques le thread sur lequel tu tournais), de même qu'un wait I/O. Le système est déjà programmé pour orchestrer les threads de manière à optimiser le travail exécuté et réveiller ceux qui peuvent tourner quand ils le peuvent. Avec les tâches il faut réimplémenter tout ça, de manière plus ou moins facile.

Après, bien entendu, il peut être question de granularité et d'enchainement, mais question granularité c'est une discipline du programmeur, et question enchainement ça peut s'implémenter avec les threads également.

Envoyé par moimadmax

Je suis pas expert mais du point de vu du développeur, c'est plus simple de faire un thread par tâche, que d'essayer de les dispatcher dans 4 threads en fonction de leur charge. Après ça va être le rôle de l'Os de les dispatcher sur le CPU en fonction de leur charge et des core qu'il a sous le coude.

Voilà, le problème du dispatching des choses à exécuté est déjà géré, de manière assez optimale par l'OS. Pourquoi se faire chier à le refaire en user-space ?

La seule différence que je vois vraiment est celle du cout des threads (cout de création et de switch). Ou alors est-ce plutôt que les tâches force plus naturellement à utiliser une granularité fine (du fait de l'impossibilité de faire des sleep ou de switcher vers une autre tâche au milieu de l'exécution) et imposent donc une discipline que n'imposent pas les threads ?

**Møgluglu** · 02/10/2013, 10h11

Envoyé par rOut

Voilà, le problème du dispatching des choses à exécuté est déjà géré, de manière assez optimale par l'OS. Pourquoi se faire chier à le refaire en user-space ?

Parce que le scheduling de l'OS n'est pas optimal du tout à partir du moment où tu as plus d'un thread actif par CPU logique. Les threads vont passer leur temps à se pourrir leurs caches entre eux. Si tu veux écrouler un système, lance 1000 threads calculant chacun un gros produit de matrices pour voir.

C'est parce que l'OS n'a aucune idée de la synchronisation entre les threads et de leur priorité respective. Donc il va juste les lancer dès qu'ils sont créés et les faire progresser à peu près à la même vitesse en context-switchant régulièrement.

Avec des tâches, les dépendances sont explicites et la synchro est automatique plutôt que d'être gérée à la main. Le runtime a les infos pour dérouler le graphe des tâches, lancer les tâches et les mapper sur le pool de n threads correspondant aux n CPU dispo. Comme il sait que le tâches ne vont jamais faire des putain d'attente actives, il peut lancer les tâches une par une ou n par n et attendre qu'elles finissent pour lancer les suivantes sans risque de deadlock.
Ou : le runtime s'occupe du dispatching des tâches, l'OS s'occupe du scheduling.

Concernant C++, c'est orthogonal. Les threads sont bas niveau, les tâches sont haut niveau, ce sont des outils différents pour des situations différentes. Selon la philosophie de C++ qui consiste à donner au programmeur tout ce dont il a besoin pour se tirer dans le pied, les deux ont un intérêt.

**rOut** · 02/10/2013, 10h24

Envoyé par Møgluglu

Parce que le scheduling de l'OS n'est pas optimal du tout à partir du moment où tu as plus d'un thread actif par CPU logique. Les threads vont passer leur temps à se pourrir leurs caches entre eux. Si tu veux écrouler un système, lance 1000 threads calculant chacun un gros produit de matrices pour voir.

C'est parce que l'OS n'a aucune idée de la synchronisation entre les threads et de leur priorité respective. Donc il va juste les lancer dès qu'ils sont créés et les faire progresser à peu près à la même vitesse en context-switchant régulièrement.

Avec des tâches, les dépendances sont explicites et la synchro est automatique plutôt que d'être gérée à la main. Le runtime a les infos pour dérouler le graphe des tâches, lancer les tâches et les mapper sur le pool de n threads correspondant aux n CPU dispo. Comme il sait que le tâches ne vont jamais faire des putain d'attente actives, il peut lancer les tâches une par une ou n par n et attendre qu'elles finissent pour lancer les suivantes sans risque de deadlock.
Ou : le runtime s'occupe du dispatching des tâches, l'OS s'occupe du scheduling.

Concernant C++, c'est orthogonal. Les threads sont bas niveau, les tâches sont haut niveau, ce sont des outils différents pour des situations différentes. Selon la philosophie de C++ qui consiste à donner au programmeur tout ce dont il a besoin pour se tirer dans le pied, les deux ont un intérêt.

Ca me va.

**Blitz** · 03/10/2013, 09h59

EDIT: nan rien, juste une erreur bête.

'*' à la place de '%' dans une requête ADO.NET sur une base ACCESS

**Tomaka17** · 04/10/2013, 18h26

Bon, j'ai un petit problème : very sleepy (le profiler) plante lorsque j'exécute mon programme.

Du coup est-ce que vous connaîtriez par hasard de bons profilers very-sleepy-like ? C'est à dire gratuit, qui ne nécessite pas de modifier mon code source (ou alors cross-platform), qui fonctionne avec les CPUs Intel (c'est à dire pas les trucs de chez AMD), et qui de préférence ne nécessite pas d'installer KDE pour voir les résultats (comme c'est le cas pour valgrind et le truc de google).

Je cherche pas compliqué, juste un petit logiciel qui m'indiquerait pourquoi est-ce que ça rame.

**Tomaka17** · 04/10/2013, 20h32

Bon ben AMD CodeXL marche pas mal, d'autant qu'il permet de débugger OpenGL/OpenCL aussi.

**rOut** · 05/10/2013, 17h41

Eclipse C++ permet de profiler/visualiser avec valgrind.

**newbie06** · 06/10/2013, 13h30

On va dire que j'insiste, mais les outils Intel sont gratuits sous certaines conditions et vtune est excellent a ce qu'il parait.

Et je vais meme mettre un lien : http://software.intel.com/en-us/non-...re-development

**Møgluglu** · 06/10/2013, 13h48

Ouais enfin icc c'est pas la panacée non plus. Il génère jamais le code que je veux, son analyse d'aliasing se foire toujours même sur des cas ultra-simples, et l'allocateur de registres se croît encore dans les années 80 quand il y avait 6 registres utilisables.
Heureusement sur le MIC j'ai trouvé la parade, je change les types double en long double, et je gagne 20% de perf sur le code flottant scalaire. (Bah ouais, ça permet d'éviter des copies et conversions intermédiaires à chaque fois que tu appelles une fonction de la libm, qui semble-t-il vient en version x87 optimisée Pentium avec ABI i386.)

Vtune j'ai jamais essayé.

Edit: je suis de mauvaise foi pour l'allocateur de registres. Il fait ce qu'il peut le pauvre, mais vu que l'ABI Intel a défini tous les registres zmm et k en caller-save, au moindre appel de fonction il faut sauvegarder tout le contexte en mémoire puis le restaurer...

**deathdigger** · 08/10/2013, 11h51

Petite question sérialisation en C# :

Faut que je sérialise une liste de cette façon :
EDIT : Graaaah faut que je reformule.

Donc :
J'ai un fichier à fournir comme ça :

Code:

<principal>
<blabla></blabla>

<toto>
<tata></tata>
<tutu></tutu>
</toto>

<toto>
<tata></tata>
<tutu></tutu>
</toto>

</principal>

J'ai créé un objet toto qui contient un tata et un tutu, par contre, forcément quand je sérialise cette liste d'objet, j'obtiens :

Code:

<principal>
<blabla></blabla>

<MaListe>
<toto>
<tata></tata>
<tutu></tutu>
</toto>

<toto>
<tata></tata>
<tutu></tutu>
</toto>
</MaListe>

</principal>

Comment je fais pour sérialiser une liste sans que le nœud de celle-ci apparaisse ?

Edit 2 : C'est bon j'ai trouvé

En fait, même si c'est une liste d'items, on peut faire un [XmlElement("dfsf")] dessus, il va créer autant de <dfsf></dfsf> que nécessaire.

**war-p** · 08/10/2013, 20h28

T'utilise quoi comme api? Mais sinon, ouais, t'auras toujours un nœud principal.

**deathdigger** · 08/10/2013, 21h40

?
J'utilise l'XmlSerializer classique de C#, c'était juste pour faire un XML à destination de l'URSSAF (pour les DUE/DPAE).
Au final, leur xml est valide mais bizarrement fait.

**war-p** · 08/10/2013, 22h43

Oui, le xml sera toujours valide si tu utilises les api standards.

Spoiler Alert!

**rOut** · 08/10/2013, 23h31

Tiens, FPComplete sort un IDE en ligne pour faire du Haskell : https://www.fpcomplete.com/business/...onal-overview/
Il y a un trial gratuit et sinon c'est 9.99$ par mois.

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages