Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 122 528 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
241
On en utilise 2

Omni ORB et Orbix...

Je crois qu'on est passé à OmniORB parce que s'est gratos à l'instart d'orbix
qui ne l'est pas...

On doit etre en omniORB V2.80

et orbix : autour de la version 3 je crois , de mémoire...

Mais bon, CORBA, c'est bien, mais vu qu'on est full windows maintenant
sur nos simulateurs, c pas forcément pertinent de continuer avec face au
remonting.. (meme si le remoting a plein de chose en moins par rapport à corba).

THe Monz, Toulouse
242
UBlas > connu pour être pas top, sans compter que l'interface BLAS, c'est franchement pourri !
Comme Meyer le dit dans son livre - que je suis en train de lire -, je pense que le GC sera vraiment indispensable partout lorsqu'on pourra le laisser tourner en tache de fond sans qu'il nous pique du temps CPU, et là OK, autrement je préfère garder mon C++ ;)

Gabou> la currification comme tu la présentes, Boost permet de le faire - bind, function, ... - ;)

Les jeux ont aussi un impératif pour rejoure une partie à l'identique, c'est d'ailleurs un gros souci qu'a eu Total annihilation car le calcul du brouillard de guerre était dans l'interface graphique... Civ4 a son IA en Python, ...

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

243

Citation :
e pense que le GC sera vraiment indispensable partout lorsqu'on pourra le laisser tourner en tache de fond sans qu'il nous pique du temps CPU, et là OK, autrement je préfère garder mon C++



Betrand Meyer, celui qui a dit "There are only two things wrong with C++: The initial concept and the implementation." ;) Ou celui qui a invente Eiffel, qui utilise souvent un gc.

Piquer du temps cpu par rapport a quoi ? Ca sous entend que le management a la main de la memoire est gratuit, alors que non. Typiquement, quand tu utilises tes auto_ptr et cie, c'est aussi une gestion de memoire qui a un cout. Quand tu fais un malloc, c'est une gestion de memoire qui a un cout. A priori, tu t'amuse pas a changer la taille des segments a la main. Je suis persuade que tu surestimes de beaucoup l'efficacite du C++ pra rapport a d'autres langages.

Sinon, bind, function et cie, ca n'a rien a voir, parce que ca n'a franchement aucun sens de comparer ce genre de fonctionnalites entre un langage interprete et un langage compile comme le C++. Ca reste un artifice pas super elegant, en C++, et franchement peu utilise. Tous les langages fonctionnels sont interpretables dans leur implementation standart, au moins pour ceux que je connais un tout petit peu (lisp, scheme, ocaml, haskell). C'est pas un hasard.

Citation :
l'interface BLAS, c'est franchement pourri !



Je vois pas pourquoi. C'est le standart, et il y a plein de binding. Je comprends pas tres bien l'interet d'utiliser le C++ sans utiliser BLAS si l'on cherche l'efficacite.
244
Oui, ce Bertrand Meyer-là ;) Je ne suis pas d'accord avec tout,mais c'est un gars qui a l'air d'avoir pas mal réfléchi sur ces concepts ;)

Le management à la main n'est pas gratuit, OK, mais c'est toi qui gère le quand et le comment, avec un GC, il peut se lancer à tout moment et à un moment critique d'après Murphy :)

Je ne vois pas pourquoi les bind et autres '_' sont différents de tes defun g(x) f(3, x) !

En C++, la manière intuitive de faire, c'est A = B * C, c'est pas A = mult(B, C).

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

245

Citation :
Je ne vois pas pourquoi les bind et autres '_' sont différents de tes defun g(x) f(3, x) !



Ben ca pert beaucoup d'interet si tu dois recompiler le code pour utiliser la nouvelle fonction ;) Je vois pas beaucoup l'interet de ce genre de trucs dans un langage compile statique, pour etre franc.

Citation :
vec un GC, il peut se lancer à tout moment et à un moment critique d'après Murphy



Pour du calcul en batch, on s'en fout. Le GC, c'est un probleme par exemple en temps reel, mais on ne parle pas de ca. Et les malloc a tout moment, ca arrive aussi en utilisant la stl ;)

Sur Meyer, c'etait une pique, evidemment.

Citation :
En C++, la manière intuitive de faire, c'est A = B * C, c'est pas A = mult(B, C).



Il y a quelque chose que je comprends pas. Tu utilises le C++ parce que tu estimes que c'est le seul langage a te garantir l'efficacite exigee. Du coup, tu laisses de cote des langages objectivement nettement plus expressifs, au moins pour la "tuyauterie". Dans cette optique la, la difference entre un * et un mul...
246

Citation : Ben ca pert beaucoup d'interet si tu dois recompiler le code pour utiliser la nouvelle fonction Je vois pas beaucoup l'interet de ce genre de trucs dans un langage compile statique, pour etre franc.


Ah, OK, c'est vrai que j'avais oublié que tu tiens au temps de compilation, donc je suis d'accord avec toi, mais c'est tout de même très utile - par exemple faire des opérations sur des lignes ou des colonnes de matrices, c'est instantanné avec cette méthode, on choisit vite ce qui doit être constant ou pas ;) -

Citation : Pour du calcul en batch, on s'en fout. Le GC, c'est un probleme par exemple en temps reel, mais on ne parle pas de ca. Et les malloc a tout moment, ca arrive aussi en utilisant la stl

Sur Meyer, c'etait une pique, evidemment.


