On peut se permettre ça car en pratique, tu n'aura pas d'état inconsistant d'un registre entier (tous les bits sont basculés en même temps). Par contre, ça a un inconvénient si tu t'es planté pour l'attente, notamment pour le multi-coeur : un coeur se retrouve à monopoliser le bus d'accès mémoire, et peut donc empêcher ses petits camarades de travailler (donc il ne faut pas se planter).
[1] en fait il faut raffiner un chouilla plus, mais c'est l'idée.
« Ce qui est arrivé à Con, est arrivé à d'autres et aussi dans le domaine des serveurs. Vmware a essuié un refus il y a peu. IBM a aussi pris un refus pour son modèle de thread. Etc. »
Je ne sais pas si tu as lu l'article original, mais CK dit que son scheduler, qui pourtant avait été critiqué, a ensuite été adopté comme modèle, et récrit from scratch par d'autres dévs du noyau (ceux qui justement critiquaient son approche). C'est ça qui l'a fait craquer, plus que le refus en lui-même : le côté « non, on veut pas de ton truc car on pense que le concept ne convient pas, mais finalement l'idée est bonne, on va le refaire à notre sauce ».
Tu parles d'IBM, mais leur modèle de threads était plus flexible et performant que celui actuellement utilisé. Sauf que bon, comme le scheduler codé par un pote du mec qui a fait les NPTL, ben... Ils se sont arrangés pour que ça colle bien l'un avec l'autre (rendant l'un dépendant de l'autre, en fait), ce qui a nécessairement désavantagé les threads d'IBM...
« Bref, je suis 100% d'accord avec toi sur le fait qu'un client lourd est mieux coté perfs, mais pas la peine de donner des argument foireux contre les applis web... »
Pas seulement côté perfs. Gmail par exemple est plutôt bien foutu ergonomiquement parlant ; n'empêche, le temps de latence pour aller d'un mail à l'autre est insupportable si tu t'en sers de « client » principal. Franchement, si toutes les applications web étaient faites façon gmail & co, ce serait vraiment un grand pas en avant, mais c'est vraiment beaucoup, beaucoup moins bien qu'un client natif.
Tout ceci sans parler du fait que pour le moment, c'est (X)HTML+javascript, et que javascript c'est sympa quand tu veux faire quelques petits trucs, mais quand tu développes de GROS trucs, c'est un langage extrêmement difficile à debugger, comparé aux autres.
Dans le principe, si le langage pouvait inclure la notion de parallélisme ce serait évidemment mieux.
Après tout dépend du but. Dans le cas de « bêtes » sections parallèles, avec un modèle à la fork/join (comme pour OpenMP), du moment que cette section prend du temps et nécessite réellement du calcul avec des dépendances « lourdes » (qui nécessitent de la synchronisation), alors oui, pourquoi pas.
Mais dans le cas où tu peux t'arranger pour qu'il n'y ai pas de synchro ou presque (par exemple parce que tu peux évaluer - statiquement ou au lancement du programme - le nombre d'opérations qui vont être effectuées, à 0,1% près), et qu'en plus, tu dois absolument aller vite, il ne te reste plus que des langages type C, ou FORTRAN (OCAML me vient aussi à l'esprit, mais je n'ai pas l'impression qu'il y ait de vraies constructions pour le parallélisme dans le langage), car malheureusement, dans la plupart des papiers parlant de parallélisme que j'ai pu voir (et c'est aussi vrai pour les implémentations classiques d'OpenMP), il y a toujours des synchro lourdes dans le cas de déclarations plus ou moins explicites de sections parallèles.
Du coup, il va falloir que je teste un chouilla TBB, mais je pense que ça ne s'interfacera pas trop avec MPC ... :-)
« Tout est normal, l'OS est là pour utiliser au mieux les ressources. Si deux thread sont attachés à un même cpu »
Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre. Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux). Depuis l'ordonnanceur a moins la bougeote, mais il lui arrive encore de migrer un thread/processus d'un processeur à l'autre même lorsque ce n'est pas judicieux.
Depuis Bull a pondu les CPU sets, qui permet de dire exactement sur quel processeur virtuel (thread, coeur, processeur) tu veux « visser » un processus ou un thread (la différence entre les deux étant relativement minime, vu que dans tous les cas on appelle clone()).
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».
« Il y a changement de contexte s'il n'y a pas assez de cpu (le cpu est alors affecté à un autre thread qui en a besoin). On est dans le cas où il n'y a moins de cpu que de threads actifs/éligibles et au-lieu de laisser un cpu en attende d'un lock, on l'affecte à un autre thread. »
Je suis un peu sceptique. J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre, sans autre raison que l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...). Du coup je me demande si ce genre de comportement ne peut pas se reproduire -- mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
« *BSD a beaucoup de programme sous GPL. T'as des exemples de programme qui ont été contaminés par la GPL ? »
Si tu parles des systèmes d'exploitation BSD, tu as raison, ils embarquent aussi des softs sous GPL (GCC n'étant pas des moindres). Maintenant, c'est clairement plus parce qu'ils n'ont pas de main d'oeuvre pour faire leurs propres outils sous BSD.
make, par exemple, est fournie version BSD sur les systèmes, et est bien différenciée de gmake (qu'il faut explicitement installer).
« Je suis sûr que "message passing" doit utiliser un lock ou un semaphore. »
C'est vrai, mais c'est laissé au soin de l'implémentation d'une part, et souvent ça utilise les mécanismes matériels mis à disposition d'autre part. Sachant que le passage de message peut se faire en synchrone ou asynchrone.
« En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. »
Euh, tu es sûr de ton coup là ?
De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
De plus, dans un contexte plus restreint (le calcul haute performance, où les entrées/sorties sont rares), synchroniser comme un malade est souvent synonyme de mauvaises performances.
« Sont un peu maso quand meme pour openmp. autant partir sur du c et du pthread, parce que openmp je trouve ca assez porc, définir des macros etc... »
Sauf que la notion de thread en FORTRAN, ben ... Elle n'existe pas. D'où le besoin de machins genre OpenMP pour rajouter du parallélisme explicite à un langage qui ne connaît pas ça officiellement.
De plus, en utilisant les pragma en C ou les commentaires correspondants en FORTRAN, tu permets au compilateur de faire tout plein d'analyses en statique (pour peu que le compilateur sache en tirer parti, ce qui n'est pas du tout évident).
« Multicoeur c'est du multi-cpu. Au niveau appli/programmation on ne voit pas la différence. »
Ça dépend du type d'application. Lorsque deux coeurs partagent le même cache, la notion de localité des données peut prendre une grande importance. La notion de proximité des processeurs aussi, du coup (je pense par exemple aux stations de travail et serveurs SMP/CMP, genre bi-xeon core 2 duo).
Imagine que tu sois sur une station de travail bi-proc, bi-coeur. Tu es graphiste, et tu utilises une application qui modifie tes jolies images. Bon, certains filtres effectuent plusieurs passes sur tes données. Là, avoir un SMP « pur » ou un SMP/CMP peut te faire gagner 50% dans le cas d'une bonne utilisation de la localité des données, ou au contraire te faire perdre 100% de puissance potentielle.
La fonction m'affiche bien <taille d'une adresse char *>.
Et effectivement, d'après la FAQ de fclc, même si pour déclarer officiellement un tableau multi-dimensionnel en passage de paramètre à une fonction, il faut faire quelque chose du genre
void f(char tab[42][S1][S2]....[Sn]) { ... }
Au final, le compilateur voit bien le tableau comme étant
void f(char (*tab)[S1][S2]...[Sn]) { ... }
Mais par contre déclarer les autres dimensions est nécessaire pour ne pas avoir à simuler toutes les dimensions à la main.
« C'est de la provocation ça. parce que entre (int)truc et static_cast(truc) je préfère de loin le premier surtout quand le int ou truc se voit prefixé avec Mon::Namespace::De::Vingt::Metres::De::Long (ok c'est un peu exagéré). »
Sauf que le cast en C est moche parce que le C est faiblement typé, et que donc (type)truc passe toujours. Et ça, c'est tout à fait inacceptable dans un langage orienté objet, je trouve.
« pourquoi choisir le C++ si c'est pour encapsuler du C ? »
Une réponse toute bête : parce qu'en C++, tu as les templates et les espaces de nommage, et que ça change la vie de plein de gens (et ça permet de faire exploser les temps de compilation aussi).
Maintenant en pratique je suis d'accord avec toi, souvent, ça ne sert à rien. Mais namespace et templates ne sont pas spécifiquement des constructions liées à la POO, et un langage procédural dérivé de C qui aurait ce genre de mécanisme en plus aurait beaucoup à y gagner je pense ... Sauf qu'au final, il suffit de faire du C en C++ avec ces deux trucs. :-)
Par contre, ce qui m'énerve bien plus, ce sont les gens qui font du C++, avec plein de construction C là où il existe un idiôme purement C++ (genre les casts façon C qui sont très très moches, et suppriment la vérification de type) aurait plus d'intérêt.
Le ... « truc », justement, tient au fait que le monsieur qui écrit le bouquin est professeur. Ça ne le dispense pas de dire des conneries bien sûr, mais si le monsieur écrit un bouquin dans sa spécialité, il y a fort à parier que
1/ Il aura demandé à être relu par au moins un de ses collègues (il suffit de lire les remerciements dans les bouquins pour voir que si une seule personne est référencée sur la couverture, souvent beaucoup d'autres ont participé)
2/ Il citera ses sources, aura vérifié nombre d'entre elles (ou bien aura dépêché un thésard ou un stagiaire pour le faire à sa place ...).
Évidemment, des gens de mauvaise foi, ça existe partout. Et par exemple, lorsque je cherche des infos en informatique relativement pointue sur wikipedia, ça me sert de bonne vulgarisation (en lisant les versions EN et FR, parce qu'une seule langue ne suffit généralement pas à avoir une explication tout à fait précise). Ensuite, je n'ai plus qu'à chercher les papiers de recherche qui vont plus loin.
Lorsque je veux me renseigner sur un autre type de connaissance, je cherche dans wikipedia aussi, mais très très souvent, n'ayant pas le recul nécessaire pour juger de la pertinence de ce que je lis, je dois quand même aller faire un tour du côté de la bibliothèque ou de la librairie du coin.
Si ton algorithme peut être formulé de façon récursive terminale, il existe une transformation « automatique » vers une forme récursive (les bons compilateurs sont capable de l'appliquer de façon limitée).
Sinon, même sans « dérécursiver », une forme récursive terminale en C revient à avoir un pointeur vers les données modifiées, de façon à ne copier que l'adresse du pointeur à chaque appel récursif et à modifier directement ta structure (en gros, ça revient vaguement à gérer toi-même ta pile d'arguments).
... Et sont à l'origine de la méga-dissipation de châleur qu'on observe actuellement sur les processeurs (pas qu'à cause de ces mécanismes, mais quand même ...). Et introduisent aussi une part non-négligeable d'inconnu pour qui veut obtenir des performances maximales, car on ne sait plus trop quoi fait quoi, entre le cache intelligent qui précharge tout seul, le coeur intelligent qui précharge tout seul, le coeur dans le désordre, qui interroge le cache partagé avec le coeur dans le désordre aussi d'à côté ...
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
« entier » étant déclaré volatile int entier;
On peut se permettre ça car en pratique, tu n'aura pas d'état inconsistant d'un registre entier (tous les bits sont basculés en même temps). Par contre, ça a un inconvénient si tu t'es planté pour l'attente, notamment pour le multi-coeur : un coeur se retrouve à monopoliser le bus d'accès mémoire, et peut donc empêcher ses petits camarades de travailler (donc il ne faut pas se planter).
[1] en fait il faut raffiner un chouilla plus, mais c'est l'idée.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Sauf que le T&S ne fonctionne (à ma connaissance) pas pour un grand nombre de processeurs (problèmes liés à la cohérence de cache, etc.).
[^] # Re: Regrettable
Posté par lasher . En réponse au journal L'interview vérité de Con Kolivas. Évalué à 3.
Je ne sais pas si tu as lu l'article original, mais CK dit que son scheduler, qui pourtant avait été critiqué, a ensuite été adopté comme modèle, et récrit from scratch par d'autres dévs du noyau (ceux qui justement critiquaient son approche). C'est ça qui l'a fait craquer, plus que le refus en lui-même : le côté « non, on veut pas de ton truc car on pense que le concept ne convient pas, mais finalement l'idée est bonne, on va le refaire à notre sauce ».
Tu parles d'IBM, mais leur modèle de threads était plus flexible et performant que celui actuellement utilisé. Sauf que bon, comme le scheduler codé par un pote du mec qui a fait les NPTL, ben... Ils se sont arrangés pour que ça colle bien l'un avec l'autre (rendant l'un dépendant de l'autre, en fait), ce qui a nécessairement désavantagé les threads d'IBM...
[^] # Re: avoir un client e-mail qui soit aussi un webmail ?
Posté par lasher . En réponse au journal La fin de Thunderbird ?. Évalué à 6.
Pas seulement côté perfs. Gmail par exemple est plutôt bien foutu ergonomiquement parlant ; n'empêche, le temps de latence pour aller d'un mail à l'autre est insupportable si tu t'en sers de « client » principal. Franchement, si toutes les applications web étaient faites façon gmail & co, ce serait vraiment un grand pas en avant, mais c'est vraiment beaucoup, beaucoup moins bien qu'un client natif.
Tout ceci sans parler du fait que pour le moment, c'est (X)HTML+javascript, et que javascript c'est sympa quand tu veux faire quelques petits trucs, mais quand tu développes de GROS trucs, c'est un langage extrêmement difficile à debugger, comparé aux autres.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
... Et c'est exactement ce que je fais. :-)
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Après tout dépend du but. Dans le cas de « bêtes » sections parallèles, avec un modèle à la fork/join (comme pour OpenMP), du moment que cette section prend du temps et nécessite réellement du calcul avec des dépendances « lourdes » (qui nécessitent de la synchronisation), alors oui, pourquoi pas.
Mais dans le cas où tu peux t'arranger pour qu'il n'y ai pas de synchro ou presque (par exemple parce que tu peux évaluer - statiquement ou au lancement du programme - le nombre d'opérations qui vont être effectuées, à 0,1% près), et qu'en plus, tu dois absolument aller vite, il ne te reste plus que des langages type C, ou FORTRAN (OCAML me vient aussi à l'esprit, mais je n'ai pas l'impression qu'il y ait de vraies constructions pour le parallélisme dans le langage), car malheureusement, dans la plupart des papiers parlant de parallélisme que j'ai pu voir (et c'est aussi vrai pour les implémentations classiques d'OpenMP), il y a toujours des synchro lourdes dans le cas de déclarations plus ou moins explicites de sections parallèles.
Du coup, il va falloir que je teste un chouilla TBB, mais je pense que ça ne s'interfacera pas trop avec MPC ... :-)
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Non. Je te donne le cas d'un processus unique qui pouvait aléatoirement être migré entre un coeur et l'autre. Il y a quelques générations du noyau de cela, c'était même un ping pong permanent (et très coûteux). Depuis l'ordonnanceur a moins la bougeote, mais il lui arrive encore de migrer un thread/processus d'un processeur à l'autre même lorsque ce n'est pas judicieux.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 4.
Je m'en sers en ce moment pour faire tout un tas de tests et autres benchmarks (notamment, évaluer l'impact des caches partagés par rapport à du SMP classique), et je pense que pour une application mono-utilisateur, on finira par devoir un minimum s'y intéresser, ne serait-ce que pour certaines tâches critiques. C'est un peu ce que fait Mac OS quand de l'OpenGL est exécuté : plutôt que d'avoir un processus affecté à un coeur par le système, et le runtime OpenGL qui s'exécute sur ce même coeur, on le fait se lancer sur l'autre coeur, pour alléger la charge. OpenGL n'en est pas rendu thread-safe pour autant, mais on a au moins découplé le côté « rendu » du côté « traitement ».
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Je suis un peu sceptique. J'ai déjà eu le cas d'un processus (pas d'un thread, nous sommes bien d'accord) qui était migré d'un coeur à un autre, sans autre raison que l'ordonnanceur l'avait décidé (tu comprends, un coeur travaillait à 100%, pas l'autre, alors forcément, l'ordonnanceur a voulu donner du boulot à ce dernier ...). Du coup je me demande si ce genre de comportement ne peut pas se reproduire -- mais bien évidemment, c'est plus ou moins indépendant du fait qu'on manipule un mutex ou non.
[^] # Re: Alors ca c'est du bon
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Si tu parles des systèmes d'exploitation BSD, tu as raison, ils embarquent aussi des softs sous GPL (GCC n'étant pas des moindres). Maintenant, c'est clairement plus parce qu'ils n'ont pas de main d'oeuvre pour faire leurs propres outils sous BSD.
make, par exemple, est fournie version BSD sur les systèmes, et est bien différenciée de gmake (qu'il faut explicitement installer).
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
C'est vrai, mais c'est laissé au soin de l'implémentation d'une part, et souvent ça utilise les mécanismes matériels mis à disposition d'autre part. Sachant que le passage de message peut se faire en synchrone ou asynchrone.
« En passant, un mutex (ou section critique sous Windows) ça ne bouffe rien si le nombre de thread actif est inférieur ou égal au nombre de cpu/core. »
Euh, tu es sûr de ton coup là ?
De ce que j'avais compris, l'utilisation de mutex te soumet potentiellement à un changement de contexte, quel que soit le nombre de processeurs actif. Je peux me tromper bien sûr.
De plus, dans un contexte plus restreint (le calcul haute performance, où les entrées/sorties sont rares), synchroniser comme un malade est souvent synonyme de mauvaises performances.
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 2.
Sauf que la notion de thread en FORTRAN, ben ... Elle n'existe pas. D'où le besoin de machins genre OpenMP pour rajouter du parallélisme explicite à un langage qui ne connaît pas ça officiellement.
De plus, en utilisant les pragma en C ou les commentaires correspondants en FORTRAN, tu permets au compilateur de faire tout plein d'analyses en statique (pour peu que le compilateur sache en tirer parti, ce qui n'est pas du tout évident).
[^] # Re: Multicoeur ?
Posté par lasher . En réponse à la dépêche Intel libère TBB. Évalué à 3.
Ça dépend du type d'application. Lorsque deux coeurs partagent le même cache, la notion de localité des données peut prendre une grande importance. La notion de proximité des processeurs aussi, du coup (je pense par exemple aux stations de travail et serveurs SMP/CMP, genre bi-xeon core 2 duo).
Imagine que tu sois sur une station de travail bi-proc, bi-coeur. Tu es graphiste, et tu utilises une application qui modifie tes jolies images. Bon, certains filtres effectuent plusieurs passes sur tes données. Là, avoir un SMP « pur » ou un SMP/CMP peut te faire gagner 50% dans le cas d'une bonne utilisation de la localité des données, ou au contraire te faire perdre 100% de puissance potentielle.
Donc non, SMP != CMP.
# Petite remarque ...
Posté par lasher . En réponse à la dépêche Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0. Évalué à 4.
[^] # Re: Le C++ peut être simple
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 2.
Si j'ai :
void f(void) {
____char tab[42];
____printf("sizeof(tab) == %lu\n", sizeof(tab));
}
J'ai bien 42 en retour. Par contre, de cette manière :
void f(char tab[42]) {
____printf("sizeof(tab) == %lu\n", sizeof(tab));
}
La fonction m'affiche bien <taille d'une adresse char *>.
Et effectivement, d'après la FAQ de fclc, même si pour déclarer officiellement un tableau multi-dimensionnel en passage de paramètre à une fonction, il faut faire quelque chose du genre
void f(char tab[42][S1][S2]....[Sn]) { ... }
Au final, le compilateur voit bien le tableau comme étant
void f(char (*tab)[S1][S2]...[Sn]) { ... }
Mais par contre déclarer les autres dimensions est nécessaire pour ne pas avoir à simuler toutes les dimensions à la main.
Enfin, c'est ce que je comprends de ce qui est écrit là :
http://docs.mandragor.org/files/Programming_languages/C/fclc(...)
[^] # Re: Internet sans pub vs logiciels libres
Posté par lasher . En réponse au journal Adblockblockblock : l'anti-anti-anti-pub. Évalué à 1.
[^] # Re: peut etre que...
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 4.
Sauf que le cast en C est moche parce que le C est faiblement typé, et que donc (type)truc passe toujours. Et ça, c'est tout à fait inacceptable dans un langage orienté objet, je trouve.
[^] # Re: Le C++ peut être simple
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 1.
[^] # Re: peut etre que...
Posté par lasher . En réponse au journal Un langage pour les nuls? Le langage D!. Évalué à 4.
Une réponse toute bête : parce qu'en C++, tu as les templates et les espaces de nommage, et que ça change la vie de plein de gens (et ça permet de faire exploser les temps de compilation aussi).
Maintenant en pratique je suis d'accord avec toi, souvent, ça ne sert à rien. Mais namespace et templates ne sont pas spécifiquement des constructions liées à la POO, et un langage procédural dérivé de C qui aurait ce genre de mécanisme en plus aurait beaucoup à y gagner je pense ... Sauf qu'au final, il suffit de faire du C en C++ avec ces deux trucs. :-)
Par contre, ce qui m'énerve bien plus, ce sont les gens qui font du C++, avec plein de construction C là où il existe un idiôme purement C++ (genre les casts façon C qui sont très très moches, et suppriment la vérification de type) aurait plus d'intérêt.
[^] # Re: Et ils ont bien raison
Posté par lasher . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 3.
1/ Il aura demandé à être relu par au moins un de ses collègues (il suffit de lire les remerciements dans les bouquins pour voir que si une seule personne est référencée sur la couverture, souvent beaucoup d'autres ont participé)
2/ Il citera ses sources, aura vérifié nombre d'entre elles (ou bien aura dépêché un thésard ou un stagiaire pour le faire à sa place ...).
Évidemment, des gens de mauvaise foi, ça existe partout. Et par exemple, lorsque je cherche des infos en informatique relativement pointue sur wikipedia, ça me sert de bonne vulgarisation (en lisant les versions EN et FR, parce qu'une seule langue ne suffit généralement pas à avoir une explication tout à fait précise). Ensuite, je n'ai plus qu'à chercher les papiers de recherche qui vont plus loin.
Lorsque je veux me renseigner sur un autre type de connaissance, je cherche dans wikipedia aussi, mais très très souvent, n'ayant pas le recul nécessaire pour juger de la pertinence de ce que je lis, je dois quand même aller faire un tour du côté de la bibliothèque ou de la librairie du coin.
[^] # Re: Récursivité terminale
Posté par lasher . En réponse au message Optimisation de la récursivité. Évalué à 2.
Je voulais dire « itérative » bien sûr.
# Récursivité terminale
Posté par lasher . En réponse au message Optimisation de la récursivité. Évalué à 2.
Sinon, même sans « dérécursiver », une forme récursive terminale en C revient à avoir un pointeur vers les données modifiées, de façon à ne copier que l'adresse du pointeur à chaque appel récursif et à modifier directement ta structure (en gros, ça revient vaguement à gérer toi-même ta pile d'arguments).
[^] # Re: 68k
Posté par lasher . En réponse au journal Un OS réécrit son code à la volée. Évalué à 2.
[^] # Re: 68k
Posté par lasher . En réponse au journal Un OS réécrit son code à la volée. Évalué à 6.