De mon coté c'est plus la doc que j'accuse. Entre un message qui me dis que faut pas si c'est trop gros et un autre qui me dis que ca vas planter dans certains cas... Je suis un peu perdu.
Il y en a un de très bon d'argument pourquoi subprocess est bizarre. En lisant la doc on peut lire:
Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited.
(pour communicate)
et
Warning Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.
pour stdout/stdin/stderr
Comme il n'y a pas d'autre moyen de communiquer avec le sous processus, je fais quoi si je ne veut pas deadlocker et si j'ai BEAUCOUP de donnée ?
J'hesite à l'acheter depuis plusieurs année. C'est utilisable sous linux facilement ? (Genre je peux lui fournir un fichier texte, il me resort un xml de l'analyse que je peux formater comme je veux ?)
Rapidement, parce qu'après l'on va dire que c'est trop long (mes excuses pour le 72 colonnes fixe, naïvement je pensais que la saisie "html" ferait des retours à la ligne au niveau des doubles retours à la ligne et ignorerait les simples, trop d'année sous vim et trop de rst ;)
Agree pour boost python, c'est un peu fastidieux, mais cela fait le boulot (Mais je suis tellement fan de la simplicité de cytpes...)
Pour les 30 minutes de compilation, je suis d'accord c'est un cas extrême. Mais même 1 minute, quand t'es en pleine phase d'essais/erreurs, c'est trop. Après cela ne veut pas forcement dire que ton programme python prendra des heures à se lancer. L'import d'un module python qui sera utilisé N fois ne se fait qu'une fois. L'instanciation d'un template qui sera utilisé par N différents types par M différents fichiers .cpp se fait un nombre compris entre N et N*M fois.
Pour les [] versus .at() versus C/python, oui, j'avoue, en effet, at sera toujours plus rapide en C++ qu'en python, rien à dire la dessus. Ce que je voulais soulever c'est qu'a force d'ajouter des couches en C++ pour faire comme en Python (ou ruby, ou autre chose), cela à un cout de performance. Si l'on est près à payer ce cout de performance (qui n'est pas négligeable, je récite mon exemple sur les fonctions virtuelles qui pouvent détruire les performances d'un programme), pourquoi ne pas utiliser python (ou ruby, ou...).
Mon problème n'est pas forcement le C++, mais plutôt le mauvais usage de celui-ci. Il est vrai qu'il y a des cas particuliers qui nécessitent l'utilisation du C++ et je ne suis pas en guerre contre les gens qui ont fait ce choix de façon raisonnée, j'essaye plutôt d'ouvrir les yeux à ceux qui le font sans réfléchir, ou avec de faux arguments. C'est comme le débat Maya/Blender (ou Windows/Linux). Je n'ai rien contre celui qui utilise Maya parce que celui-ci est plus pratique pour certains cas de figure. J'ai quelque chose contre celui qui crache sur Blender en disant que Maya est mieux parce que c'est professionnel et puis de tout manière je m'en cogne, je le pirate.
Pour ton assertion "C++ plus facile pour travailler en entreprise". Je dirais que oui, sur un CV cela le fait mieux (par contre python ou ruby ça peut faire de toi l'élément qui se démarque dans la masse de +/- bon développeurs C++). Pour l'efficacité du travail, cela dépend à mon sens de savoir si tu bosses avec des gens compétents et avec de la rigueur ou pas ? Et je suis d'accord que quitte à faire des conneries, autant le faire avec un système à typage statique qui sera moins permissif. Maintenant, quand je bosse tout seul, je prend mes responsabilités et j'espère ne pas être mauvais. Et quand je m'entoure, j'essaye de m'entourer de gens compétents qui ne se laisseront pas avoir par le risque du typage dynamique et qui sauront profiter de ses avantages.
Pour ton problème d'encodage.
- Soit tu veux travailler sur des caractères et dans ce cas là il te faut faire une conversion et tu dois connaître le format d'entrée et de sortie (en l'imposant ou en demandant à l'utilisateur de le spécifier, si celui-ci ne suit pas cette règle, tu ne peux rien pour lui) et dans ce cas là rien ne t'empêches de convertir son iso-42 en unicode puis en iso-42 (en supposant qu'il existe une fonction de conversion ;)
- Soit tu n'as pas besoin de travailler sur les caractères, et tu peux travailler sur un bytes (le type python3 ~ char[]) et ainsi il n'y aura pas de caractère qui disparaît en sortie.
L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.
- Tu peux bidouiller tes chaînes à coup d'opérateurs de bit, après il faut voir si cela à un sens (sur une chaîne char[], certainement, et encore je ne vois pas grand chose à faire de plus que le changement de case avec ^ (1 << 5))
- Tu peux décharger des modules, après faut voir si cela à un sens
- Tu peux faire de la programmation de carte graphique en Python ;)
- Tu peux aussi te demander en C++ si les 30 lignes que tu as écris seront aussi rapide que du Python (Je pense par exemple au hashmap qui n'existent pas dans la STL). Je joue souvent un jeu marrant avec mes collègues, élèves ou autre qui me disent que python est lent, je leur demande de me fournir un bout de code C++ qui est selon eux rapide et un bout de code python qui est selon eux lent. Très souvent je peux récrire leur bout de python pour qu'il soit plus rapide que leur bout de C++ (bon, je peux aussi récrire le bout de C++ pour qu'il soit plus rapide que le bout de Python ;)
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces.
Je me demande aussi, mais figure toi que j'ai aussi ce problème. Je ne fais presque jamais d'erreur de syntaxe en Python, je passe mon temps à en faire en C++... Mais je suis certainement biaisé en C++ du fait de mon expérience python. (Enfin j'ai fais plus de C++ dans ma vie que de python...)
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Ça c'est (à mon avis) un faux argument. Pourquoi ré-indenter ? Cela signifie que ton indentation n'a qu'une valeur cosmétique, donc cela ne sert a rien d'indenter. Si cela ne sert a rien, pourquoi le faire non ? Donc cela sert à quelque chose. Donc il faut indenter, et tous indenter de la même manière au sein d'un projet, donc l'indentation a un sens ? Tient, ce sens est vraiment proche des blocs que je délimite par des {} et ;. C'est meme tellement proche que je me demande pourquoi je duplique l'information... En fait l'indentation significative : "ça permet de remettre facilement les {}; avec un outil tel que GNU jemetlesaccollades"
Allez, hop, j'arrive après la guerre et je répond, parce que je suis un vil
pythoneux qui ne supporte pas que l'on dise du mal du meilleur langage du
monde (Lisez tout de même la suite avant de moincer, j'ai essayé de mettre des
arguments)
* Le python n'est pas un langage compilé, j'aime bien les langages
compilés. Ça permet de faire des mini-pauses pendant la compilation, et on a
pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une
concaténation entre un string et un nombre).
Pour les minis pauses, je suis tellement d'accord. Sauf qu'ici au boulot c'est
des pauses de 30 minutes chaque fois que l'on change un commentaire dans le
fichier .h qui contient le template de base du système...
Sinon, pour le coté erreurs en pleins milieu, les autres l'on déjà dis, tu
confond la compilation et le tapage statique. Java est aussi un langage
interprété et pourtant tu as des erreurs au milieu du programme.
Mais en pratique en C++ tu as aussi des erreurs en milieu du programme que la
*compilation* ne réglera jamais. Par contre l'interpréteur peut être plus
malin que ton CPU en te renvoyant une erreur plus précise (genre unbound acces
en lieu et place de segfault). Mais j'avoue qu'avec une utilisation correcte
de la STL, tu n'as plus de segfault (enfin presque). Mais cette utilisation
correcte de la STL revient à rendre C++ aussi lent (enfin presque) que
Python...
* Le python ne permet pas de gérer manuellement la mémoire. Le ramasse
miettes, je n'accroche pas du tout. Surtout qu'avec une bonne architecture
du programme, on ne rencontre pas beaucoup de problèmes de gestion mémoire
en C++.
Chacun ses goûts. Je suis en grande partie d'accord avec toi quand je fais de
la programmation qui se doit d'être *vraiment* (cf plus loin) le plus rapide
possible.
Mais dans 99.9% des cas (chiffre au pif), quel est le besoin de gérer
l'allocation mémoire ? Tout le monde ici programme des fusées (Et encore, je
ne métrais pas de C++ dans les fusées), Tout le monde ici fait de la synthèse
d'image temps réel ? (Et encore, on peut en faire en python). Bon, donc sauf
si j'ai raté la dernière révolution, la plupart des code développés n'ont PAS
besoin de performances dingues, et n'ont PAS besoin de gestion fine de la
mémoire. Dans le cas particulier de l'article que l'on commente, l'on parle de
conception d'interfaces graphiques. Ici, 99.9% (chiffre au pif, certainement
surévalué) du temps CPU se passe dans le code du toolkit graphique et celui-ci
doit certainement faire une bonne partie des allocations mémoires (voirs peut
être 99.9% de celles-ci). Je connais mal Qt mais du peu que j'en ai fais en
C++, je ne me rappel pas avoir passé la moitié de la journée à faire des
malloc.
Et puis, tu dis aimer gérer toi même la mémoire, mais combien de personnes
utilisent une malloc alternative, combien de personnes surchargent le
paramètre alloc des templates de la STL ? Combien de personnes surchargent
l'opérateur new de la STL ? Si tu ne fais pas cela, alors tu ne peux pas
prétendre aimer gérer la mémoire.
De son coté, le GC de python, son job est de faire un malloc (si nécessaire)
quand tu crée un objet et nettoyer la mémoire (si il juge cela pertinent)
quand tu n'as plus besoin de cet objet. Alors oui, l'on ne maîtrise rien, mais
maitrise-t-on moins qu'avant ? Que faut-t-il craindre du GC de python ? Il
fait un travail fastidieux à notre place, en faisant moins d'erreur et
potentiellement plus rapide (du fait du pool de mémoire qui est réutilisé). Il
faut juste savoir l'utiliser correctement (ne rien faire) et si l'on veut une
utilisation avancé, il est aussi possible de l'utiliser de façon avancé (en
désactivant le GC de recherche de références cyclique et en ne laissant que le
compteur de référence qui ne consomme virtuellement rien)
* Pas de typage explicite des variables. C'est super pénible de ne pas savoir
quelle est le type de la variable que l'on a à gérer.
Goût et couleurs... Personnellement je ne m'intéresse pas à la variable ni à
son type, mais à ses capacités. Note que rien ne t'empêches en python de faire
du typage static.
Tu peux par exemple "décorer" tes arguments de fonctions:
def tortue(a:int, b:float)->float
Ensuite libre à qui veut de faire ce qu'il veut avec cela (je m'en sert pour
documenter les valeurs). Mais avec cela, tu n'as aucun problème pour faire de
la vérification de type au run-time, ou, un peu plus dur, écrire un
vérificateur de type statique. J'avoue, dans certains cas cela sera un peu
sioux ;)
Mais le problème ici, c'est que l'on s'en fout car l'on vois les types
de façon différente, plus comme une interface implicite :
Prenons un exemple. Tu est le gérant d'un bar. Un blanc entre dans le bar, tu
as prévu d'ouvrir le bar aux blancs, donc tu lui verses sa bière.
Un black (Il faut dire black pour être non raciste aujourd'hui) entre dans le
bar. Tu avais prévu que les blancs, mince. Comme t'es pas raciste, tu changes
ta porte d'entrée pour laisser passer les "buveurs", et tu demandes à tes
clients de se faire référencer comme buveur. Tu peux donc tout Homme se
présentant comme un buveur.
Un alien entre dans ton bar, et te demande à boire. Il n'a pas l'interface
buveur (son vaisseau vient de s'écraser devant ton bar, personne sur terre ne
connais l'existence de cette race d'arien, donc personne n'a pensé à le
rajouter dans le fichier des espèces qui boivent... Mais il a soif et te
montre de façon insistance avec sa tentacule la bouteille de bière. Pas
d'interface buveur, il ne bois pas. C'est ainsi que commencera la première
guerre universel (A lire, universal war one, très bonne BD sur ce sujet, enfin
presque).
Alors oui, on pourrait dire que c'est préférable de l'empêcher de boire si
l'on ne sait pas si il peut boire (imagine, il se trompe et cela le tue...).
C'est deux façon de voir les choses et je préfère rendre responsable les
développeurs que de rendre responsable le code. Le résultat étant le même à la
fin, soit c'est bon et cela passe, soit cela te pète à la gueule (au runtime
ou à la vérification statique). D'un coté tu t'es embêté à écrire du code
complexe, de l'autre t'as mis en place une procédure pour que cela pète au
runtime chez toi et pas chez le client (des tests par exemple). Comprendra qui
veut (Personnellement je préfère ne pas m'embêter en codant et écrire des
tests, parce que les tests, j'aurais honte de fournir du code au client qui
n'est pas testé... Donc entre écrire des tests et m'embêter en codant, ou juste
écrire des tests (et en plus sans m'embêter à les écrire...), le choix est
vite fait)
Le problème ici c'est que python ne manque pas d'une fonctionnalité de typage,
c'est juste une façon différente de voir les choses.
* Le self comme argument dans les méthodes de classes, c'est vraiment très
très moche comme hack, et les messages d'erreurs sont faussés (quand il
manque des arguments, le nombre d'arguments comprend le self, alors que l'on
ne doit pas le préciser avec la syntaxe classique).
Problème de goût et erreur de compréhension. Personnellement je trouve que le
this implicite en C++ c'est très moche comme hack (mon dieu, il vient d'où ?).
Après pour l'histoire du self, il n'y a pas de message d'erreur faussés, juste
une habitude que tu as pris d'ignorer dans le compte des arguments l'instance
concerné
toto.doit(5)
pour moi c'est une fonction (C.doit) qui prend deux arguments, toto et 5. C
sera dynamiquement déduit du type de toto (en l'occurrence, toto.doit(5) est
juste un raccourci syntaxique pour:
toto.__class__.doit(toto, 5)
avec toto.__class__ = C
Et là ou le système de type est intéressant, c'est que la classe C est finalement
juste un gros namespace de fonction travaillant sur des objets equivalents,
mais rien ne t'empeches de faire:
titi = B() # b n'a RIEN a voir avec C dans l'arbre d'héritage
C.doit(titi, 5)
En C++, on appelle cela les templates... En python on appelle cela le
dynamisme, mais en pratique les deux langages font la même chose...
Personnellement, je n'ai jamais compris pourquoi les autres langage ne
faisaient pas comme cela (pour le self/this). Et même avant que je connaisse
python, je ne comprenais pas. Quand j'ai découvert python, j'ai bondi de joie
au plafond en hurlant "Mon dieu, enfin des gens logiques qui pensent comme
moi"... Donc loin d'un hack immonde, c'est encore une fois un problème de
façon de voir les choses (même si le hack immonde, il faut être fou pour ne
pas se rendre compte qu'il est dans le langage C++ ;)
D'ailleurs, on va pousser un peu. Supposons une classe A et une
classe fille B ayant tout les deux une méthode "blork", Dans B.blork tu veux
appeler le A.blork sur l'instance courante...
En java tu utiliseras "inherited", bon, ok, java n'as pas d'héritage multiple
(en bien ou en mal), donc cela fonctionne très bien (je trouve cela juste
dommage d'introduire un nouveau mot clé dans le langage pour cela...)
En C++, tu utilises l'opérateur de portée de classe:
void B::blork()
{
A::blork();
}
Donc ici de façon implicite, A::blork est appelée avec le contexte. Mais si tu
utilises A::blork() en dehors de la classe B, et bien cela risque de ne pas
fonctionner non ?
En python tu verras simplement A.blork(self) que tu sois DANS l'instance le
code de la classe B ou en dehors (sauf que en dehors tu n'écrira pas de
variable nommée self ;)
Autre exemple. Tu écris une fonction qui travaille sur un objet de classe A,
et qui fait un truc
def mafonction(something):
assert(is_instance(something, A))
#dosomething with something
Note qu'ici je vérifie le type, pour le sport.
Puis après, tu obtient le pouvoir d'intégrer ta fonction au sein de la classe
A. Et bien tu n'as rien à changé, le prototype reste le même (faut renommer
self en something partout pour que cela soit joli, mais sinon c'est la même
chose).
Je ne parle pas de simplicité pour le refactoring ou autre hein (en C++ c'est
presque aussi simple en C++), je parle de cohérence. En C++ ce n'est pas du
tout la même chose, en python c'est toujours une fonction, il n'y à rien de
changé. En c++ il y a des namespaces, des classe, des fonctions, des méthodes
statiques, des méthodes d'instance. En python l'on fait la même chose
simplement avec des namespaces et des méthodes.
* On ne peut pas modifier un caractère d'une chaîne de caractère, obligé de
* faire une copie.
C'est un choix qui semble logique de mon coté. Une chaîne de caractère tient
sa valeur de son contenu, tu changes le contenu, tu changes la chaîne. Mais
sincèrement, on s'en cogne pas un peu ? Je crois que je n'ai jamais changé
un caractère dans une chaîne... A la limite plusieurs, mais cela change
complètement l'algo derrière, et j'avoue être plutôt heureux que python me
l'interdise ;)
Et si vraiment tu n'est pas content, libre à toi d'écrire un type
mutablestring basé sur les listes voir même sur les chaînes. Cela prend 5
minutes. Mais je n'en vois pas l'intérêt.
Les exceptions pour les jeux de caractères, ça me gonfle.
Précise ta remarque ? Les exceptions que j'ai eu en python étaient toutes liés
à une erreur de ma part. Une fois que tu as compris qu'il faut toujours
travailler en unicode (ou str dans python3), sauf pour les entrées sorties ou
tu converties en str (ou bytes dans python3) ou les traitements qui n'ont pas
de valeur de chaîne de caractère, il n'y a plus de problème.
On parlait tout a l'heure de vérification à la compilation, du fait que le
typage apportait un lot de sécurité, bla bla bla... Et bien ici python
t'apporte le fait que si tu fais des bêtises avec ta chaîne de caractère, il
te hurle dessus pour éviter que tu ne vois pas que la sortie est remplie de
petits '?', certes très jolis. Python est ici plus sécurisé que le C++, sans
être embêtant...
De toute façon ici l'on ne peut pas comparer avec C++, la lib standard C++ ne
gère pas l'un code, donc de toute façon tu n'aurais jamais eu ses erreurs en
C++, mais ce n'est pas forcement pour une bonne raison. C++ 0x apportera un
vrai support des chaînes de caractère, donc rassurez vous, cet argument en
faveur de python ne sera plus dans quelques années, à en juger par
l'implémentation du C99 sur les grands compilateurs du marché, au moins 10 ans ;)
L'impression générale d'être limité à une utilisation en haut niveau.
Précise ? Oui tu ne feras jamais un OS en python (et encore, cela pourrait
être marrant), mais quelles sont tes contraintes bas niveau ?
Personnellement je fais de l'OpenGL/Cuda/OpenCL tous les jours avec, et je
trouve que c'est suffisamment bas niveau...
Maintenant oui, j'accepte cet assertion, cependant revenons au débat sur Qt,
personnellement je m'en fout de toucher mes registres à la main, de faire du
(S/M)IMD, de gérer ma gestion de lignes de cache du CPU, de savoir comment mes
pages mémoires sont swapées. ON fait de la GUI là... On est en 2010, combien
de personnes, à part les gens qui font du système ou de l'image ont besoin
d'autant de bas niveau ?
Alors oui, quand j'ai besoin de bas niveau (mon dieu, il y a quoi dans mon
cache L2 !!!) Je fais du C (et du C++ quand vraiment je fais un gros truc et
que j'ai besoin d'une syntaxe objet plus légère que celles possibles en C),
mais quand je fais une gui, avec C++ j'ai "l'impression générale d'être limité
à une utilisation de bas niveau".
Puis l'indentation obligatoire, c'est super pénible. Surtout quand on
* reprends le code d'une autre personne, ou que l'on a juste commenté une
* condition.
C'est personnel. Moi je ne supporte plus les accolades et points virgules et
bien que j'ai plus d'années d'expériences en C/C++ que python, n'oublies
encore pleins de ;, mais je n'oublies jamais d'intenter mon code...
Quand j'enseigne la programmation à la fac ou en école d'ingé Je passe les 3/4
de mes séances C/C++/Pascal à rajouter des {};begin/end... J'ai la chance
d'avoir quelques groupes d'enseignement en Python, et bien je n'ai jamais* eu
de problème avec l'indentation et la syntaxe du langage.
* Une fois un élève qui à changé la configuration de son éditeur de texte pour
l'indentation et qui est passé soudain de 4 espaces à un tab... Un beau
bordel, j'avoue. Mais une fois ce détail connu pour une utilisateur averti,
il suffit d'un peu de rigueur (et d'un éditeur bien configuré) et ce problème
devient un souvenir.
Pour les commentaires de conditions, j'avoue, c'est peu pratique (enfin en C
tu est aussi forcé de supprimé les accolades ouvrantes et fermantes, sauf si
tu acceptes la déclaration d'un nouveau bloc, ce qui, j'avoue, à peu
d'implications, sauf si il reste encore le else après et là t'es eu...
Personnellement, j'ai une macro $EDITOR pour chercher le if le plus proche, et
cycler entre:
if condition:
#TODO if condition:
if True:
#TODO if condition:
if False:
Et elle est adaptée d'une macro pour le C que j'avais avant qui faisait la
même chose, car je n'ai pas trouvé mieux (je suis preneur).
Ce que j'aime bien dans les langages compilés sinon, c'est l'optimisation
automatique du code (en python, on perd la documentation quand on veut
optimiser). Gcc va vraiment plus optimiser, et même en fonction de
l'architecture de la machine.
Avec un langage interprété, effectuer les mêmes optimisations serait possible,
mais ce serait aussi bien trop lent à exécuter.
La suppression de documentation n'optimise pas plus, elle réduit seulement la
taille du fichier. Tu as deux flag en python, -O et -OO pour optimiser. -O ne
fait pas grand chose (principalement, il supprime les assert et la variable
__debug__) et -OO supprime la documentation. Si tu veux optimiser, python
n'est vraiment pas la bonne solution.
Et là je vais revenir sur le débat de la mémoire. ON s'en COGNE des
optimisations. On fait de la GUI ici hein, de la GUI ! Le truc pour lequel le
toolkit bouffe 99.9% de ton temps CPU pour dessiner des fenêtres à l'écran. Le
truc ou l'élément limitant en terme de performances et de réactivité c'est
l'utilisateur, la carte graphique, le serveur d'affichage et le toolkit.
Et puis pour la plupart on fait de la GUI qui affiche les
résultats qui sortent d'une BDD, le truc qui va prendre un temps de fou pour
revenir, parce que une BDD c'est des milliers de cycle CPU pour ramener une
petite donnée, c'est comme cela. Et on fait de la gui qui va lire et charger
des fichiers Image, qui va prendre quelques milliers de cycle CPU pour
décompresser le jpeg. Tout cela est déjà écrit et est lent, et sera toujours
plus lent que 10 appels de fonction dans python pour connecter ton évènement
clique de bouton sur la fonction de décompression de JPEG.
Alors oui, python prendra quelques cycles CPU de plus que C++ dans la boucle
principale, cycles qui sont négligeables à cote de ceux nécessaire au toolkit
pour afficher ta fenêtre. Alors OUI, je ne ferais jamais un toolkit en python,
ou une librairie de décompression JPEG, (et encore... faut voir ;)), mais
quand l'on parle d'utilisation de librairies qui existent déjà.
Et puis l'on parle d'optimisation et de C++, j'en rigole tous les jours. Du
fait des mécanismes d'héritage virtuel, les appels de fonction en C++ sont
lents et ne peuvent être inlinés (on parlait d'optimisation par le compilateur
?).
Alors OUI, python n'est pas parfait, Oui il a des défauts, le plus gros étant
qu'il ne code pas à ma place, ainsi je suis obligé d'aller au boulot et de
coder (parce que sinon je coderais à la maison pour le plaisir, ou je ferais
de l'escalade, ou je jouerais à Ryzom). Je vous demande juste une chose, ne
pas critiquer python sur des goûts personnels (l'indentation, le self, ...) ou
sur des fausses idées (python est lent. Oui, mais lent à quel point ?), mais
faites le sur des vrais points techniques, je peux en citer pleins :
- Python sucks en multithreadé à cause du GIL (cela se discute, mais globalement c'est vrai
pour les calculs cpu-bound)
- Déployer une application écrite en python c'est plus chiant qu'un bon gros
binaire Qt linké en statique. Sous windows un bon gros binaire Qt linké en
statique marche tout seul, alors que la même application en pytoolkit doit
contenir plusieurs fichiers, et il faut installer python, pytoolkit, toolkit
et dépendances du toolkit + pydependances du toolkit (ceux qui font du pygtk
doivent sourire en ce moment...). Bon, ca j'avoue que c'est super lourd...
- Python n'est pas un langage normé ISO (bon, celle-la me fait toujours rire,
mais peu avoir de la valeur), ceci impliquant aussi le prochain point,
- Python à au moins 6 implémentations différentes (Cython, UnladenSwallow,
Jython, IronPython, Pypi, Stackless), ayant toutes des différences de
comportement et de librairies, donc python n'est pas portable entre ses
différentes implémentations (bon, le C/C++ c'est pareil, hormis le C(++)
ansi sans utiliser la STL, c'est pas portable d'un compilo à un autre. C'est
encore plus vrai pour les libraries qui ne fonctionnent pas de la même
manière d'un système à un autre (Apple, quand tu packages !!!) et c'est la
plaie des systèmes de build (Mais ou est donc pkg-config sous Windows ?)
- Python sucks pour d'interfacer avec du C++ (alors qu'avec du C c'est très
simple) et cela parce que C++ sucks sur le name mangling et autres bêtises.
(Les symboles exportées par le compilateur peuvent être différents d'un
compilateur à l'autre. J'avoue que je ne sais pas exactement qu'elle est le
statut des normes à ce sujet)
Bon, je vais me coucher, vous pouvez moinser... A non, faut que je relise
l'orthographe avant... (et merde...)
Oui, mais bon, la radiosité dans Blender degage avec la version 2.50. Concretement la radiosité c'est vieux, moche, et il n'y a plus aucune recherche dans le domaine depuis plusieurs années.
Actuellement si tu veux faire du vrai éclairage globale (ce que blender ne fait absolument pas, il y a une ébauche dans le SVN, mais ce n'est pas à terme un des buts, il y a d'autres moteurs de rendu libre qui font cela très bien), il a les photons map et le path tracing. Et si tu acceptes de faire un truc completement cheaté, tu as l'ambiant occlusion (voir meme l'approximate ambiant occlusion) qui donnent des résultats bien meilleurs que la radiosité.
Rapidement, pour ceux que cela interesse:
La radiosité, on coupe la scene en pleins de petits *patch*, on calcule entre chaque patch la quantité d'energie transmise potentiellement et à partir d'un état initiale (De l'energie sur les sources de lumière), l'on fait propager cette energie de patch en patch. C'est un processus iteratif qui as plusieurs problemes :
- Cela peut etre super lent, et c'est global (Il faut donc charger TOUTE la scene en memoire et calculer le facteur de forme (la quantité d'energie transmise) entre chaque patchs de la scène.
- Plus les patchs sont gros, moins c'est précit, plus les patchs sont petits, plus c'est lent, très difficile de trouver un compromis.
L'ambiant occlusion fait la meme chose, mais en bien plus simple et plus rapide. Rappelez vous que le lancé de rayon les rayons partent de la camera et heurtent un objet de la scene. A ce point d'intersection l'on regarde si les sources de lumière sont visibles, si oui, le point est eclairé, sinon il est dans l'ombre.
En path tracing, normalement l'on relance des rayons dans toutes les directions pour tenir compte de l'eclairage indirecte (regardez sous votre table, il y a de la lumière, mais elle n'est pas éclairée directement par la lampe. En relancant des rayons dans toutes les directions, ils vont rebondir contre le mur qui lui est éclairé par la lampe et ainsi de l'energie va arriver sous la table.
Ca c'est le path tracing, et il s'agit du genre de méthode qui permet d'avoir des éclairages physiquement realiste. Blender ne fait pas encore cela (Je vous invite à jouer avec luxrender), car c'est COUTEUX en temps de calcul et cela produit generalement des images bruités (l'on relance les rayons dans pleins de direction au hasard, ce qui donne du bruit, et autant le bruit ne derange pas sur une image fixe, c'est horrible sur une animation, et donc il faut calculer TRES longtemps pour avoir une animation avec peu de bruit)
Blender fait de l'ambiant occlusion, le principe est presque le même que le path tracing, l'on lance des rayons aléatoire partout et l'on regarde juste le nombre de rayon qui ne rencontrent pas d'objets à une certaine distance. De cela on en deduit si l'objet est caché dans un coin ou dans un espace bien ouvert et l'on peut ajouter un peu de lumière (ou en enlever). Ici il y a encore du bruit, mais juste dans les zones de transition lumière/ombre, et le calcul est très peu couteux en temps, mais c'est physiquement faux.
Blender fait aussi de l'approximate ambiant occlusion, qui est une approximation de l'ambiant occlusion, très vite on approxime la géometrie de la scène par des disques et en ne s'interessant qu'aux disques proches, l'on regarde lequels sont en face du disque de surface que l'on essaye de mettre en lumière ( C'est bien expliqué là, mais c'est plus *scientifique* http://www.bigbuckbunny.org/index.php/approximate-ambient-oc(...)http://www.blender.org/development/release-logs/blender-246/(...) ) Cette méthode est une horreur d'un point de vue realisme physique, possede de nombreux arguments qu'il faut regler au petit bonheur la chance, mais a l'aventage d'étre très rapide et sans bruit.
Maintenant pour répondre au troll originale, rien n'empeche de faire un plugin pour blender qui affiche les scenes en SVG. Problème, comment affiches tu les effets de lumière ? Avec des dégradés complexes ? ...
PS: j'ai tendance à tutoyer de manière globale, bref, le tu ici signifies "l'humanité" ;)
En même temps si patrick_g devait détailler toutes les amélioration mineures pour les langages obsolètes que GCC supporte encore, et bien il aurait pas fini.
(On est vendredi hein ;)(J'aime pas le C++)(Je bosse avec tous les jours)(Comme George Abitbol aurait dis, monde de
En pratique cela veut donc dire que GCC fait la compilation et l'instanciation des templates pour chaque .o alors qu'il pourrait le faire seulement au link, donc un gain de temps qui pourrait étre sympa.
Et aussi, GCC pourrait-il faire l'instanciation de template C++ lors du link ? Et ainsi gagner un max de temps sur les 2000 .o qui instancient le meme template ?
Et autre question, quand on a 2000 .o qui instancient le meme template, comment GCC faisait-t-il avant, il dupliquait le code entre chaque .o et la duplication restait après le link ? (Mon dieu !)
A propos du link time optimisation, je me pose une question.
J'ai souvent tendance à écrire du code à grand coup d'inline dans les .h, par exemple dans le cas d'une libraire de gestion de vecteur, le .h contenant la definition de struct et toutes les méthodes en static inline. Evidament la compilation prend beaucoup de temps car si je modifie une unique ligne de code dans un .h inclue dans TOUT le projet, il faut recompiler tous les .o du projet et refaire le link.
Grace au link time optimisation, je devrais pouvoir simplement declarer mon interface de vector dans mon .h, mettre le code dans un .c, compiler mes .o et lors du link, il doit pouvoir inliner après coup non ? Donc je perd un petit peu en temps de link, mais j'y gagne surement en temps de compilation.
Et je vais meme etre plus bourin. Actuellement je declare toutes mes petites fonctions en static inline, mais finalement pourquoi ne pas laisser gcc faire correctement son travail et n'inliner que ce qui vaut vraiment le coup ? (Et en théorie il le sait mieux que moi ?)
Donc, la "bottom-line" devient plutot: verra-t-on dans les mois à venir la disparition des interface .h fourre-tout static inline au profit d'un code bien separé .h/.o et mieux optimisé ?
Autre question, GCC sera il capable d'eliminer (et informer) à propos de la présence de code mort/ fonction non appelée ?
Mon ibook g3 me suit depuis 2000 et il est toujours parfait ;) Alors oui, il est lent maintenant pour regarder une video, jouer, afficher les sites web 2.0 top moumoute, mais pour programmer, lire de la documentation, ..., lire mes mails en vadrouille, il est parfait ;) J'ai juste changé la batterie depuis.
Ha, et il s'est prit des chutes sympatiques, genre descendre un amphi marche par marche après une chute de 1m50. Il était en petit morceaux, j'ai tout emboité comme du lego et hop hop, il retourne au travail.
Par contre, il y a une chose qui me fait vraiment rire, c'est que l'on demande d'avoir moins de choix sur le matèriel a haute valeure ajouté, mais moi ce qui me choque vraiment c'est le rayon de mon supermarché dedié au rasage et brossage de dent. Plus d'une centaine de rasoir/brosse à dent/tube de dentifrice different... Et en plus en super embalé jetable...
Pourquoi avoir décidé de faire debut 2009 de nouvelles applications pour la gestion du son, la gestion des videos, la gestion des photos, ... alors que dans *presque* tout ces domaines il existait des applications qui, soit remplissaient le besoin, soit le remplissaient presque et ne demandaient qu'un petit peu de bonne volonté pour devenir compétitives...
Je cite par exemple Jokosher, pour le son, Pitivi pour la video. Pourquoi tout reprendre encore une fois de zéro ?
J'ai l'impression que depuis 4 ans c'est la folie du coté de ce type d'application avec tout le monde qui veut faire sa propre version dans son langage, quand il n'y a pas plusieurs application par langage (pour les logiciels de manipulation de film orientés G, de tete je peux citer pitivi (python), diva (mono), openshot (python), kino, ...)
Jokosher et Pitivi étant utilisables à l'époque de la création de Yorba, pourquoi ne pas avoir pris le partit de regrouper ces differents projets sous un meme meta projet ?
Je me permet d'ailleur une remarque dans la traduction, ce n'est pas typage statique, mais typage fort que jim nelson listait comme contrainte, ce qui change tout de meme beaucoup de chose, puisque en respectant les contraintes listées, Python (par exemple, mais on aurait pu prendre ruby, ou certains autres) correspond aux contraintes.
Bref, même si je comprend le plaisir de faire ce que l'on veut dans le langage de son choix (finalement c'est aussi cela le logiciel libre), je regrete à chaque fois les projets qui divergent juste pour des raisons de langage.
Pour les grosses modifications de la 2.5 il y a ma précedente depeche, qui est vraiment plus complète. la 2.5 alpha 1 c'est principalement de la stabilisation.
Je viens de trouver une autre feature nouvelle, le drag et drop. Mais pour l'instant cela ne permet que de dupliquer des objets dans la scene ou de copier coller des noms, mais pas d'ouvrir des fichiers blender ou des images depuis une autre application, donc l'interet (je trouve) est plutot limité.
Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même, mais tout ce qui tourne autour, notamment les entrées sorties et la BDD. De plus la plupart des fonctions PHP étant écrite en C derrière, PHP n'est pas si lent que cela (globalement le temps gagné se fera sur le temps de dispatch des instructions de la machine virtuelle, ce qui est proche d'être négligeable dans le cas d'une utilisation WEB standard où l'on fait principalement des appels de fonction de traitement de chaîne et de base de donnée).
Donc je ne suis pas convaincu pour le gain en vitesse. D'autant plus que l'on parle d'un gain de performance sur la partie qui peut être facilement dupliquée, il suffit de créer un serveur clone du premier et de repartir la charge entre les deux et c'est bon (enfin presque ;)
Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue. Je ne suis pas près à sacrifier la maintenabilité et la simplicité de développement pour un millième de seconde gagné à chaque requête.
A mon avis il serait plus rentable de payer pour auditer le code à la recherche d'algorithmes mal écrits / requêtes mal faite plutôt que de payer quelqu'un pour s'assurer que ce bordel fonctionne correctement ;) A partir du moment ou l'on utilise un langage comme PHP c'est que l'on à comprit que la perte en performance ce fait en échange d'un gain énorme en maintenabilité, portabilité et facilité de développement. Quitte à revenir en arrière, autant faire du web en C.
Sinon j'ai un exemple tout bête, il existe pour Python pyrex (ou cython) qui permet de compiler du code python en C. Le gain de performance est presque nul tant que l'on ne fournit pas des indications à pyrex sur le code (par exemple les types de données), mais à ce moment là ce n'est PLUS du python, c'est un autre langage au typage statique qui permet, du fait de son typage statique, des optimisations hardware intéressante.
Conclusion, soit HipHop prend du PHP pur et en fait du C++ et je ne vois pas le gain que cela peut apporter, soit HipHop définit un nouveau langage basé sur PHP et (attention troll), je trouve cela inutile car il y a pleins d'autres langage qui répondent à ce besoin (langage de plus/moins haut niveau avec typage statique permettant des optimisations agressives) et si j'avais à faire cela je n'aurais pas pris php comme base de départ (bouh, moche ;)
En lisant le titre, je me suis dis "chouette, une astuce top moumoute pour lire des videos avec mon laptop"
Et j'ai déchanté dans les premières ligne. Ce n'est pas un CPU limite ton truc ? Mon ordinateur le plus puissant de la maison est un athlon XP 2000+ (pas de sse2, pas de HT, 1.6ghz).
Sur ce athlon xp 2000+ je lis le flux OGG de bigbuckbunny en 1920x1080 sans soucis (cpu à fond par contre, avec -framedrop, il me saute une frame de temps en temps lorsque c'est vraiment trop dur.
Par contre sur ma config "presque limite" (un ibook g3@500 mhz), qui n'est limite dans la vie de tous les jours que pour les videos, c'est là que j'aurais aimé une astuce pour aller plus vite.
En plus, vu la machine que tu as, tu dois certainement avoir une *bonne* carte graphique derriere, essaye de voir si en changeant le plugin de sortie dans mplayer si tu ne multiplies pas les perfs par deux.
J'allucine de plus en plus sur ce que les gens qualifient de configuration limite...
Le problème de ce genre de méthode c'est cela casse la mise en page et que generalement la pluspart des sites ne sont absolument pas prevu pour fonctionner sans mise en page et sans couleur. Résultat c'est pire qu'avec les couleurs.
J'ai un g3 sous ubuntu (donc sans support de l'altivec) et TOUS les packages multi-medias que j'ai rencontrés sont compilés avec le support de l'altivec. J'en suis donc a recompiler la moitié de la distribution et je me demande si je ne vais pas passer à gentoo, tant qu'a tout recompiler, autant faire cela avec un systeme prevu pour.
Dans les bugs marrants aussi, est-ce que les applis 3D plantent lamentablement avec un ati 128 timed out ? (dans le cas ou tu as un g3 avec une ati 128 bien sur)
Sinon c'est que du bonheur ce laptop sous linux... Je dirais qu'à cette époque Apple faisait du bon materiel. Jusqu'a il y a 6 mois, je n'arrivais pas a trouver dans le commerce un portable pouvant le remplacer (2 kg, ecran 13", ~6 heure d'autonomie) à moins de 2000 euros... Je ne l'aurais remplacer pour rien au monde. Maintenant certaines marques commencent à faire du petit portable autonome pour moins de 700 euros, donc j'attend qu'il casse ;)
Il nous reste qu'à espérer que le en:Tone_mapping a été correctement fait par leur soins
Je serais curieux de connaitre ta definition de "correctement" pour du Tone_mapping. Mais je pense saisir une touche d'ironie là dedans ;)
Le Tone mapping est un processus qui vise à passer une information sur une gamme large vers une gamme reduite. Ou comment rendre un ensemble de nombres flottants entre 0 et +inf sur une echelle qui vas de 0 à 255 en entier.
Et ici le probleme c'est qu'il n'y a pas de "Bonne façon". Il existe de nombreuses méthodes, toute adaptées plus ou moins à certains besoins et qui ont toutes (ou presque) une quantité de réglages fins à effectuer en fonction de ce que l'on veut faire resortir de la photographie.
Donc si ils ont trouvés comment faire "correctement" du Tone_mapping automatiquement sans réglage de l'utilisateur --> faut breveter (ou alors, plus gentil, faites une publication dans une conf publique !)
[^] # Re: Pourquoi les gens critiquent toujours python avec de mauvais argumen
Posté par Guillaum (site web personnel) . En réponse au journal Journal inutile : Python c'est complêtement pourri, j'ai un exemple. Évalué à 1.
# Pourquoi les gens critiquent toujours python avec de mauvais argument
Posté par Guillaum (site web personnel) . En réponse au journal Journal inutile : Python c'est complêtement pourri, j'ai un exemple. Évalué à 2.
Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited.
(pour communicate)
et
Warning Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.
pour stdout/stdin/stderr
Comme il n'y a pas d'autre moyen de communiquer avec le sous processus, je fais quoi si je ne veut pas deadlocker et si j'ai BEAUCOUP de donnée ?
[^] # Re: antidote
Posté par Guillaum (site web personnel) . En réponse au journal Ubuntu et Btrfs. Évalué à 2.
[^] # Re: TL;DR
Posté par Guillaum (site web personnel) . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 3.
[^] # Re: Une vraie question
Posté par Guillaum (site web personnel) . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 0.
Agree pour boost python, c'est un peu fastidieux, mais cela fait le boulot (Mais je suis tellement fan de la simplicité de cytpes...)
Pour les 30 minutes de compilation, je suis d'accord c'est un cas extrême. Mais même 1 minute, quand t'es en pleine phase d'essais/erreurs, c'est trop. Après cela ne veut pas forcement dire que ton programme python prendra des heures à se lancer. L'import d'un module python qui sera utilisé N fois ne se fait qu'une fois. L'instanciation d'un template qui sera utilisé par N différents types par M différents fichiers .cpp se fait un nombre compris entre N et N*M fois.
Pour les [] versus .at() versus C/python, oui, j'avoue, en effet, at sera toujours plus rapide en C++ qu'en python, rien à dire la dessus. Ce que je voulais soulever c'est qu'a force d'ajouter des couches en C++ pour faire comme en Python (ou ruby, ou autre chose), cela à un cout de performance. Si l'on est près à payer ce cout de performance (qui n'est pas négligeable, je récite mon exemple sur les fonctions virtuelles qui pouvent détruire les performances d'un programme), pourquoi ne pas utiliser python (ou ruby, ou...).
Mon problème n'est pas forcement le C++, mais plutôt le mauvais usage de celui-ci. Il est vrai qu'il y a des cas particuliers qui nécessitent l'utilisation du C++ et je ne suis pas en guerre contre les gens qui ont fait ce choix de façon raisonnée, j'essaye plutôt d'ouvrir les yeux à ceux qui le font sans réfléchir, ou avec de faux arguments. C'est comme le débat Maya/Blender (ou Windows/Linux). Je n'ai rien contre celui qui utilise Maya parce que celui-ci est plus pratique pour certains cas de figure. J'ai quelque chose contre celui qui crache sur Blender en disant que Maya est mieux parce que c'est professionnel et puis de tout manière je m'en cogne, je le pirate.
Pour ton assertion "C++ plus facile pour travailler en entreprise". Je dirais que oui, sur un CV cela le fait mieux (par contre python ou ruby ça peut faire de toi l'élément qui se démarque dans la masse de +/- bon développeurs C++). Pour l'efficacité du travail, cela dépend à mon sens de savoir si tu bosses avec des gens compétents et avec de la rigueur ou pas ? Et je suis d'accord que quitte à faire des conneries, autant le faire avec un système à typage statique qui sera moins permissif. Maintenant, quand je bosse tout seul, je prend mes responsabilités et j'espère ne pas être mauvais. Et quand je m'entoure, j'essaye de m'entourer de gens compétents qui ne se laisseront pas avoir par le risque du typage dynamique et qui sauront profiter de ses avantages.
Pour ton problème d'encodage.
- Soit tu veux travailler sur des caractères et dans ce cas là il te faut faire une conversion et tu dois connaître le format d'entrée et de sortie (en l'imposant ou en demandant à l'utilisateur de le spécifier, si celui-ci ne suit pas cette règle, tu ne peux rien pour lui) et dans ce cas là rien ne t'empêches de convertir son iso-42 en unicode puis en iso-42 (en supposant qu'il existe une fonction de conversion ;)
- Soit tu n'as pas besoin de travailler sur les caractères, et tu peux travailler sur un bytes (le type python3 ~ char[]) et ainsi il n'y aura pas de caractère qui disparaît en sortie.
L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.
- Tu peux bidouiller tes chaînes à coup d'opérateurs de bit, après il faut voir si cela à un sens (sur une chaîne char[], certainement, et encore je ne vois pas grand chose à faire de plus que le changement de case avec ^ (1 << 5))
- Tu peux décharger des modules, après faut voir si cela à un sens
- Tu peux faire de la programmation de carte graphique en Python ;)
- Tu peux aussi te demander en C++ si les 30 lignes que tu as écris seront aussi rapide que du Python (Je pense par exemple au hashmap qui n'existent pas dans la STL). Je joue souvent un jeu marrant avec mes collègues, élèves ou autre qui me disent que python est lent, je leur demande de me fournir un bout de code C++ qui est selon eux rapide et un bout de code python qui est selon eux lent. Très souvent je peux récrire leur bout de python pour qu'il soit plus rapide que leur bout de C++ (bon, je peux aussi récrire le bout de C++ pour qu'il soit plus rapide que le bout de Python ;)
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces.
Je me demande aussi, mais figure toi que j'ai aussi ce problème. Je ne fais presque jamais d'erreur de syntaxe en Python, je passe mon temps à en faire en C++... Mais je suis certainement biaisé en C++ du fait de mon expérience python. (Enfin j'ai fais plus de C++ dans ma vie que de python...)
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Ça c'est (à mon avis) un faux argument. Pourquoi ré-indenter ? Cela signifie que ton indentation n'a qu'une valeur cosmétique, donc cela ne sert a rien d'indenter. Si cela ne sert a rien, pourquoi le faire non ? Donc cela sert à quelque chose. Donc il faut indenter, et tous indenter de la même manière au sein d'un projet, donc l'indentation a un sens ? Tient, ce sens est vraiment proche des blocs que je délimite par des {} et ;. C'est meme tellement proche que je me demande pourquoi je duplique l'information... En fait l'indentation significative : "ça permet de remettre facilement les {}; avec un outil tel que GNU jemetlesaccollades"
[^] # Re: Une vraie question
Posté par Guillaum (site web personnel) . En réponse au journal QML: le futur des interfaces graphiques. Évalué à 7.
pythoneux qui ne supporte pas que l'on dise du mal du meilleur langage du
monde (Lisez tout de même la suite avant de moincer, j'ai essayé de mettre des
arguments)
* Le python n'est pas un langage compilé, j'aime bien les langages
compilés. Ça permet de faire des mini-pauses pendant la compilation, et on a
pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une
concaténation entre un string et un nombre).
Pour les minis pauses, je suis tellement d'accord. Sauf qu'ici au boulot c'est
des pauses de 30 minutes chaque fois que l'on change un commentaire dans le
fichier .h qui contient le template de base du système...
Sinon, pour le coté erreurs en pleins milieu, les autres l'on déjà dis, tu
confond la compilation et le tapage statique. Java est aussi un langage
interprété et pourtant tu as des erreurs au milieu du programme.
Mais en pratique en C++ tu as aussi des erreurs en milieu du programme que la
*compilation* ne réglera jamais. Par contre l'interpréteur peut être plus
malin que ton CPU en te renvoyant une erreur plus précise (genre unbound acces
en lieu et place de segfault). Mais j'avoue qu'avec une utilisation correcte
de la STL, tu n'as plus de segfault (enfin presque). Mais cette utilisation
correcte de la STL revient à rendre C++ aussi lent (enfin presque) que
Python...
* Le python ne permet pas de gérer manuellement la mémoire. Le ramasse
miettes, je n'accroche pas du tout. Surtout qu'avec une bonne architecture
du programme, on ne rencontre pas beaucoup de problèmes de gestion mémoire
en C++.
Chacun ses goûts. Je suis en grande partie d'accord avec toi quand je fais de
la programmation qui se doit d'être *vraiment* (cf plus loin) le plus rapide
possible.
Mais dans 99.9% des cas (chiffre au pif), quel est le besoin de gérer
l'allocation mémoire ? Tout le monde ici programme des fusées (Et encore, je
ne métrais pas de C++ dans les fusées), Tout le monde ici fait de la synthèse
d'image temps réel ? (Et encore, on peut en faire en python). Bon, donc sauf
si j'ai raté la dernière révolution, la plupart des code développés n'ont PAS
besoin de performances dingues, et n'ont PAS besoin de gestion fine de la
mémoire. Dans le cas particulier de l'article que l'on commente, l'on parle de
conception d'interfaces graphiques. Ici, 99.9% (chiffre au pif, certainement
surévalué) du temps CPU se passe dans le code du toolkit graphique et celui-ci
doit certainement faire une bonne partie des allocations mémoires (voirs peut
être 99.9% de celles-ci). Je connais mal Qt mais du peu que j'en ai fais en
C++, je ne me rappel pas avoir passé la moitié de la journée à faire des
malloc.
Et puis, tu dis aimer gérer toi même la mémoire, mais combien de personnes
utilisent une malloc alternative, combien de personnes surchargent le
paramètre alloc des templates de la STL ? Combien de personnes surchargent
l'opérateur new de la STL ? Si tu ne fais pas cela, alors tu ne peux pas
prétendre aimer gérer la mémoire.
De son coté, le GC de python, son job est de faire un malloc (si nécessaire)
quand tu crée un objet et nettoyer la mémoire (si il juge cela pertinent)
quand tu n'as plus besoin de cet objet. Alors oui, l'on ne maîtrise rien, mais
maitrise-t-on moins qu'avant ? Que faut-t-il craindre du GC de python ? Il
fait un travail fastidieux à notre place, en faisant moins d'erreur et
potentiellement plus rapide (du fait du pool de mémoire qui est réutilisé). Il
faut juste savoir l'utiliser correctement (ne rien faire) et si l'on veut une
utilisation avancé, il est aussi possible de l'utiliser de façon avancé (en
désactivant le GC de recherche de références cyclique et en ne laissant que le
compteur de référence qui ne consomme virtuellement rien)
* Pas de typage explicite des variables. C'est super pénible de ne pas savoir
quelle est le type de la variable que l'on a à gérer.
Goût et couleurs... Personnellement je ne m'intéresse pas à la variable ni à
son type, mais à ses capacités. Note que rien ne t'empêches en python de faire
du typage static.
Tu peux par exemple "décorer" tes arguments de fonctions:
def tortue(a:int, b:float)->float
Ensuite libre à qui veut de faire ce qu'il veut avec cela (je m'en sert pour
documenter les valeurs). Mais avec cela, tu n'as aucun problème pour faire de
la vérification de type au run-time, ou, un peu plus dur, écrire un
vérificateur de type statique. J'avoue, dans certains cas cela sera un peu
sioux ;)
Mais le problème ici, c'est que l'on s'en fout car l'on vois les types
de façon différente, plus comme une interface implicite :
Prenons un exemple. Tu est le gérant d'un bar. Un blanc entre dans le bar, tu
as prévu d'ouvrir le bar aux blancs, donc tu lui verses sa bière.
Un black (Il faut dire black pour être non raciste aujourd'hui) entre dans le
bar. Tu avais prévu que les blancs, mince. Comme t'es pas raciste, tu changes
ta porte d'entrée pour laisser passer les "buveurs", et tu demandes à tes
clients de se faire référencer comme buveur. Tu peux donc tout Homme se
présentant comme un buveur.
Un alien entre dans ton bar, et te demande à boire. Il n'a pas l'interface
buveur (son vaisseau vient de s'écraser devant ton bar, personne sur terre ne
connais l'existence de cette race d'arien, donc personne n'a pensé à le
rajouter dans le fichier des espèces qui boivent... Mais il a soif et te
montre de façon insistance avec sa tentacule la bouteille de bière. Pas
d'interface buveur, il ne bois pas. C'est ainsi que commencera la première
guerre universel (A lire, universal war one, très bonne BD sur ce sujet, enfin
presque).
Alors oui, on pourrait dire que c'est préférable de l'empêcher de boire si
l'on ne sait pas si il peut boire (imagine, il se trompe et cela le tue...).
C'est deux façon de voir les choses et je préfère rendre responsable les
développeurs que de rendre responsable le code. Le résultat étant le même à la
fin, soit c'est bon et cela passe, soit cela te pète à la gueule (au runtime
ou à la vérification statique). D'un coté tu t'es embêté à écrire du code
complexe, de l'autre t'as mis en place une procédure pour que cela pète au
runtime chez toi et pas chez le client (des tests par exemple). Comprendra qui
veut (Personnellement je préfère ne pas m'embêter en codant et écrire des
tests, parce que les tests, j'aurais honte de fournir du code au client qui
n'est pas testé... Donc entre écrire des tests et m'embêter en codant, ou juste
écrire des tests (et en plus sans m'embêter à les écrire...), le choix est
vite fait)
Le problème ici c'est que python ne manque pas d'une fonctionnalité de typage,
c'est juste une façon différente de voir les choses.
* Le self comme argument dans les méthodes de classes, c'est vraiment très
très moche comme hack, et les messages d'erreurs sont faussés (quand il
manque des arguments, le nombre d'arguments comprend le self, alors que l'on
ne doit pas le préciser avec la syntaxe classique).
Problème de goût et erreur de compréhension. Personnellement je trouve que le
this implicite en C++ c'est très moche comme hack (mon dieu, il vient d'où ?).
Après pour l'histoire du self, il n'y a pas de message d'erreur faussés, juste
une habitude que tu as pris d'ignorer dans le compte des arguments l'instance
concerné
toto.doit(5)
pour moi c'est une fonction (C.doit) qui prend deux arguments, toto et 5. C
sera dynamiquement déduit du type de toto (en l'occurrence, toto.doit(5) est
juste un raccourci syntaxique pour:
toto.__class__.doit(toto, 5)
avec toto.__class__ = C
Et là ou le système de type est intéressant, c'est que la classe C est finalement
juste un gros namespace de fonction travaillant sur des objets equivalents,
mais rien ne t'empeches de faire:
titi = B() # b n'a RIEN a voir avec C dans l'arbre d'héritage
C.doit(titi, 5)
En C++, on appelle cela les templates... En python on appelle cela le
dynamisme, mais en pratique les deux langages font la même chose...
Personnellement, je n'ai jamais compris pourquoi les autres langage ne
faisaient pas comme cela (pour le self/this). Et même avant que je connaisse
python, je ne comprenais pas. Quand j'ai découvert python, j'ai bondi de joie
au plafond en hurlant "Mon dieu, enfin des gens logiques qui pensent comme
moi"... Donc loin d'un hack immonde, c'est encore une fois un problème de
façon de voir les choses (même si le hack immonde, il faut être fou pour ne
pas se rendre compte qu'il est dans le langage C++ ;)
D'ailleurs, on va pousser un peu. Supposons une classe A et une
classe fille B ayant tout les deux une méthode "blork", Dans B.blork tu veux
appeler le A.blork sur l'instance courante...
En java tu utiliseras "inherited", bon, ok, java n'as pas d'héritage multiple
(en bien ou en mal), donc cela fonctionne très bien (je trouve cela juste
dommage d'introduire un nouveau mot clé dans le langage pour cela...)
En C++, tu utilises l'opérateur de portée de classe:
void B::blork()
{
A::blork();
}
Donc ici de façon implicite, A::blork est appelée avec le contexte. Mais si tu
utilises A::blork() en dehors de la classe B, et bien cela risque de ne pas
fonctionner non ?
En python tu verras simplement A.blork(self) que tu sois DANS l'instance le
code de la classe B ou en dehors (sauf que en dehors tu n'écrira pas de
variable nommée self ;)
Autre exemple. Tu écris une fonction qui travaille sur un objet de classe A,
et qui fait un truc
def mafonction(something):
assert(is_instance(something, A))
#dosomething with something
Note qu'ici je vérifie le type, pour le sport.
Puis après, tu obtient le pouvoir d'intégrer ta fonction au sein de la classe
A. Et bien tu n'as rien à changé, le prototype reste le même (faut renommer
self en something partout pour que cela soit joli, mais sinon c'est la même
chose).
Je ne parle pas de simplicité pour le refactoring ou autre hein (en C++ c'est
presque aussi simple en C++), je parle de cohérence. En C++ ce n'est pas du
tout la même chose, en python c'est toujours une fonction, il n'y à rien de
changé. En c++ il y a des namespaces, des classe, des fonctions, des méthodes
statiques, des méthodes d'instance. En python l'on fait la même chose
simplement avec des namespaces et des méthodes.
* On ne peut pas modifier un caractère d'une chaîne de caractère, obligé de
* faire une copie.
C'est un choix qui semble logique de mon coté. Une chaîne de caractère tient
sa valeur de son contenu, tu changes le contenu, tu changes la chaîne. Mais
sincèrement, on s'en cogne pas un peu ? Je crois que je n'ai jamais changé
un caractère dans une chaîne... A la limite plusieurs, mais cela change
complètement l'algo derrière, et j'avoue être plutôt heureux que python me
l'interdise ;)
Et si vraiment tu n'est pas content, libre à toi d'écrire un type
mutablestring basé sur les listes voir même sur les chaînes. Cela prend 5
minutes. Mais je n'en vois pas l'intérêt.
Les exceptions pour les jeux de caractères, ça me gonfle.
Précise ta remarque ? Les exceptions que j'ai eu en python étaient toutes liés
à une erreur de ma part. Une fois que tu as compris qu'il faut toujours
travailler en unicode (ou str dans python3), sauf pour les entrées sorties ou
tu converties en str (ou bytes dans python3) ou les traitements qui n'ont pas
de valeur de chaîne de caractère, il n'y a plus de problème.
On parlait tout a l'heure de vérification à la compilation, du fait que le
typage apportait un lot de sécurité, bla bla bla... Et bien ici python
t'apporte le fait que si tu fais des bêtises avec ta chaîne de caractère, il
te hurle dessus pour éviter que tu ne vois pas que la sortie est remplie de
petits '?', certes très jolis. Python est ici plus sécurisé que le C++, sans
être embêtant...
De toute façon ici l'on ne peut pas comparer avec C++, la lib standard C++ ne
gère pas l'un code, donc de toute façon tu n'aurais jamais eu ses erreurs en
C++, mais ce n'est pas forcement pour une bonne raison. C++ 0x apportera un
vrai support des chaînes de caractère, donc rassurez vous, cet argument en
faveur de python ne sera plus dans quelques années, à en juger par
l'implémentation du C99 sur les grands compilateurs du marché, au moins 10 ans ;)
L'impression générale d'être limité à une utilisation en haut niveau.
Précise ? Oui tu ne feras jamais un OS en python (et encore, cela pourrait
être marrant), mais quelles sont tes contraintes bas niveau ?
Personnellement je fais de l'OpenGL/Cuda/OpenCL tous les jours avec, et je
trouve que c'est suffisamment bas niveau...
Maintenant oui, j'accepte cet assertion, cependant revenons au débat sur Qt,
personnellement je m'en fout de toucher mes registres à la main, de faire du
(S/M)IMD, de gérer ma gestion de lignes de cache du CPU, de savoir comment mes
pages mémoires sont swapées. ON fait de la GUI là... On est en 2010, combien
de personnes, à part les gens qui font du système ou de l'image ont besoin
d'autant de bas niveau ?
Alors oui, quand j'ai besoin de bas niveau (mon dieu, il y a quoi dans mon
cache L2 !!!) Je fais du C (et du C++ quand vraiment je fais un gros truc et
que j'ai besoin d'une syntaxe objet plus légère que celles possibles en C),
mais quand je fais une gui, avec C++ j'ai "l'impression générale d'être limité
à une utilisation de bas niveau".
Puis l'indentation obligatoire, c'est super pénible. Surtout quand on
* reprends le code d'une autre personne, ou que l'on a juste commenté une
* condition.
C'est personnel. Moi je ne supporte plus les accolades et points virgules et
bien que j'ai plus d'années d'expériences en C/C++ que python, n'oublies
encore pleins de ;, mais je n'oublies jamais d'intenter mon code...
Quand j'enseigne la programmation à la fac ou en école d'ingé Je passe les 3/4
de mes séances C/C++/Pascal à rajouter des {};begin/end... J'ai la chance
d'avoir quelques groupes d'enseignement en Python, et bien je n'ai jamais* eu
de problème avec l'indentation et la syntaxe du langage.
* Une fois un élève qui à changé la configuration de son éditeur de texte pour
l'indentation et qui est passé soudain de 4 espaces à un tab... Un beau
bordel, j'avoue. Mais une fois ce détail connu pour une utilisateur averti,
il suffit d'un peu de rigueur (et d'un éditeur bien configuré) et ce problème
devient un souvenir.
Pour les commentaires de conditions, j'avoue, c'est peu pratique (enfin en C
tu est aussi forcé de supprimé les accolades ouvrantes et fermantes, sauf si
tu acceptes la déclaration d'un nouveau bloc, ce qui, j'avoue, à peu
d'implications, sauf si il reste encore le else après et là t'es eu...
Personnellement, j'ai une macro $EDITOR pour chercher le if le plus proche, et
cycler entre:
if condition:
#TODO if condition:
if True:
#TODO if condition:
if False:
Et elle est adaptée d'une macro pour le C que j'avais avant qui faisait la
même chose, car je n'ai pas trouvé mieux (je suis preneur).
Ce que j'aime bien dans les langages compilés sinon, c'est l'optimisation
automatique du code (en python, on perd la documentation quand on veut
optimiser). Gcc va vraiment plus optimiser, et même en fonction de
l'architecture de la machine.
Avec un langage interprété, effectuer les mêmes optimisations serait possible,
mais ce serait aussi bien trop lent à exécuter.
La suppression de documentation n'optimise pas plus, elle réduit seulement la
taille du fichier. Tu as deux flag en python, -O et -OO pour optimiser. -O ne
fait pas grand chose (principalement, il supprime les assert et la variable
__debug__) et -OO supprime la documentation. Si tu veux optimiser, python
n'est vraiment pas la bonne solution.
Et là je vais revenir sur le débat de la mémoire. ON s'en COGNE des
optimisations. On fait de la GUI ici hein, de la GUI ! Le truc pour lequel le
toolkit bouffe 99.9% de ton temps CPU pour dessiner des fenêtres à l'écran. Le
truc ou l'élément limitant en terme de performances et de réactivité c'est
l'utilisateur, la carte graphique, le serveur d'affichage et le toolkit.
Et puis pour la plupart on fait de la GUI qui affiche les
résultats qui sortent d'une BDD, le truc qui va prendre un temps de fou pour
revenir, parce que une BDD c'est des milliers de cycle CPU pour ramener une
petite donnée, c'est comme cela. Et on fait de la gui qui va lire et charger
des fichiers Image, qui va prendre quelques milliers de cycle CPU pour
décompresser le jpeg. Tout cela est déjà écrit et est lent, et sera toujours
plus lent que 10 appels de fonction dans python pour connecter ton évènement
clique de bouton sur la fonction de décompression de JPEG.
Alors oui, python prendra quelques cycles CPU de plus que C++ dans la boucle
principale, cycles qui sont négligeables à cote de ceux nécessaire au toolkit
pour afficher ta fenêtre. Alors OUI, je ne ferais jamais un toolkit en python,
ou une librairie de décompression JPEG, (et encore... faut voir ;)), mais
quand l'on parle d'utilisation de librairies qui existent déjà.
Et puis l'on parle d'optimisation et de C++, j'en rigole tous les jours. Du
fait des mécanismes d'héritage virtuel, les appels de fonction en C++ sont
lents et ne peuvent être inlinés (on parlait d'optimisation par le compilateur
?).
Alors OUI, python n'est pas parfait, Oui il a des défauts, le plus gros étant
qu'il ne code pas à ma place, ainsi je suis obligé d'aller au boulot et de
coder (parce que sinon je coderais à la maison pour le plaisir, ou je ferais
de l'escalade, ou je jouerais à Ryzom). Je vous demande juste une chose, ne
pas critiquer python sur des goûts personnels (l'indentation, le self, ...) ou
sur des fausses idées (python est lent. Oui, mais lent à quel point ?), mais
faites le sur des vrais points techniques, je peux en citer pleins :
- Python sucks en multithreadé à cause du GIL (cela se discute, mais globalement c'est vrai
pour les calculs cpu-bound)
- Déployer une application écrite en python c'est plus chiant qu'un bon gros
binaire Qt linké en statique. Sous windows un bon gros binaire Qt linké en
statique marche tout seul, alors que la même application en pytoolkit doit
contenir plusieurs fichiers, et il faut installer python, pytoolkit, toolkit
et dépendances du toolkit + pydependances du toolkit (ceux qui font du pygtk
doivent sourire en ce moment...). Bon, ca j'avoue que c'est super lourd...
- Python n'est pas un langage normé ISO (bon, celle-la me fait toujours rire,
mais peu avoir de la valeur), ceci impliquant aussi le prochain point,
- Python à au moins 6 implémentations différentes (Cython, UnladenSwallow,
Jython, IronPython, Pypi, Stackless), ayant toutes des différences de
comportement et de librairies, donc python n'est pas portable entre ses
différentes implémentations (bon, le C/C++ c'est pareil, hormis le C(++)
ansi sans utiliser la STL, c'est pas portable d'un compilo à un autre. C'est
encore plus vrai pour les libraries qui ne fonctionnent pas de la même
manière d'un système à un autre (Apple, quand tu packages !!!) et c'est la
plaie des systèmes de build (Mais ou est donc pkg-config sous Windows ?)
- Python sucks pour d'interfacer avec du C++ (alors qu'avec du C c'est très
simple) et cela parce que C++ sucks sur le name mangling et autres bêtises.
(Les symboles exportées par le compilateur peuvent être différents d'un
compilateur à l'autre. J'avoue que je ne sais pas exactement qu'elle est le
statut des normes à ce sujet)
Bon, je vais me coucher, vous pouvez moinser... A non, faut que je relise
l'orthographe avant... (et merde...)
[^] # Re: Non
Posté par Guillaum (site web personnel) . En réponse au journal Des films en vectoriel ?. Évalué à 10.
Actuellement si tu veux faire du vrai éclairage globale (ce que blender ne fait absolument pas, il y a une ébauche dans le SVN, mais ce n'est pas à terme un des buts, il y a d'autres moteurs de rendu libre qui font cela très bien), il a les photons map et le path tracing. Et si tu acceptes de faire un truc completement cheaté, tu as l'ambiant occlusion (voir meme l'approximate ambiant occlusion) qui donnent des résultats bien meilleurs que la radiosité.
Rapidement, pour ceux que cela interesse:
La radiosité, on coupe la scene en pleins de petits *patch*, on calcule entre chaque patch la quantité d'energie transmise potentiellement et à partir d'un état initiale (De l'energie sur les sources de lumière), l'on fait propager cette energie de patch en patch. C'est un processus iteratif qui as plusieurs problemes :
- Cela peut etre super lent, et c'est global (Il faut donc charger TOUTE la scene en memoire et calculer le facteur de forme (la quantité d'energie transmise) entre chaque patchs de la scène.
- Plus les patchs sont gros, moins c'est précit, plus les patchs sont petits, plus c'est lent, très difficile de trouver un compromis.
L'ambiant occlusion fait la meme chose, mais en bien plus simple et plus rapide. Rappelez vous que le lancé de rayon les rayons partent de la camera et heurtent un objet de la scene. A ce point d'intersection l'on regarde si les sources de lumière sont visibles, si oui, le point est eclairé, sinon il est dans l'ombre.
En path tracing, normalement l'on relance des rayons dans toutes les directions pour tenir compte de l'eclairage indirecte (regardez sous votre table, il y a de la lumière, mais elle n'est pas éclairée directement par la lampe. En relancant des rayons dans toutes les directions, ils vont rebondir contre le mur qui lui est éclairé par la lampe et ainsi de l'energie va arriver sous la table.
Ca c'est le path tracing, et il s'agit du genre de méthode qui permet d'avoir des éclairages physiquement realiste. Blender ne fait pas encore cela (Je vous invite à jouer avec luxrender), car c'est COUTEUX en temps de calcul et cela produit generalement des images bruités (l'on relance les rayons dans pleins de direction au hasard, ce qui donne du bruit, et autant le bruit ne derange pas sur une image fixe, c'est horrible sur une animation, et donc il faut calculer TRES longtemps pour avoir une animation avec peu de bruit)
Blender fait de l'ambiant occlusion, le principe est presque le même que le path tracing, l'on lance des rayons aléatoire partout et l'on regarde juste le nombre de rayon qui ne rencontrent pas d'objets à une certaine distance. De cela on en deduit si l'objet est caché dans un coin ou dans un espace bien ouvert et l'on peut ajouter un peu de lumière (ou en enlever). Ici il y a encore du bruit, mais juste dans les zones de transition lumière/ombre, et le calcul est très peu couteux en temps, mais c'est physiquement faux.
Blender fait aussi de l'approximate ambiant occlusion, qui est une approximation de l'ambiant occlusion, très vite on approxime la géometrie de la scène par des disques et en ne s'interessant qu'aux disques proches, l'on regarde lequels sont en face du disque de surface que l'on essaye de mettre en lumière ( C'est bien expliqué là, mais c'est plus *scientifique* http://www.bigbuckbunny.org/index.php/approximate-ambient-oc(...) http://www.blender.org/development/release-logs/blender-246/(...) ) Cette méthode est une horreur d'un point de vue realisme physique, possede de nombreux arguments qu'il faut regler au petit bonheur la chance, mais a l'aventage d'étre très rapide et sans bruit.
Maintenant pour répondre au troll originale, rien n'empeche de faire un plugin pour blender qui affiche les scenes en SVG. Problème, comment affiches tu les effets de lumière ? Avec des dégradés complexes ? ...
PS: j'ai tendance à tutoyer de manière globale, bref, le tu ici signifies "l'humanité" ;)
# Tort ? Interets
Posté par Guillaum (site web personnel) . En réponse au journal freebox et les licences libres : vers une traduction de la GPL. Évalué à 2.
Oui, pas d'argumentation, j'avoue que je ne sais pas et que tous les arguments des deux partis me semblent valablent.
[^] # Re: Dépêche incomplète !
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 1.
(On est vendredi hein ;)(J'aime pas le C++)(Je bosse avec tous les jours)(Comme George Abitbol aurait dis, monde de
[^] # Re: LinkTimeOptimisation
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 1.
En pratique cela veut donc dire que GCC fait la compilation et l'instanciation des templates pour chaque .o alors qu'il pourrait le faire seulement au link, donc un gain de temps qui pourrait étre sympa.
[^] # Re: LinkTimeOptimisation
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 1.
[^] # Re: LinkTimeOptimisation
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 3.
Et autre question, quand on a 2000 .o qui instancient le meme template, comment GCC faisait-t-il avant, il dupliquait le code entre chaque .o et la duplication restait après le link ? (Mon dieu !)
# LinkTimeOptimisation
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GCC 4.5. Évalué à 4.
J'ai souvent tendance à écrire du code à grand coup d'inline dans les .h, par exemple dans le cas d'une libraire de gestion de vecteur, le .h contenant la definition de struct et toutes les méthodes en static inline. Evidament la compilation prend beaucoup de temps car si je modifie une unique ligne de code dans un .h inclue dans TOUT le projet, il faut recompiler tous les .o du projet et refaire le link.
Grace au link time optimisation, je devrais pouvoir simplement declarer mon interface de vector dans mon .h, mettre le code dans un .c, compiler mes .o et lors du link, il doit pouvoir inliner après coup non ? Donc je perd un petit peu en temps de link, mais j'y gagne surement en temps de compilation.
Et je vais meme etre plus bourin. Actuellement je declare toutes mes petites fonctions en static inline, mais finalement pourquoi ne pas laisser gcc faire correctement son travail et n'inliner que ce qui vaut vraiment le coup ? (Et en théorie il le sait mieux que moi ?)
Donc, la "bottom-line" devient plutot: verra-t-on dans les mois à venir la disparition des interface .h fourre-tout static inline au profit d'un code bien separé .h/.o et mieux optimisé ?
Autre question, GCC sera il capable d'eliminer (et informer) à propos de la présence de code mort/ fonction non appelée ?
[^] # Re: Apple, c’est autre chose…
Posté par Guillaum (site web personnel) . En réponse au journal Marre des portables à 100mille déclinaisons. Évalué à 7.
Ha, et il s'est prit des chutes sympatiques, genre descendre un amphi marche par marche après une chute de 1m50. Il était en petit morceaux, j'ai tout emboité comme du lego et hop hop, il retourne au travail.
Par contre, il y a une chose qui me fait vraiment rire, c'est que l'on demande d'avoir moins de choix sur le matèriel a haute valeure ajouté, mais moi ce qui me choque vraiment c'est le rayon de mon supermarché dedié au rasage et brossage de dent. Plus d'une centaine de rasoir/brosse à dent/tube de dentifrice different... Et en plus en super embalé jetable...
# Au hasard
Posté par Guillaum (site web personnel) . En réponse au journal Tutorial sur l'utilisation de Mercurial au quotidien. Évalué à 4.
http://gobpower.free.fr/howto_mercurial.html
Ca à le merite d'étre en français (approximatif, je viens de voir pleins de belles fautes ;), mais à ce jour je n'ai pas eu le moindre retour ;)
# "Edition video" in Synonymes("Roue") is True
Posté par Guillaum (site web personnel) . En réponse au journal Yorba et Vala. Évalué à 10.
Je cite par exemple Jokosher, pour le son, Pitivi pour la video. Pourquoi tout reprendre encore une fois de zéro ?
J'ai l'impression que depuis 4 ans c'est la folie du coté de ce type d'application avec tout le monde qui veut faire sa propre version dans son langage, quand il n'y a pas plusieurs application par langage (pour les logiciels de manipulation de film orientés G, de tete je peux citer pitivi (python), diva (mono), openshot (python), kino, ...)
Jokosher et Pitivi étant utilisables à l'époque de la création de Yorba, pourquoi ne pas avoir pris le partit de regrouper ces differents projets sous un meme meta projet ?
Je me permet d'ailleur une remarque dans la traduction, ce n'est pas typage statique, mais typage fort que jim nelson listait comme contrainte, ce qui change tout de meme beaucoup de chose, puisque en respectant les contraintes listées, Python (par exemple, mais on aurait pu prendre ruby, ou certains autres) correspond aux contraintes.
Bref, même si je comprend le plaisir de faire ce que l'on veut dans le langage de son choix (finalement c'est aussi cela le logiciel libre), je regrete à chaque fois les projets qui divergent juste pour des raisons de langage.
[^] # Re: Non, sérieux..
Posté par Guillaum (site web personnel) . En réponse au journal Blender 2.5 alpha 1. Évalué à 2.
Merci pour le compliment ;)
# DragnDrop
Posté par Guillaum (site web personnel) . En réponse au journal Blender 2.5 alpha 1. Évalué à 3.
# Pas convaincu
Posté par Guillaum (site web personnel) . En réponse au journal HipHop For PHP : Facebook php-to-C++ translator. Évalué à 1.
Je ne suis pas convaincu pour plusieurs raisons.
Actuellement, le goulot d'étranglement des performances ce n'est pas le PHP en lui même, mais tout ce qui tourne autour, notamment les entrées sorties et la BDD. De plus la plupart des fonctions PHP étant écrite en C derrière, PHP n'est pas si lent que cela (globalement le temps gagné se fera sur le temps de dispatch des instructions de la machine virtuelle, ce qui est proche d'être négligeable dans le cas d'une utilisation WEB standard où l'on fait principalement des appels de fonction de traitement de chaîne et de base de donnée).
Donc je ne suis pas convaincu pour le gain en vitesse. D'autant plus que l'on parle d'un gain de performance sur la partie qui peut être facilement dupliquée, il suffit de créer un serveur clone du premier et de repartir la charge entre les deux et c'est bon (enfin presque ;)
Maintenant ce genre de compilation de code risque de provoquer des incompatibilités et des problématiques de maintenance tordue. Je ne suis pas près à sacrifier la maintenabilité et la simplicité de développement pour un millième de seconde gagné à chaque requête.
A mon avis il serait plus rentable de payer pour auditer le code à la recherche d'algorithmes mal écrits / requêtes mal faite plutôt que de payer quelqu'un pour s'assurer que ce bordel fonctionne correctement ;) A partir du moment ou l'on utilise un langage comme PHP c'est que l'on à comprit que la perte en performance ce fait en échange d'un gain énorme en maintenabilité, portabilité et facilité de développement. Quitte à revenir en arrière, autant faire du web en C.
Sinon j'ai un exemple tout bête, il existe pour Python pyrex (ou cython) qui permet de compiler du code python en C. Le gain de performance est presque nul tant que l'on ne fournit pas des indications à pyrex sur le code (par exemple les types de données), mais à ce moment là ce n'est PLUS du python, c'est un autre langage au typage statique qui permet, du fait de son typage statique, des optimisations hardware intéressante.
Conclusion, soit HipHop prend du PHP pur et en fait du C++ et je ne vois pas le gain que cela peut apporter, soit HipHop définit un nouveau langage basé sur PHP et (attention troll), je trouve cela inutile car il y a pleins d'autres langage qui répondent à ce besoin (langage de plus/moins haut niveau avec typage statique permettant des optimisations agressives) et si j'avais à faire cela je n'aurais pas pris php comme base de départ (bouh, moche ;)
# *limite*
Posté par Guillaum (site web personnel) . En réponse au journal Lire de la vidéo HD avec une machine limite. Évalué à 9.
Et j'ai déchanté dans les premières ligne. Ce n'est pas un CPU limite ton truc ? Mon ordinateur le plus puissant de la maison est un athlon XP 2000+ (pas de sse2, pas de HT, 1.6ghz).
Sur ce athlon xp 2000+ je lis le flux OGG de bigbuckbunny en 1920x1080 sans soucis (cpu à fond par contre, avec -framedrop, il me saute une frame de temps en temps lorsque c'est vraiment trop dur.
Par contre sur ma config "presque limite" (un ibook g3@500 mhz), qui n'est limite dans la vie de tous les jours que pour les videos, c'est là que j'aurais aimé une astuce pour aller plus vite.
En plus, vu la machine que tu as, tu dois certainement avoir une *bonne* carte graphique derriere, essaye de voir si en changeant le plugin de sortie dans mplayer si tu ne multiplies pas les perfs par deux.
J'allucine de plus en plus sur ce que les gens qualifient de configuration limite...
[^] # Re: Super, un site de plus en dark
Posté par Guillaum (site web personnel) . En réponse au journal Feuille de style CSS pour LinuxFR. Évalué à 2.
# Super, un site de plus en dark
Posté par Guillaum (site web personnel) . En réponse au journal Feuille de style CSS pour LinuxFR. Évalué à 1.
Vivement le web sans style qui prenne les couleurs par defaut du navigateur, je vous le dis.
[^] # Re: Moi je trouve...
Posté par Guillaum (site web personnel) . En réponse au journal Méta-lancé de rayons. Évalué à 4.
Par contre j'adore le concept de definir une cornel box avec seulement des spheres (les murs *plans* sont aussi des spheres.
[^] # Re: Déjà essayé mais...
Posté par Guillaum (site web personnel) . En réponse au sondage MacOS X. Évalué à 2.
J'ai un g3 sous ubuntu (donc sans support de l'altivec) et TOUS les packages multi-medias que j'ai rencontrés sont compilés avec le support de l'altivec. J'en suis donc a recompiler la moitié de la distribution et je me demande si je ne vais pas passer à gentoo, tant qu'a tout recompiler, autant faire cela avec un systeme prevu pour.
Dans les bugs marrants aussi, est-ce que les applis 3D plantent lamentablement avec un ati 128 timed out ? (dans le cas ou tu as un g3 avec une ati 128 bien sur)
Sinon c'est que du bonheur ce laptop sous linux... Je dirais qu'à cette époque Apple faisait du bon materiel. Jusqu'a il y a 6 mois, je n'arrivais pas a trouver dans le commerce un portable pouvant le remplacer (2 kg, ecran 13", ~6 heure d'autonomie) à moins de 2000 euros... Je ne l'aurais remplacer pour rien au monde. Maintenant certaines marques commencent à faire du petit portable autonome pour moins de 700 euros, donc j'attend qu'il casse ;)
# Tone_mapping
Posté par Guillaum (site web personnel) . En réponse au journal Une liberté sur 360°. Évalué à 3.
Je serais curieux de connaitre ta definition de "correctement" pour du Tone_mapping. Mais je pense saisir une touche d'ironie là dedans ;)
Le Tone mapping est un processus qui vise à passer une information sur une gamme large vers une gamme reduite. Ou comment rendre un ensemble de nombres flottants entre 0 et +inf sur une echelle qui vas de 0 à 255 en entier.
Et ici le probleme c'est qu'il n'y a pas de "Bonne façon". Il existe de nombreuses méthodes, toute adaptées plus ou moins à certains besoins et qui ont toutes (ou presque) une quantité de réglages fins à effectuer en fonction de ce que l'on veut faire resortir de la photographie.
Donc si ils ont trouvés comment faire "correctement" du Tone_mapping automatiquement sans réglage de l'utilisateur --> faut breveter (ou alors, plus gentil, faites une publication dans une conf publique !)