Effectivement, sur du calcul en batch, ça ne sert pas à beaucoup, mais dans le cas d'un processus critique, un GC déclenché peut bouffer du temps à un moment critique auquel on ne s'attend pas alors que pour un malloc, on le sait, on l'a demandé tout de même ;)
Oui, Meyer est un peu bizarre, il dit que pour l'instant, un GC est peu utile, mais il l'utilise tout de même, mais c'est aussi pour ne pas faire de gestion à la main. D'ailleurs, un de ses exemples intermédiaires, c'est les pointeurs intelligents, l'inconvénient face au GC, ce sont les cycles, ce qui peut être évité dans les pointeurs qui vont entrer dans le standard ;)

Citation : Il y a quelque chose que je comprends pas. Tu utilises le C++ parce que tu estimes que c'est le seul langage a te garantir l'efficacite exigee. Du coup, tu laisses de cote des langages objectivement nettement plus expressifs, au moins pour la "tuyauterie". Dans cette optique la, la difference entre un * et un mul...


Oui, je suis bizarre :D
Le C++ n'est pas le seul, j'en suis conscient - c'est pas pour rien que ce que tu dis sur Python m'intéresse au plus haut point, même si je n'ai pas encore eu le temps de me plonger dans ce langage, même si j'ai des docs qui attendent un peu de temps cerveau ;) -, mais pour me simplifier la vie, je préfère tout de même utiliser même en C++ une notation naturelle.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

247
Ca y'est je comprends plus rien :ptdr:

Tiens puisque je suis là, j'aimerais vous poser quelques questions qui me prennent un peu la tête en ce moment... Récemment, j'ai codé un plug VST en C++ (avec VS.NET 2003), il marche à peu près bien, même si j'ai eu un peu de mal avec les allocations mémoire. Par contre, y a des trucs sur lesquels je galère à mort.

Ces derniers jours, j'ai bossé sur une simulation d'ampli. Et avec quelques filtres et fonctions, j'arrive à un truc qui consomme à mort du CPU. Alors qu'un Guitar Rig 2 avec 20 fois plus de fonctions me prend 4% de CPU au max. Ca me laisse perplexe.

Est-ce qu'il existe des sources d'informations sur l'organisation du code et l'optimisation ? Des bouquins, des articles... Je suis en train de me demander si je devrais faire mon stage de master 2 en Février chez Arturia ou Ohmforce justement pour mieux apprendre à coder mes VSTs, et voir quelles sont les différentes techniques utilisées pour que le tout soit le plus propre et stable possible...

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape

248

Citation :
Tiens puisque je suis là, j'aimerais vous poser quelques questions qui me prennent un peu la tête en ce moment... Récemment, j'ai codé un plug VST en C++ (avec VS.NET 2003), il marche à peu près bien, même si j'ai eu un peu de mal avec les allocations mémoire. Par contre, y a des trucs sur lesquels je galère à mort.

Ces derniers jours, j'ai bossé sur une simulation d'ampli. Et avec quelques filtres et fonctions, j'arrive à un truc qui consomme à mort du CPU. Alors qu'un Guitar Rig 2 avec 20 fois plus de fonctions me prend 4% de CPU au max. Ca me laisse perplexe.

Est-ce qu'il existe des sources d'informations sur l'organisation du code et l'optimisation ? Des bouquins, des articles... Je suis en train de me demander si je devrais faire mon stage de master 2 en Février chez Arturia ou Ohmforce justement pour mieux apprendre à coder mes VSTs, et voir quelles sont les différentes techniques utilisées pour que le tout soit le plus propre et stable possible...



Ben dans la mesure du possible, file moi le code en question, on peut en discuter un peu. Si (ce que je comprends bien, bien sur) tu peux pas filer tout le truc, tu peux filer un truc avec les elements de base (filtre et cie), sur une structure differente "non secrete", avec les memes problemes. J'ai VS express installe sur mon portable en VM, pour tester quelques codes multi plateformes.

Mais globalement, c'est un probleme complexe. Le truc de base a regarder, c'est evidemment l'algo version non temps reel, et voir ou ca prends du temps. Pour ca, il faut que tu aies la possibilite de configurer ton projet de telle sorte a ce qu'au lieu d'etre compile VST, il soit compile vers un hote "bateau" ou tu peux profiler et instrumenter ton code.

Quelques regles de base:
- dans la fonction process, est ce que tu utilises des appels systeme ?
- Lorsque tu utilises des sin,cos et autre fonctions transcendentales, est ce que tu utilises les fonctions standarts de la libc ?
- est ce que tu utilises bien le cache de ton proc ?
- est ce que tu calcules plusieurs fois les memes valeurs ?

Il y a des trucs simples pour l'optimisation: par exemple, en maths, diviser par deux et multiplier par 0.5, c'est pareil. Sur un pentium, en flottant, diviser est facilement 5 a 10 fois plus couteux qu'une multiplication. Si tu as besoin de cos et sin regulierments espaces, tu peux utiliser des tables et des formules de recurrence, etc... Aussi, il faut bien connaitre le compilo, et toutes les options d'optimisation. Ca peut changer beaucoup de choses.
249
La méthode ultime pour savoir ce qui te bouffe du CPU : le profiling ;)

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

250
Ben y a pas grand chose à cacher pour l'instant :mrg: Mais bon comme je disais mon problème c'est un peu de l'organisation... Par exemple, j'utilise pas mal de classes (pour chaque filtre, pour les traitements non linéaires, pour la compression...), que j'appelle dans la fonction qui fait le traitement en temps réel, je ne sais pas trop me servir de l'assembleur... Bref c'est un problème global plutôt que sur du code particulier. Je suis capable de faire quelques améliorations, mais je me demande si il n'existe pas des recettes de cuisine que tous les gens qui font du VST utilisent...

Développeur de Musical Entropy | Nouveau plug-in freeware, The Great Escape