Certes C# est un bon langage, aucun doute là-dessus. Mais bon on ne peut pas tout apprendre : Java ou C# il faut choisir son camp (même s'il y a de nombreuses similitudes , ils copient leurs avancées mutuelles). Cependant, la "légende urbaine" veut que C++ reste plus performant que n'importe quel autre langage. Je vais me mettre à jour sur le sujet, du reste, vérifier ce qu'il en est à l'heure actuelle.
Pour donner un exemple : python c’est un peu la voiture de monsieur tout le monde : facile à conduire et accessible au plus grand nombre mais pas très nerveuse en terme de performance
Le C/C++ c’est un peu le roadster ou la Porsche : n’importe qui peut en acheter une mais ça demande beaucoup plus de finesse dans le pilotage car on peut vite partir dans le décors.
Le C/C++ c’est un peu le roadster ou la Porsche : n’importe qui peut en acheter une mais ça demande beaucoup plus de finesse dans le pilotage car on peut vite partir dans le décors.
En terme de rapidité d'exécution sans aucun doute.BeerIsDead a écrit :la "légende urbaine" veut que C++ reste plus performant que n'importe quel autre langage.
Le gros point faible que je lui trouve : c'est un fourre-tout de tout et n'importe quoi (en langage savant : il est multi-paradigme lol).
Les dernières évolutions dans le niveau d'abstraction sont assez complexes.
Du coup, c'est parfois difficile de comprendre du code écrit par un autre que soit.
Jim pour la rapidité d'exécution. Pas de raison que ça ait changé après tout => Java / C# sont compilés en langage intermédiaire alors que C++ est directement compilé en langage natif.
On est ok pour ce qui est la lisibilité du code (donc la productivité à terme) => Java et C# (entre autres), lorsqu'ils sont bien programmés, sont très "expressifs", donc une équipe peut facilement reprendre un projet, ainsi que soi-même quand on revient sur le code quelques mois / années plus tard.
Cependant sur ce thème Bernardino me disait justement qu'il y avait eu de grandes avancées côté C++. Mais je ne pourrais pas te donner les détails, je n'ai pas noté à l'époque, et je ne me suis pas penché sur ce langage depuis longtemps.
On est ok pour ce qui est la lisibilité du code (donc la productivité à terme) => Java et C# (entre autres), lorsqu'ils sont bien programmés, sont très "expressifs", donc une équipe peut facilement reprendre un projet, ainsi que soi-même quand on revient sur le code quelques mois / années plus tard.
Cependant sur ce thème Bernardino me disait justement qu'il y avait eu de grandes avancées côté C++. Mais je ne pourrais pas te donner les détails, je n'ai pas noté à l'époque, et je ne me suis pas penché sur ce langage depuis longtemps.
Exemple de benchmark :
Source :
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html
Ceci est juste un exemple : sur le site, il y a plusieurs algorithmes différents qui donnent des résultats différents suivant le langage et qui bousculent ce classement.
@BeerIsDead:
Le C# est d'abord compilé en langage intermédiaire qui est ensuite compilé en langage natif.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/regexredux.html
Ceci est juste un exemple : sur le site, il y a plusieurs algorithmes différents qui donnent des résultats différents suivant le langage et qui bousculent ce classement.
@BeerIsDead:
Le C# est d'abord compilé en langage intermédiaire qui est ensuite compilé en langage natif.
Sympa ce site, je ne connaissais pas ! Des benchmarks pour différents algorithmes ok.
Oui le Java / C# sont compilés en langage intermédiaire, et c'est seulement à l'exécution qu'ils sont compilés en langage natif ? Donc moins performant, à priori, que du C / C++ compilé directement en natif avant l'exécution
Oui le Java / C# sont compilés en langage intermédiaire, et c'est seulement à l'exécution qu'ils sont compilés en langage natif ? Donc moins performant, à priori, que du C / C++ compilé directement en natif avant l'exécution
Pour ce qui est de la rapidité du C et de ses rejetons, voici une autre légende urbaine : un code bien écrit en C sera généralement plus rapide qu'un code bien écrit en assembleur. La raison ? Les compilateurs C font un énorme boulot d'optimisation pour la meilleure exécution.
La compilation C c'est un peu vaudou par moment. Ca marche mieux si tu as trempé ton CPU dans le sang d'une chèvre fraîchement décapitée...
La compilation C c'est un peu vaudou par moment. Ca marche mieux si tu as trempé ton CPU dans le sang d'une chèvre fraîchement décapitée...
je pense que tu as raison pour le caractère "aléatoire" des compilateurs.
J'ai bossé quelques temps sur du C embarqué => le développeur initial avait tout écrit en assembleur, puis a petit à petit traduit en C ANSI (pour des raisons de lisibilité...). Il a tout de même choisi de garder certaines parties "sensibles" (en temps d'exécution) en assembleur.
Disons que si on maîtrise bien son sujet, je pense qu'on peut faire mieux en assembleur que n'importe quel compilateur côté optimisations. (je n'y connais rien assembleur, je m'occupais du C, mais c'est ce que j'en ai compris)
Malgré tout ça, ça n'empêche que même un compilateur C++ qui optimiserait "mal" le code, débouchera sur un logiciel plus performant que nos compères en langage intermédiaire, à mon avis.
J'ai bossé quelques temps sur du C embarqué => le développeur initial avait tout écrit en assembleur, puis a petit à petit traduit en C ANSI (pour des raisons de lisibilité...). Il a tout de même choisi de garder certaines parties "sensibles" (en temps d'exécution) en assembleur.
Disons que si on maîtrise bien son sujet, je pense qu'on peut faire mieux en assembleur que n'importe quel compilateur côté optimisations. (je n'y connais rien assembleur, je m'occupais du C, mais c'est ce que j'en ai compris)
Malgré tout ça, ça n'empêche que même un compilateur C++ qui optimiserait "mal" le code, débouchera sur un logiciel plus performant que nos compères en langage intermédiaire, à mon avis.
Super intéressant le lien de Takapoto ! On voit bien que le même code compilé sur différents compilateurs donne des différences d'exécutions énormes (en durée d'exécution, d'utilisation de mémoire, ou des CPUs)
Je rejoins Jim en ce qui concerne l'assembleur et son optimisation par le C.
J'ai travaillé en équipe sur des systèmes de guidage de missiles (en assembleur) et il fallait sans cesse réécrire le code de certains car il était très loin des performances exigées. Quand on a pu enfin travailler en C, les résultats étaient beaucoup plus lissés.
J'ai travaillé en équipe sur des systèmes de guidage de missiles (en assembleur) et il fallait sans cesse réécrire le code de certains car il était très loin des performances exigées. Quand on a pu enfin travailler en C, les résultats étaient beaucoup plus lissés.
Spoiler:
Puisqu'on parle de guidage de missile et de conseil pour les futurs développeurs... Taka, j'imagine que tu connais l'histoire suivante
Pour nous autres, c'est un sinistre rappel.
Tout développeur s'est, un jour ou l'autre, arraché les cheveux à cause des arrondis de calculs en virgule flottante. Parfois c'est plus grave : quand un missile Patriot rate son interception de Scud pour une toute petite erreur d'arrondi. Toute petite erreur, mais qui reproduite un grand nombre de fois, crée un décalage de 0.34 seconde au lancement. Et fait fait 28 morts.
http://www-users.math.umn.edu/~arnold//disasters/patriot.html
Pour nous autres, c'est un sinistre rappel.
Tout développeur s'est, un jour ou l'autre, arraché les cheveux à cause des arrondis de calculs en virgule flottante. Parfois c'est plus grave : quand un missile Patriot rate son interception de Scud pour une toute petite erreur d'arrondi. Toute petite erreur, mais qui reproduite un grand nombre de fois, crée un décalage de 0.34 seconde au lancement. Et fait fait 28 morts.
http://www-users.math.umn.edu/~arnold//disasters/patriot.html
Spoiler:
Je ne la connaissais pas, Merci !
J'ai une autre histoire du même type, mais appliquée au trading.
prt est une boîte noire, mais j'ai quelques suppositions quant à son fonctionnement : les valeurs des indicateurs sont calculées sur 32 bits côté utilisateur ; et calculées sur 16 bits (ou quelque chose qui s'en approche) côté serveur.
16 bits c'est très très léger pour exprimer des valeurs à 5 ou 6 chiffres commes les indices (16 bits = 7 chiffres précis au mieux).
Du coup, mes robots qui tournaient côté serveur et qui étaient censés prendre position sur des croisements de moyenne mobile étaient toujours décalés de plusieurs bougies par rapport à mes indicateurs qui tournaient en local.
Même cause, mêmes effets, j'ai changé de plateforme de trading et je me retrouve avec le même foutoir lorsque je calcule en float 16 bits. Passer en double 32 bits et c'est tout bon.
A RETENIR : PAS DE CROISEMENT DE moyennes mobiles D'INDICES CODES EN 16 BITS (ou alors il faut que les pentes des MM soient raides )
prt est une boîte noire, mais j'ai quelques suppositions quant à son fonctionnement : les valeurs des indicateurs sont calculées sur 32 bits côté utilisateur ; et calculées sur 16 bits (ou quelque chose qui s'en approche) côté serveur.
16 bits c'est très très léger pour exprimer des valeurs à 5 ou 6 chiffres commes les indices (16 bits = 7 chiffres précis au mieux).
Du coup, mes robots qui tournaient côté serveur et qui étaient censés prendre position sur des croisements de moyenne mobile étaient toujours décalés de plusieurs bougies par rapport à mes indicateurs qui tournaient en local.
Même cause, mêmes effets, j'ai changé de plateforme de trading et je me retrouve avec le même foutoir lorsque je calcule en float 16 bits. Passer en double 32 bits et c'est tout bon.
A RETENIR : PAS DE CROISEMENT DE moyennes mobiles D'INDICES CODES EN 16 BITS (ou alors il faut que les pentes des MM soient raides )
Et moi qui allais te dire qu'avec les robots de trading, on n'avait pas ce problème...
Spoiler:
Intéressant ça Jim. Les virgules flottantes, la hantise des systèmes précis.
Sinon sur prt , il y aurait des optimisations à faire. L'utilisation de régressions linéraires, par exemple, rame grave, voire plante sur mon poste. Bon je dis ça => qui aime bien châtie bien.
Tu es passé sur quel langage de script du coup ? MetaTrader ?
Sinon sur prt , il y aurait des optimisations à faire. L'utilisation de régressions linéraires, par exemple, rame grave, voire plante sur mon poste. Bon je dis ça => qui aime bien châtie bien.
Tu es passé sur quel langage de script du coup ? MetaTrader ?
Sur un autre sujet => je suis bien content de n'avoir jamais géré que de l'argent au final. J'ai confiance en mes qualités de développeur, mais je ne me sens pas gérer des sytèmes genre aéronotique, médecine etc... critiques quoi.
Je suis passé sur Sierra Chart. 100% écrit en C++. Ultra-rapide.BeerIsDead a écrit : Tu es passé sur quel langage de script du coup ? MetaTrader ?
La principale raison de ma migration n'était pas la rapidité de la plateforme, mais la flexibilité de pouvoir tout faire. Et en plus elle est robuste (sauf quand mes codes font des boucles infinies ).
Pas de script. Il faut coder ses indicateurs en C++ (idéalement). Puis les compiler, et ils deviennent des DLL de Sierra Chart.
Ah sympa. Ok. Je ne connais pas. De toute façon, j'ai plutôt l'optique de programmer tout de A à Z (en Java sans doute) dés que je maîtrise le machine learning.
Même si la partie la plus flippante (pas la plus compliquée) c'est le passage d'ordres et les problèmes techniques, pour moi. Au moins quand c'est prt qui gère, tu peux te plaindre à quelqu'un si ton ordre n'a pas été exécuté.
Même si la partie la plus flippante (pas la plus compliquée) c'est le passage d'ordres et les problèmes techniques, pour moi. Au moins quand c'est prt qui gère, tu peux te plaindre à quelqu'un si ton ordre n'a pas été exécuté.
Je ne sais pas quelle est ta motivation, mais ça me semble une tâche très ardue.
Gérer les différents protocoles pour les flux de données et maîtriser les langages spécifiques pour les passages d'ordre sur les marchés régulés (DTC/FIX...) c'est un vrai métier à temps plein.
Gérer les différents protocoles pour les flux de données et maîtriser les langages spécifiques pour les passages d'ordre sur les marchés régulés (DTC/FIX...) c'est un vrai métier à temps plein.
Python est présent partout.
Dans toute les application de type box, raspberry domo tique. Dès qu’il y a un peu de Linux il y a du python. Tu prends par exemple distribution Ubuntu toute l’interfaces graphiques est quasiment faite en python. Tous les scriptes d’installation, de mises à jour de tout ce que tu veux python
Dans le web
Dans les applications sur PC et sur Mac
Dans les outils de production et dans l’industrie partout partout partout
C’est assez complémentaires du C et du Java
Dans toute les application de type box, raspberry domo tique. Dès qu’il y a un peu de Linux il y a du python. Tu prends par exemple distribution Ubuntu toute l’interfaces graphiques est quasiment faite en python. Tous les scriptes d’installation, de mises à jour de tout ce que tu veux python
Dans le web
Dans les applications sur PC et sur Mac
Dans les outils de production et dans l’industrie partout partout partout
C’est assez complémentaires du C et du Java
Sujets similaires
Ramener un PP futurs sur cfds à risque limité
Fichier(s) joint(s) par Jim » 13 oct. 2016 14:44 (23 Réponses)
Fichier(s) joint(s) par Jim » 13 oct. 2016 14:44 (23 Réponses)
points pivots des graph futurs pour graph cfd à risque limité ?
par Reda » 15 oct. 2019 21:53 (9 Réponses)
par Reda » 15 oct. 2019 21:53 (9 Réponses)
Trader les cfd à risque limité en regardant les futurs
par Benoist Rousseau » 10 nov. 2019 13:21 (3 Réponses)
par Benoist Rousseau » 10 nov. 2019 13:21 (3 Réponses)
Ecart et pertinence des volume PRT et futurs euronext
par Amarantine » 08 mai 2020 03:34 (2 Réponses)
par Amarantine » 08 mai 2020 03:34 (2 Réponses)