Tout est dans les parenthèses que tu as mis : en C tu ne fais pas de compromis au final, ca ne change pas grand chose sur les perfs.
Je te renvoi à ce que t'as expliqué Nicolas plus haut (plus je te connais plus j'ai l'impression que tu es rétif à tout apprentissage): http://www.linuxfr.org/comments/1068755.html#1068755
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
C'est difficile de savoir réellement parce que ça dépend du type d'appli sue tu compile, et le compilateur peu découvrir plein de trucs grace à la globalité... ou pas.
Au niveau global, c'est surtout la prédiction de type qui est faite et donc la suppression d'appels polymorphique (plus que 2% à la fin en moyenne).
Mais ça peut se faire aussi assez localement. Genre avec 3 prototypes et ta lib collection, ce qui est un code petit comme un module Linux, tu va avoir quand même pas mal d'optim. Surtout que la dernière version du compilateur effectue pas mal de détection d'optims locales.
Si tu veux, on peut déjà considérer que le simple fait d'optimiser sur ton objet + la lib de base que tu utilises (nombre + string + collections) ça optimise pas mal déjà.
Mais plus tu globalise mieux c'est.
Donc pour le MPEG 2, tu dois déjà avoir pas mal d'optims même en découpant en 10 parties.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Quand Ben aura le temps de s'y mettre, c'est absolument pas prioritaire.
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Ben, on fait pareil, vu que c'est du C derrière.
Comment ils font en Eiffel d'après toi.
Dans ma boite, en java, on a maven le gros bousin pour "compilo, linker, makefile", et eclipse pour l'IDE.
En Lisaac, tu as eclipse comme IDE, et le compilateur pour compiler (et shorter pour te générer la doc).
La chaine de production est là. Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
Je répète : lit 10 fois http://www.linuxfr.org/comments/1068755.html#1068755 , tu vas peut être finir par comprendre....
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai, mais le mécanisme est généralisé pour ça (en fait c'est une dose d'aspect programming).
Tu peux poser des contrats sur du code, des données, en tant qu'invariant de prototype.
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code " ? Parce que moi, j'ai du me les taper à la main, les mock, et je vois pas ce que c'est en "dynamique" (et ça m'intéresse parce que c chiant les mocks...).
Pour l'introspection, je devrais pouvoir jouer avec dans 2 ou 3 mois, c'est quasi implémenté. Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compilation
Chez nous, ça s'appelle "shorter".
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
composants "versionnable", "signables" : Dans la section header (en passant, en Java, je sais pas comment on fait)
Introspection, voir plus haut.
chargement dynamique (plugins) : C'est quoi ?
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
déploiement à distance : C'est quoi ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: rentrons dans le vif du sujet
Posté par Ontologia (site web personnel) . En réponse au journal Linux un bloat, ah bon ?. Évalué à 2.
Je te renvoi à ce que t'as expliqué Nicolas plus haut (plus je te connais plus j'ai l'impression que tu es rétif à tout apprentissage): http://www.linuxfr.org/comments/1068755.html#1068755
Ben non, parcque en Lisaac le fait de ne pas compiler globalement ca va te faire "réellement" perdre des perfs (sinon c'est que le compiler global n'apporte pas de gain).
Je sais pas moi, découper votre encodeur MPEG2 en par exemple 10 modules séparés, et remesurez les perfs. Soit il n'y a quasiment pas de perte et on se rend compte que l'optimisation globale ne sert quasiment à rien, soit les perfs sont nettement dégradées et ca justifie l'optimisation globale tout en mettant en avant la contradiction de la modularité.
C'est difficile de savoir réellement parce que ça dépend du type d'appli sue tu compile, et le compilateur peu découvrir plein de trucs grace à la globalité... ou pas.
Au niveau global, c'est surtout la prédiction de type qui est faite et donc la suppression d'appels polymorphique (plus que 2% à la fin en moyenne).
Mais ça peut se faire aussi assez localement. Genre avec 3 prototypes et ta lib collection, ce qui est un code petit comme un module Linux, tu va avoir quand même pas mal d'optim. Surtout que la dernière version du compilateur effectue pas mal de détection d'optims locales.
Si tu veux, on peut déjà considérer que le simple fait d'optimiser sur ton objet + la lib de base que tu utilises (nombre + string + collections) ça optimise pas mal déjà.
Mais plus tu globalise mieux c'est.
Donc pour le MPEG 2, tu dois déjà avoir pas mal d'optims même en découpant en 10 parties.
'Fin étudie la question avant d'affirmer des choses de ce genre, parce qu'au niveau théorique, y répondre est assez difficile.
Mais t'es comme la plupart du ingés javaiste/csharpiste (j'en ai plein dans ma boite), tu connais rien à la compilation. (ça c'est la petite méchanceté ;-)
Oué bah c'est pour ça que je dis : "quand est ce que Lisaac va résoudre le problème".
Quand Ben aura le temps de s'y mettre, c'est absolument pas prioritaire.
Ben la chaîne de production à partir de modules est parfaitement prise en compte par les outils (compilo, linker, makefile, IDE). Je te demande comment on fait en Lisaac.
Ben, on fait pareil, vu que c'est du C derrière.
Comment ils font en Eiffel d'après toi.
Dans ma boite, en java, on a maven le gros bousin pour "compilo, linker, makefile", et eclipse pour l'IDE.
En Lisaac, tu as eclipse comme IDE, et le compilateur pour compiler (et shorter pour te générer la doc).
La chaine de production est là.
Euh, le troll du journal cible le kernel Linux, même si Linux tourne sur de l'embarqué, c'est un projet pour moi "énorme", les problématiques de modularité sont pleinement à prendre en compte.
Je répète : lit 10 fois http://www.linuxfr.org/comments/1068755.html#1068755 , tu vas peut être finir par comprendre....
C'était une remarque plus général sur Lisaac, pas spécialement lié à la compilation séparée.
Tests : possibilité d'inclure des méta-données, de mocker dynamiquement le code (nécessite l'introspection et la génération dynamique de code).
Inclure des méta donnée : tu peux avec les contrats, en les détournant un peu il est vrai, mais le mécanisme est généralisé pour ça (en fait c'est une dose d'aspect programming).
Tu peux poser des contrats sur du code, des données, en tant qu'invariant de prototype.
Tu peux m'expliquer ce qu'est "mocker dynamiquement le code " ? Parce que moi, j'ai du me les taper à la main, les mock, et je vois pas ce que c'est en "dynamique" (et ça m'intéresse parce que c chiant les mocks...).
Pour l'introspection, je devrais pouvoir jouer avec dans 2 ou 3 mois, c'est quasi implémenté.
Documentation : syntaxe spécialisée et utilisable par le compilateur pour générer automatiquement une documentation externe synchronisée à chaque compilation
Chez nous, ça s'appelle "shorter".
Déploiement : composants "versionnable", "signables", introspection et chargement dynamique (plugins), abstraction hardware, déploiement à distance, etc.
composants "versionnable", "signables" : Dans la section header (en passant, en Java, je sais pas comment on fait)
Introspection, voir plus haut.
chargement dynamique (plugins) : C'est quoi ?
abstraction hardware : C'est quoi ? (si c'est ce que je pense, on est largement en avance)
déploiement à distance : C'est quoi ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker