donc de compiler automatiquement le bon code assembleur, que ce soit avec des instructions NEON, SSE, AVX, etc. par contre il faut qu'à la compilation, je lui dise que pour tel environnement (ex : windows sur smartphone) il prenne les instructions NEON, pour d'autres (windows sur pc), il prenne les SSE, etc. quand Je n'ai pas les idées très claires là-dessus mais c'est l'idée...
À la compilation, tu peux pas configurer ce que le binaire fera à l'exécution. La seule chose que tu peux faire, c'est compiler plusieurs versions de ton logiciel, et installer chaque version sur la bonne machine. Chaque binaire aura un code machine différent (soit parce que le code source est différent et sélectionné par des commandes pré-processeur, soit parce que le compilateur va générer un code machine différent pour le même code source).
Si tu veux un seul binaire commun qui fait diverses choses selon l'architecture précises, on revient sur des librairies d'abstraction, comme OpenCL et compagnie avec une logique dans le code. Faut pas que tu mélanges les deux. C'est complémentaire.
Et de manière général, il n'y a pas de magie. Le multi-tâche (threading, multi-proc, etc.), c'est dans le code. Ça peut être plus ou moins encapsulés dans des librairies haut niveau, mais ça reste au dév de créer la logique. Une option du compilateur pour créer du code parallèle à partir de code linéaire, ça n'existe pas.
Donc ce genre de choses n'a vraiment rien à voir avec la compilation (bien sûr y a des options de compilation en rapport avec le multi-thread, mais c'est pas pour transformer magiquement ton code), et donc avec crossroad.
La seule chose qui a un rapport, c'est quand tu parles de générer des sets d'instructions plus précis que juste x86 32/64-bit. Comme dit plus haut, fais un man gcc. Et fais une recherche avec tes mots clés. Je trouve des trucs pour NEON (-mfpu=neon), plein de mentions de SSE (plein d'options, à toi de choisir lesquelles tu veux), pareil pour AVX. Ça oui, tu peux rajouter ces options dans ton CFLAGS (donc probablement aussi fonctionnel avec crossroad).
Et encore même pour ça, ça ne signifie pas que le code final va soudainement être parfaitement optimisé. Le compilateur va tenter de générer des codes spécifiques plus performants s'il détecte des schémas connus. Et pour ça les compilos modernes sont très forts et peuvent être plus performants que la plupart des dévs. Mais une machine reste moins intelligente qu'un humain malin. Et il est donc possible que tu puisses optimiser davantage avec du code assembleur (comme il est aussi possible que tu fasses pire que l'optimisation du compilo).
Pour tout le reste, c'est à toi de bosser et de modifier ton code. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cross compiler vers du matériel différent ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 4.
À la compilation, tu peux pas configurer ce que le binaire fera à l'exécution. La seule chose que tu peux faire, c'est compiler plusieurs versions de ton logiciel, et installer chaque version sur la bonne machine. Chaque binaire aura un code machine différent (soit parce que le code source est différent et sélectionné par des commandes pré-processeur, soit parce que le compilateur va générer un code machine différent pour le même code source).
Si tu veux un seul binaire commun qui fait diverses choses selon l'architecture précises, on revient sur des librairies d'abstraction, comme OpenCL et compagnie avec une logique dans le code. Faut pas que tu mélanges les deux. C'est complémentaire.
Et de manière général, il n'y a pas de magie. Le multi-tâche (threading, multi-proc, etc.), c'est dans le code. Ça peut être plus ou moins encapsulés dans des librairies haut niveau, mais ça reste au dév de créer la logique. Une option du compilateur pour créer du code parallèle à partir de code linéaire, ça n'existe pas.
Donc ce genre de choses n'a vraiment rien à voir avec la compilation (bien sûr y a des options de compilation en rapport avec le multi-thread, mais c'est pas pour transformer magiquement ton code), et donc avec crossroad.
La seule chose qui a un rapport, c'est quand tu parles de générer des sets d'instructions plus précis que juste x86 32/64-bit. Comme dit plus haut, fais un
man gcc. Et fais une recherche avec tes mots clés. Je trouve des trucs pour NEON (-mfpu=neon), plein de mentions de SSE (plein d'options, à toi de choisir lesquelles tu veux), pareil pour AVX. Ça oui, tu peux rajouter ces options dans ton CFLAGS (donc probablement aussi fonctionnel avec crossroad).Et encore même pour ça, ça ne signifie pas que le code final va soudainement être parfaitement optimisé. Le compilateur va tenter de générer des codes spécifiques plus performants s'il détecte des schémas connus. Et pour ça les compilos modernes sont très forts et peuvent être plus performants que la plupart des dévs. Mais une machine reste moins intelligente qu'un humain malin. Et il est donc possible que tu puisses optimiser davantage avec du code assembleur (comme il est aussi possible que tu fasses pire que l'optimisation du compilo).
Pour tout le reste, c'est à toi de bosser et de modifier ton code. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]