A la vue des récents problèmes de certains sites de projets qui ne faisaient confiance qu'au RAID pour leur sauvegarde, il semble en effet qu'une certaine informatique paradoxale s'est mise en place. Avec la mise à disposition du consommateur d'équipements et techniques précédemment accessible qu'aux professionnels, on arrive sur des solutions problèmatiques.
- Le RAID crée une confusion entre fiabilité et pérénité. Malcompris et en mode 1 il s'utilise en place des traditionnelles sauvegardes. Au final, l'utilisateur perdra l'habitude des sauvegardes (qu'il n'avait déjà pas!). Le mode 0 doublera le risque de pertes. Le rythmes des sauvegardes (si elles ont lieu) ne doublant pas...
- Le firewall est "dit" nécessaire à la protection des machines clientes. Oui mais ca n'a jamais été le cas. Une machine sans services ouverts sur le net n'a jamais nécessité de firewall. Elle ne protègent de rien, et les trojans windows n'en sont aucunement freinés. Par contre, l'utilisateur augmentera les problèmes des applications communiquantes. L'ICMP echo perd son utilité par la vonlonté d'un éditeur...
- On passe du 56k à l'ADSL 10Mbps voire plus, et on augmente en parallele la taille des contenus. Les hebergements dédiés augmentent leur débit, mais deviennent potentiellement le nouveau goulot d'étranglement théorique.
Le tout dans la continuité de l'absence d'optimisation de code par augmentation des capacités des machines.
D'autres exemples sont les bienvenus !
Journal "L'informatique Paradoxale"
27
déc.
2006
# Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Plop !
Posté par Anonyme . Évalué à 8.
Tout seul :)
Je refuse d'utiliser des usines à gaz (openoffice, au hasard et entre autre), et fait gaffe quand je code à ne pas attraper le syndrôme "pas grave, l'utilisateur prendra un pc plus puissant".
Bon, ok, Linux en lui-même est une usine à gaz (ya qu'à voir le temps de boot, plus de 30s sur un dual core 3800+ (donc 2GHz) avec 1Go de RAM, c'est indécent), mais chut, faut pas le dire...
[^] # Re: Plop !
Posté par lasher . Évalué à 7.
J'ai aussi des exemples dans le domaine du calcul scientifique, mais ça commence à devenir un peu trop ciblé.
Je suis d'accord dans l'ensemble concernant l'optimisation du code, mais ...
... Mais les gens oublient qu'à partir du moment où on optimise, on perd le plus souvent en lisibilité du code ; que tout le monde n'a pas le même niveau en programmation ; que beaucoup de code produit (et jeté) provient de stagiaires qui par définition ne sont pas encore rôdés [1]; etc.
Si on a pu démultiplier ainsi le nombre d'applications complexes, c'est grâce en grande partie à la réutilisation de composants, de bibliothèques, etc., car c'était plus simple pour des programmeurs moins expérimentés de construire au-dessus des briques de base pas toujours évidentes à faire. Mais ce faisant, et l'abstraction aidant, beaucoup de programmeurs (surtout débutants, je souligne) ignorent de quoi sont faites les briques sur lesquelles ils s'appuient (nombre de programmeurs Java - mais c'est valable pour tout autre langage avec une bibliothèque aussi importante - ne mesurent pas toujours les conséquences d'utiliser un ArrayList plutôt qu'un TreeMap plutôt que ... en termes de complexité spatiale et temporelle).
Moralité : oui, il faut essayer de faire attention à ne pas faire n'importe quoi, pour que ça tourne au mieux, mais il faut faire aussi attention aux excès de zèle.
[1] Il y a toujours des exceptions, bien sûr.
[^] # Re: Plop !
Posté par パパフラクス . Évalué à 2.
[^] # Re: Plop !
Posté par jcs (site web personnel) . Évalué à 1.
[^] # Re: Plop !
Posté par Anonyme . Évalué à 5.
Quand est-ce que les gens comprendront que la complexité est une notion mathématique faisant appel à des concepts d'infinis qui n'existent pas en informatique ? Des librairies algorithmiquement correctes, il y en a des milliers. N'importe quel crétin peut coder une linked liste avec suppression en 0(1), ou un arbre avec recherche en 0(log(n)), mais rare sont les gens qui conçoivent des librairies cache friendly (oui, vous savez, la bêtise qui permet des boosts de perfs de plusieurs centaines de % si on fait gaffe), ou qui ont compris que la prédiction de branchement ne devait pas être ignorée. Je ne parlerais pas des dépendances entre opérations flottantes (en entiers on s'en tape un peu, le compilo réorganise), de la gestion du padding (qui a eu la bonne idée de mettre les int avant et les doubles après ?), de l'utilisation des SIMD (amélioration tout sauf insignifiante, gain possible de facteur 16 sur des int8 (filtrage d'images...)) et en général de toutes les bidouilles bas niveau méprisées par les théoriciens, mais qui font la vrai différence entre une lib de merde et une lib performante.
Bref, un sujet de discussions inépuisable.
ps: pour le monsieur qui a posté en dessous de moi, les Vector sont deprecated, faut utiliser des ArrayList.
[^] # Re: Plop !
Posté par パパフラクス . Évalué à 5.
Par contre, connaitre les structures de données qu'on utiliser, c'est indispensable: les plus gros gains de perf se font sur l'algorithmique.
Sinon, j'ai pas envie de passer ma vie à optimiser, mais je préfère développer des fonctionnalité à temps, tout simplement parce que je ne dispose pas d'un temps infini. Donc je ne veux pas être obligé de gérer la taille des entiers , les float, double & co: il faut savoir s'arrêter. De plus ce genre d'optimisation n'est souvent pas portable, et générateur de bug.
Je préfère un langage/lib qui m'expose des types de plus haut niveau, ce qui ne dispense pas d'être implémenté de manière performante.
Donc en résumé, ce que tu dis peut s'appliqué pour ceux qui écrivent des lib en C, s'ils savent ce qu'il font. Pour les autres je conseille de s'appliquer sur le fonctionnel et la validité de leur code: avoir rapidement un résultat faux (ou un plantage), ça sert à rien.
Pour les Vector et Hashtable, il ne sont pas deprecated à ma connaissance, ms devraient surement l'être, voir même suprimés. Je justement attirer l'attention sur le fait que beaucoup de dev java ne connaissent que ces structure de données qui sont synchronisées par défaut, ce qui bouffe de perf, alors que bien souvent on en a pas besoin. Il faudrait les supprimer (ou déprécier si on veut garder la compatibilité) car il existe d'autres moyens pour synchoniser une collection, et ça ne simplifie pas l'api.
[^] # Re: Plop !
Posté par taratatatata . Évalué à 2.
Si ton moteur est plus lent que le moteur concurrent, tu auras forcément moins d'effets graphiques sur une même scène. Donc moins de feature pour le client.
Par contre la partie logique des jeux est souvent codée dans du haut niveau, comme du Lua, du Python, des langages de scripts parfois crées par le concepteur du moteur..
[^] # Re: Plop !
Posté par lasher . Évalué à 3.
[^] # Re: Plop !
Posté par Obsidian . Évalué à 6.
Il faut bien se rendre compte que si l'on avait eu la même approche de la programmation il y n'y a pas plus de vingt ans, il n'y aurait toujours pas d'ordinateurs dans nos maisons aujourd'hui.
Les deux conséquences majeures que je vois d'ici sont :
- La perte dramatique de savoir-faire dans le métier.
- La dépendance totale du monde à deux ou trois fondeurs de microprocesseurs.
Ce dernier point est très préoccupant pour moi, d'ailleurs, et je ne comprends pas que l'on en fasse pas état plus souvent. Il commence à devenir clair que le monopole de Redmond est inacceptable (stratégiquement) voire dangereux (monoculture), mais rien vis-à-vis du marché du hardware.
Il faut bien se rendre compte que produire un microprocesseur aussi complexe qu'un x86 de dernière génération et le cadencer à 3 GHz est en soi une prouesse technologique. La plupart des autres produits fonctionnent largement en dessous de ce rythme.
Si les fondeurs américains entament un blocus, leur cible se retrouvera totalement privée d'informatique, car elle n'aura plus le savoir métier nécessaire à écrire du logiciel pour des microprocesseurs plus modestes.
Les microcontrôleurs PIC, par exemple, sont très à la mode en ce moment chez les électroniciens et ne battent pourtant qu'à 4 ou 20 MHz (à peu de choses près la fréquence de fonctionnement d'un Amstrad CPC).
Apprendre à être sobre en informatique pourrait bien devenir un enjeu futur après avoir été complètement mis de coté, un peu comme le respect de l'environnement, qui redevient une priorité en ces années 2000.
[^] # Re: Plop !
Posté par briaeros007 . Évalué à 2.
Bon déja il y a pas de monopole à proprement parlé des fondeurs vu qu'il y a 2 gros acteurs sur le marché du grand public, et un certain autre nombre sur l'embarqué .
Ensuite , à l'énorme différence avec le logiciel, le matériel coute à reproduire. Faire une fonderie ca demande des investissement énormes ! La maintenir à jour aussi.
Par exemple pour le projet ogp , ils avait donné le cout d'un masque (cad juste pour qu'un fondeur fonde ta puce) : plus de 1 millions de $.
Toutefois on y vient, il y a plusieurs cpu 'libre de droit' ou opensource.
Le plus récent est je pense 'niagara' l'ultra sparc T1 de sun (8 coeurs, chaque coeur pouvant contenir 4 threads. Optimisé pour les pages web etc... (qu'une unité flottante par coeur je crois, voir sur tous le cpu)).
Ogp fait aussi son bonhomme de chemin.
Pour terminé je suis bien d'accord qu'on devrais jeter le x86 et repartir sur des bases neuves. Mais ca casserait toute la compatibilité, et donc les entreprises (qui ont un poid assez important) et les menages (l'autre partie) apprécieront que moyennement => peu de demande => les couts fixes sont moins amortis => prix plus elevé => encore moins de demande.
Les microcontrôleurs PIC, par exemple, sont très à la mode en ce moment chez les électroniciens et ne battent pourtant qu'à 4 ou 20 MHz (à peu de choses près la fréquence de fonctionnement d'un Amstrad CPC).
Les besoins d'un électronicien (au niveau d'un microcontroleur) et d'un informaticien sont totalement différent.
Le code que sorte les electronicien n'as strictement rien à voir comparé a ce qui est par exemple sur un simple téléphone portable ou un pda!
Et quand tu sais le prix d'un PIC et que tu compare ses perfs aux intels ou aux amd , tu te dis , que somme toute c'est pas si mal les intels ou les amd :D
[^] # Re: Plop !
Posté par Obsidian . Évalué à 2.
Je le sais bien, mais qu'est-ce que cela change au problème ? On ne fait pas face à un trust de ces compagnie mais plutôt au fait que la société de l'information, dont l'émergence est comparable à une révolution industrielle, s'appuie entièrement sur le savoir-faire de deux acteurs mondiaux ! Et à mon sens, c'est beaucoup plus grave ...
Il ne s'agit même plus de rétention du savoir. Fondre un processeur pour PC aujourd'hui, c'est un peu comme enrichir de l'uranium. Il ne suffit plus de lire la doc'. Même les brevets perdent leur efficacité dans le cas présent puisque l'on atteint un stade où, dans la majorité des cas, un processeur devient obsolète avant qu'un industriel concurrent parvienne à maîtriser suffisamment les techniques pour en produire à son tour.
Ce ne sont pas mes propos.
Lacher la « vieille » archi x86 permettrait probablement de gagner drastiquement en performances, mais c'est une opération qui ne pourra avoir lieu qu'une seule fois. Cela ne résoudra pas le problème de fond.
Là encore, tu prends le problème à l'envers. D'abord, ce n'est pas tout-à-fait vrai. L'exemple classique est celui de la dépréciation de port série RS-232 au profit de l'USB. Pratique pour les utilisateurs, mais ingérable au niveau conception, spécialement en ce qui concerne les petites séries. Fort heureusement, il existe désormais des microcontrôleurs qui prennent la partie matérielle en charge, mais la procédure d'énumération, la négotiation de l'alimentation, et le dialogue entre les deux applications sont très compliquées à définir. Il faut non seulement une cadence de travail minimum mais également une quantité non négligeable de mémoire pour stocker le logiciel qui ne servira qu'à la gestion de l'interface.
Ensuite, il faut voir qu'un téléphone portable bat à une cadence bien moindre qu'un ordinateur de bureau. Même si Intel a annoncé des puces pour mobile atteignant le gigaHertz, la majorité des circuits fonctionnent bien en deçà. À cela, s'ajoute le fait que l'appareil doit être sobre en énergie, ne pas chauffer, et pouvoir tenir dans une boite d'allumettes. C'est un peu la quadrature du cercle. Et si quelques fondeurs y parviennent, on se ramène tout de même au problème précédent.
En tout état de cause, il faut bien se rendre compte que si les développeurs ont cessé de chercher à optimiser leur programmes, c'est uniquement dû au fait que les microélectroniciens, eux, font la course à la puce la plus performante. Le mouvement s'essoufle déjà coté fréquence, la tendance actuelle étant axée multicore. Le jour où ils n'y parviendront plus du tout, on pourrait connaître une petite crise économique ...
[^] # Re: Plop !
Posté par briaeros007 . Évalué à 3.
La par contre c'est du fud pur et simple.
Tes deux grands acteurs ils ne sont valables que pour le grand public.
Les pros ils ont d'autres acteurs (par exemple sun)
Et compte pas mettre un p4 la ou tu fait de l'embarqué avec des asic spécifiques .... comme des routeurs ou des commutateurs atm !
Ah moins que chez toi les routeurs ca sert à rien dans 'la société de l'information'.
Quand au couts, ca sert juste à montrer , que c'est bien beau de critiquer mais
1°) y a déja une concurrence (avec via derriere)
2°) pouvoir 'empecher' un pseudo-trust il faut déja allonger pas mal de billet, et avoir une equipe r&d derriere qui suit la route
3°) que les fondeurs peuvent aussi te fonder tes puces. Tu paie le masque et le cout de production toussa, et ils te font ta puce.
Bref strictement rien a voir avec la catastrophe que tu nous prédit.
D'abord, ce n'est pas tout-à-fait vrai. L'exemple classique est celui de la dépréciation de port série RS-232 au profit de l'USB. Pratique pour les utilisateurs, mais ingérable au niveau conception, spécialement en ce qui concerne les petites séries.
Sachant qu'il y a des convertisseur rs-232 <-> usb à faible cout je pense que ton exemple est plutot mauvais...
Ensuite, il faut voir qu'un téléphone portable bat à une cadence bien moindre qu'un ordinateur de bureau. Même si Intel a annoncé des puces pour mobile atteignant le gigaHertz, la majorité des circuits fonctionnent bien en deçà. À cela, s'ajoute le fait que l'appareil doit être sobre en énergie, ne pas chauffer, et pouvoir tenir dans une boite d'allumettes. C'est un peu la quadrature du cercle. Et si quelques fondeurs y parviennent, on se ramène tout de même au problème précédent.
Euh ca a quoi à voir avec la choucroute ?
Oui l'embarqué a ses propres critères et ? Ca fait que le téléphone portable n'est pas utilisé ? Ca fait que tu ne peux pas récupérer tes mails sur ton portable ?
Et le pda ca fait quoi ? C'est pas de l'embarqué aussi ?
En clair tu veux pas que des personnes arrivent et profite d'un marché, avec du travail et un investissement conséquent, parce que toi tu peux pas profiter du marché en claquant des doigts ?
Propose une toute nouvelle puce pour l'embarqué on t'en prie.
Tu remarquera que malgré le trust de ms sur le grand public, linux fut reconnu par plusieurs, et la on peut parlé réellement de trust cad d'un monopole qui empeche par des moyens plus ou moins viles toute concurrence.
Tant qu'il y a pas de concurrence , on peut difficielemnt leur en vouloir de combler un marché.
Oui c'est pas forcément facile de cassé ce cercle vicieux, mais depuis quand la vie doit etre facile ?
Comme disais kennedy 'Celui qui crois que la vie est juste est bien mal renseigné'.
En tout état de cause, il faut bien se rendre compte que si les développeurs ont cessé de chercher à optimiser leur programmes, c'est uniquement dû au fait que les microélectroniciens, eux, font la course à la puce la plus performante. Le mouvement s'essoufle déjà coté fréquence, la tendance actuelle étant axée multicore. Le jour où ils n'y parviendront plus du tout, on pourrait connaître une petite crise économique ...
Tres drole celle la :D
Un jour bill gates a dis 'Personne a besoin de plus de 640 ko'.
Les developpeurs n'ont pas cessé de cherché a optimiser leurs programmes, regardent les programmes de recherches à coté des compilateurs par exemple.
Par contre les programmes résolvent de plus en plus de cas, avec de plus en plus de données.
Et le multicore, pourquoi faire ?
Ca vient de deux chose
-> une limitation physique de la fréquence
-> un ordinateur actuel est un systemùe multitache, et peut donc profiter de plusieurs unité d'executions.
On a commencé à le voir arrivé avec l'HT par exemple
Alors oui le fait qu'on a des puces de 3Ghz on cherche plus à gagner le moindre bit sur certains problemes (mais pas sur tous, l'embarqué recherche toujours à optimiser la taille par exemple) mais de la à dire que c'est la seule et unique cause à un probleme aussi complexe que l'évolution normal de tout un domaine extremement dynamique , c'est il me semble allez bien vite ne besogne.
[^] # Re: Plop !
Posté par Obsidian . Évalué à 2.
Tu as réussi à me faire dire exactement le contraire de ce que j'exprime, et ce pratiquement à chacun des mes paragraphes. Donc, et comme tu sembles être très impulsif, je vais rectifier point par point, ensuite je cesse d'alimenter ce thread.
C'est justement ce que je dis plus haut.
La plupart des programmeurs, aujourd'hui, ne connaissent que la puissance de leur PC de dernière génération, alors que cette puissance est difficile à atteindre.
À ce point, c'est pratiquement de la diffamation.
J'ai volontairement omis ce cas de figure car il est fallacieux (et évidemment, tu sautes dedans à pieds joints) : « ce n'est pas compliqué puisque ce n'est pas toi qui le réalise » ! Les électroniciens dont tu parles, si.
Là encore, à aucun moment, je n'ai « critiqué » cette politique de coût
Je te la fais en plus court : Il n'y a pas de trust, qu'il soit de fait ou volontairement maintenu, il y a dépendance mondiale à une technologie très avancée, et de ce fait maitrisée par un petit nombre d'acteurs seulement.
C'est plus clair ou il faut encore que je développe ?
Complètement hors-sujet (troll anti-trust).
Et on a tous vu ce que ça a donné.
- Tout le monde le sait.
- L'escalade en fréquence touche à sa fin (pour un moment en tout cas, avant que l'on ne trouve une nouvelle technologie), et c'est un exemple de ressource qui se tarit.
En tout cas c'est un troll très réussi, que tu nous as pondu là. Je te laisse avoir le dernier mot si ça t'amuses (mais dans ce cas, merci de faire un effort sur le français, par respect pour tes lecteurs).
[^] # Re: Plop !
Posté par briaeros007 . Évalué à 2.
Tu as réussi à me faire dire exactement le contraire de ce que j'exprime, et ce pratiquement à chacun des mes paragraphes. Donc, et comme tu sembles être très impulsif, je vais rectifier point par point, ensuite je cesse d'alimenter ce thread.
Dans ce cas est ce moi qui ais mal lu , ou toi qui t'es mal exprimé ?
quand je vois :
La plupart des programmeurs, aujourd'hui, ne connaissent que la puissance de leur PC de dernière génération, alors que cette puissance est difficile à atteindre.
Et qui fait le code de l'embarqué ? des singes ou des developpeurs ?
Alors on est pe d'accord, je lis pe mal , mais désolé, il y a certainement aussi un probleme au niveau de ton expression.
d'autant que je cite à chaque fois que je répond, et que je vois aucun probleme de raisonnement entre les citations et mes réponses.
Je te la fais en plus court : Il n'y a pas de trust, qu'il soit de fait ou volontairement maintenu, il y a dépendance mondiale à une technologie très avancée, et de ce fait maitrisée par un petit nombre d'acteurs seulement.
et avant
- La dépendance totale du monde à deux ou trois fondeurs de microprocesseurs.
Ce dernier point est très préoccupant pour moi, d'ailleurs, et je ne comprends pas que l'on en fasse pas état plus souvent. Il commence à devenir clair que le monopole de Redmond est inacceptable (stratégiquement) voire dangereux (monoculture), mais rien vis-à-vis du marché du hardware.
Tu fais bien une correspondance entre redmond qui est un trust , et les 2 grosses firmes de proc gp.
J'ai volontairement omis ce cas de figure car il est fallacieux (et évidemment, tu sautes dedans à pieds joints) : « ce n'est pas compliqué puisque ce n'est pas toi qui le réalise » ! Les électroniciens dont tu parles, si.
Euh ces lesquels dont je parle ?
Si c'est du vhdl ... alors ils le concoivent une fois... ou récup un bloc d'ip (opencore doit avoir ca d'ailleur)
Mais dans ce cas c'est dans la puce.
Si ce sont des electroniciens tels quel (cad pas des micro elec) alors ils utilisent les puces qui existent.
Dans tous les cas, avoir une interface ou une autre pose le probleme de la conception, et des blocs ip - le série ne se fait pas non plus automagiquement, et rien n'empeche d'avoir un bloc ip qui fait de l'usb et qu'on utilise dans la puce comme du rs232 -
Alors pour éviter de s'entredéchirer pour rien.
Si j'ai répondu à coté de la plaque, je m'en excuse.
Si on est d'accord c'est trés bien :)
[^] # Re: Plop !
Posté par Thomas Douillard . Évalué à 3.
Mouais, pour avoir déja eu ce genre d'échange avec toi, avec des remarques au passage relativement similaire, je peux te répondre "à d'autres." Et sans rancune d'ailleur.
[^] # Re: Plop !
Posté par briaeros007 . Évalué à 1.
Certains code compilé avec gcc , puis icc , sur la meme machine, offrait une perfs de plus de 20% avec icc !
/me codeur a ses heures perdu, et n'atteint pas tout le niveau d'optimisation dont vous parlez. Si vous avez une (ou plusieurs) pages explicitant tout ca je serais preneur ;)
[^] # Re: Plop !
Posté par med . Évalué à 4.
Ça, ça dépend beaucoup du programme. J'avais fait quelques tests avec GDL (GNU Data Language) par le passé avec un gcc récent et avec icc. La conclusion étant qu'icc ne sortait pas forcément un code plus rapide et que le code vectorisé était même plus lent que le non vectorisé (et avec un temps de compilation 10 fois plus long). De plus icc tend parfois à ne pas vraiment respecter les normes pour essayer de gagner en performance. Parfois c'est sans conséquence, parfois c'est un peu plus gênant. À propos de performance et de conformité avec les normes il est intéressant de lire par exemple : http://david.monniaux.free.fr/dotclear/index.php/2006/03/17/(...) où l'on apprend des choses surprenantes. :)
[^] # Re: Plop !
Posté par lasher . Évalué à 2.
Parce que icc -Wall est bien plus (trop ?) verbeux que gcc, au point que c'en est gênant.
[^] # Re: Plop !
Posté par lasher . Évalué à 2.
Chez moi, l'expression 1. et l'expression 2. n'ont absolument rien d'équivalent, idem pour 3. Vs 4. Ça n'empêche pas le reste de son article d'être intéressant, mais c'est quand même un peu bizarre ...
[^] # Re: Plop !
Posté par med . Évalué à 3.
Ce sont juste quatre expressions permettant d'obtenir le minimum. Cependant comme indiqué dans le blog il y a des différences sémantiques.
[^] # Re: Plop !
Posté par lasher . Évalué à 3.
[^] # Re: Plop !
Posté par Yusei (Mastodon) . Évalué à 10.
[^] # Re: Plop !
Posté par lasher . Évalué à 7.
1°/ On n'optimise pas.
2°/ (pour experts seulement) On n'optimise pas encore.
Blague à part, effectivement, les compilateurs optimisants sont plutôt assez bien fichus de nos jours, et un bon algo restera en général bien plus efficace qu'une micro-optimisation locale. Il y a des exceptions, bien entendu.
Pour répondre à un commentaire vu plus haut concernant les histoires d'optimisation pour les caches, etc.. Si on prend la bibliothèque MKL (Math Kernel Library) d'Intel qui a été optimisée aux petits oignons et tout, on s'aperçoit que les défauts de cache, on s'en fout. Elle en fait plein, plus que des bibliothèques justement étudiées pour les minimiser. En contrepartie, elle fait plein de préchargements intelligents.
C'est ça le gros problème de l'optimisation : on cherche à améliorer la localité ? Très bien, on améliore. Mais on oublie que les défauts de cache sont parfois peu important vis à vis d'autres facteurs (un défaut de TLB par exemple est souvent bien plus déterminant qu'un défaut de cache L2). Ou bien on se rend compte que tout bêtement, un compilateur donné ne sait pas correctement dérouler des boucles un peu irrégulières, et qu'il suffit de le faire à la main pour gagner 20 à 30% de performances (déjà expérimenté sur icc version Itanium). Mais là, on se rend dépendant d'un compilateur donné.
Donc toute la difficulté est dans le compromis portabilité du code/portabilité des performances/optimisations spécifiques, et franchement, avant d'en arriver à ce genre de choses, je pense que bien définir ses structures de données et ses algorithmes est sacrément plus important.
[^] # Varnish
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 2.
> Par contre, connaitre les structures de données qu'on utiliser, c'est
> indispensable: les plus gros gains de perf se font sur
> l'algorithmique.
Un excellent exemple de ce que l'optimisation peut apporter : Varnish
( http://www.varnish-cache.org/ ).
Voir la vidéo de présentation de l'auteur (PHK) ici :
http://www.nuug.no/pub/video/published/20060919-varnish.mpeg
(attendre un peu pour le démarrage du texte en anglais)
ou un entretien audio seul ici :
http://cisx1.uma.maine.edu/~wbackman/bsdtalk/bsdtalk072.ogg
On doit trouver aussi la présentation donnée cette année à Milan lors de
l'EuroBSDcon, mais je n'ai plus le lien sous la main...
À faire passer dans tous les cours d'informatique !
--
Th. Thomas.
[^] # Re: Plop !
Posté par lasher . Évalué à 5.
On t'a déjà répondu en partie, mais juste pour préciser : j'ai fait exprès de parler de complexités spatiale et temporelle ; il y a bien une notion « physique » dans ces deux types de complexité.
Ensuite, une fois qu'on a un algorithme qui dans le cas général est correct, il faut encore se pencher sur une implémentation efficace.
Oui, il existe des cas où la complexité théorique n'est pas si importante. J'ai en tête un exemple assez frappant :
1°) Pour pouvoir mettre sous forme SSA un programme ( http://en.wikipedia.org/wiki/Static_single_assignment_form ) il faut construire des frontières de domination (dominance frontiers en Anglais). Il existe un algorithme, avec une complexité théorique qui pour le moment n'a pas été améliorée (ou alors juste ses constantes).
2°) Les auteurs d'un papier ont mis au point un algorithme ayant une complexité théorique moins bonne, mais
3°) La différence de complexité n'entre réellement en compte que lorsque le graphe de flot de contrôle (CFG, Control Flow Graph) totalise plus de 30 000 noeuds.
4°) Ça n'arrive presque jamais (en fait, je n'ai jamais vu un cas pareil, mais mon expérience de l'informatique est très petite).
5°) L'algorithme des auteurs est beaucoup plus simple à mettre en oeuvre
6°) Les auteurs de l'article ont tripatouillé à mort leurs structures de données
Résultat : en pratique, tant que les CFG sont en dessous de 30 000 noeuds, ils ont un algorithme qui va plus vite que les implémentations connues de l'algo classique, et qui, étant plus simple dans son énoncé, risque moins d'être sujet à bugs pour sa mise en oeuvre.
Dans cet exemple, on touche directement à la limite séparant la recherche de l'ingénierie. L'ingénierie concerne l'optimisation des structures de données ; la recherche la mise au point de l'algo ; le flou concerne le fait qu'on prend en compte la complexité, tout en faisant attention aux cas réels.
D'autre part, la complexité n'est pas qu'un outil mathématique. Elle donne des bornes, ce qui est très important pour l'implémentation. À quoi bon implémenter un algorithme de complexité O(m^n), par exemple ? Ou mieux : lorsqu'on demande à quelqu'un d'effectuer une tâche, et que ce quelqu'un parvient à démontrer que le problème donné à résoudre est NP-complet [1], il est temps de reformuler le problème, pour le circonscrire un peu plus. Je réagis assez vivement parce que tu donnes l'impression de croire que l'informatique théorique n'est que de la masturbation intellectuelle ; or ce n'est clairement pas le cas [2].
Quand on parle d'algorithmes répartis, par exemple, tu as intérêt à être sûr que ton algorithme converge, sinon tu vas au devant de grosses surprises. Là encore, les « maths » aident beaucoup (même si maintenant il existe tout un tas d'outils sympa pour aider l'infoteux à se dépatouiller de tout ça).
[1] Oui bon, OK, non seulement ça n'arrive pas tous les jours, mais en plus, ça prend du temps de le démontrer correctement.
[2] Y'a des exceptions, comme toujours. ;-)
[^] # Re: Plop !
Posté par briaeros007 . Évalué à 4.
C'est pour ca qu'on parle aussi quelquefois de complexité moyenne et de complexité au pire ;)
(le cas le plus connu le quicksort, le heapsort toussa)
[^] # Re: Plop !
Posté par Thomas Douillard . Évalué à 3.
Ici à priori c'est plutot qu'on a un algorithme efficace sur des "petites" instances du problème, mais qui perd son avantage à partir d'une certaine taille de problème. Ce qui est souvent le cas quand on mets des trucs sioux dans un algo comme de l'apprentissage, qui bouffent du temps et de la mémoire pour en gagner plus tard. L'algo peut être moins efficace sur de tout petits problèmes qu'un algo naif dans ces cas là.
Du coup l'algo "intelligent" sera en moyenne bien meilleurs, il a une infinité de problème derrière le seuil pour rattraper son retard, mais moins performant jusqu'au seuil.
L'algo intelligent peut donc être meilleur à la fois en moyenne et au pire, mais pas sur des instances petites ou bornées.
[^] # Re: Plop !
Posté par briaeros007 . Évalué à 2.
Je crois que la multiplcation par karatsuba et fft correspondent bien à ca.
karatsuba = en n^2 (un peu plus rapide que l'algo naif qui est aussi en n^2)
fft = en n log(n) (de tete).
Quand j'avais demandé a mon prof si il fallait pas mieux qu'on implémente les multiplications par fft (je connais juste de nom) ils nous a dis que non, car sur les nombres sur lesquels on travaillait (clé rsa classique) le coefficient du n log(n) était tellement important que ca mettait plus de temps.
[^] # Re: Plop !
Posté par Thomas Douillard . Évalué à 4.
L'algorithme du simplex est un algo de résolution d'un problème d'optimisation avec des contraintes linéaire et une fonction linéaire elle aussi à maximiser ou minimiser. L'algorithme est exponentiel au pire, mais en moyenne il est meilleur que d'autres algorithmes, qui sont pourtant polynomiaux au pire. En pratique c'est le plus efficace.
http://en.wikipedia.org/wiki/Simplex_algorithm
[^] # Re: Plop !
Posté par Krunch (site web personnel) . Évalué à 3.
Et c'est valable aussi bien pour la complexité moyenne que celle du pire cas.
[0] http://pix.nofrag.com/47/5a/54b359614973b7d9c0fddd2b4e4f.jpe(...)
Faudrait que j'apprenne à me servir de gnuplot un jour.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Plop !
Posté par taratatatata . Évalué à 6.
Je laisse la parole à John Carmack, qui a participé à l'un des moteurs 3D de jeu vidéo le plus optimisé qui soit, dans les limites de l'humainement possible. (mais il n'a pas été le seul, voir par ex :
http://games.slashdot.org/article.pl?sid=06/12/01/184205
)
The biggest problem is that Java is really slow. On a pure cpu / memory / display / communications level, most modern cell phones should be considerably better gaming platforms than a Game Boy Advanced. With Java, on most phones you are left with about the CPU power of an original 4.77 mhz IBM PC, and lousy control over everything.
C'est son constat après avoir fait des jeux pour téléphone portable ( Doom RPG, haha ).
Ce même monsieur a pendant longtemps boudé le C++ et fait ses moteurs en C. Doom 3, qui était l'un des premiers jeux à exploiter le per pixel lighting, a la logique du jeu qui est codé en C++ mais le moteur 3D est toujours fait dans un style C, pas du C++ objet.
A noter que le mythe du C++ beaucoup plus rapide que Java est dû au fait qu'une grande, grande partie des développeurs C++ ne sont pas vraiment des développeurs C++ mais des développeurs C qui s'ignorent. Un programme C++ qui utilise tout le pouvoir d'abstraction offert par le C++ moderne risque même d'être plus lent qu'un programme Java qui tourne sous HotSpot. De très (trop?) nombreux projets ont des règles de Coding Style qui interdisent un grand nombre des outils offerts par le C++ moderne, à la fois pour des raisons de portabilité (compileurs pourris) et performances.
Malheureusement il ne sort plus de livres sur le C. Il y a eu une nouvelle norme C, le C99, mais très très peu de livres qui expliquent les nouveautés de cette norme. Ca n'encourage pas les jeunes développeurs à apprendre le vieux langage, qu'ils considèrent prématurément comme désuet.
L'avenir, et c'est même le présent, c'est d'alterner des couches bas et haut niveau. Sun a raté un train avec Java qui cherche absolument à tout faire en Java.
Alors que le java officiel prétends qu'il faut même faire le GUI en java (Swing), les Windows.Forms du C# font appel à des libs natives, ce ne sont que des wrappers, comme l'étaient les MFC du C++ qui cachaient l'API C.
Dotnet et Mono seront de plus grandes réussites sur le desktop, et peut-être même dans le monde du jeu vidéo parce que dotnet est bien plus facile à interfacer avec le monde natif et on est encouragé à le faire.
Les pythonistas ont eu aussi cette longueur d'avance sur les développeurs Java. Ils n'hésitent pas du tout à utiliser les libs natives dans leurs programmes python. Un programme python qui utilise des libs natives dans les points chauds sera forcément plus rapide qu'un programme codé par un drogué qui fait tout en Java.
[^] # Re: Plop !
Posté par taratatatata . Évalué à 2.
http://209.85.135.104/search?q=cache:rwizBZAEv0UJ:www.armadi(...)
[^] # Re: Plop !
Posté par パパフラクス . Évalué à 0.
En fait je suis plutôt un partisan du monde Python, et par conséquent je suis d'accord avec toi sur la statégie d'optimisation :)
Par contre pour le C++pour moi c'est un des pires languages qui puisser exister, il faut sûrement être malade, ou dépressif pour vouloir coder dans ce langage ;)
Pour le C je peux comprendre, pour le bas niveau, ou l'optimisation, ce langage a au moins l'avantage de la simplicité (comparé au C++).
Encore que me concerant dans ce cas je me tournerait plutôt vers ocaml, si possible
Sinon, Python + bindings conjugue à merveille la programmation de haut niveau avec les performances.
Un bémol cependant, tu fais alors une concession sur la portabilité, si la lib n'existe pas sur les plateformes qui t'interessent.
Alors qu'avec java tu reste portable, et c'est un argument qui se défend, suivant le contexte.
[^] # Re: Plop !
Posté par taratatatata . Évalué à 6.
Ça c'est uniquement si tu utilises java pour du serveur ou du desktop. Dans le monde du mobile J2ME Carmack a fait la douloureuse expérience du Write Once, Debug Everywhere.
[^] # Re: Plop !
Posté par kowalsky . Évalué à 5.
Ouais, bof... Il faut que ta plateforme possede une machine Java...!
Ce n'est pas le cas pour moi (et plein d'autre personne...!).
[^] # Re: Plop !
Posté par Anonyme . Évalué à 4.
D'apres certaines rumeurs, il semblerait egalement que de nombreux psychopates, ainsi que des criminels racistes, des communistes et des detraqués mentaux veuillent utiliser le C++ comme langage de programmation.
# Le plus connu
Posté par KiKouN . Évalué à 6.
[^] # Re: Le plus connu
Posté par xumelc . Évalué à 5.
[^] # Re: Le plus connu
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: Le plus connu
Posté par gasche . Évalué à 6.
(on peut continuer sur monsieur Portes, mais je pense que ça va comme ça)
# Free
Posté par tiot (site web personnel) . Évalué à -1.
[^] # Re: Free
Posté par Gniarf . Évalué à -3.
# fsf et gnu
Posté par B16F4RV4RD1N . Évalué à -2.
alors qu'il existe des logiciels dits "libres", il y a également des intégristes qui veulent interdire tout un tas de pratiques sur l'ordinateur des gens : utilisation de flash, de java, de pilotes pour le faire fonctionner, utilisation de la licence bsd "trop permicives"... Ainsi le top du top serait d'utiliser la distribution officielle de la fsf : gnewsense, variante d'utuntu, elle-même variante de debian, car tout serait ainsi plus libre : l'utilisateur enfin "libéré" de son aliénation, découvrira les joies de la "liberté" imposée par la fsf : pas plus de sites flash (le pilote libre étant encore aléatoire..), ni de jeux 3D, ni de java, ni de mp3, ni de vidéos non encodée en format libre (95% des vidéos disponibles sur internet), ni d'un certains nombres de pilotes qui faisaient fonctionner la machine, ni du joli logo du renard de feu panda rouge.
oui, parfois le proprio c'est mal, mais l'inverse c'est pas forcément mieux.
Le libre n'est-il pas justement d'avoir le CHOIX de ses outils ? Debian (et autres...) au moins propose le choix, ayant séparé les logiciels 100% libres de ceux ayant de quelconques restrictions, mais ces derniers restant malgré tout accessibles (mp3 par exemple). Mais en attendant d'avoir de plus en plus de logiciels vraiment libres ou de manipuler des formats entièrement ouvert (comme ogg), au moins on peut utiliser son ordinateur.
Finalement, à part le nom ridicule, le logo de cette distribution gnewsense n'est pas mal trouvé, en l'installant l'utilisateur aura effectivement l'impression de se retrouver avec toute la technologie dont on peut disposer sur une île déserte :
http://wiki.gnewsense.org/pub/skins/gnewsense/logo.png
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: fsf et gnu
Posté par Yusei (Mastodon) . Évalué à 7.
On vit vraiment dans une société malade, pour que dès que quelqu'un tente de nous convaincre de quelque chose, on suppose qu'il essaye de nous interdire le contraire. Ce n'est pas parce que la FSF dit que Flash saimal qu'ils veulent t'interdire quoi que ce soit...
Ah si, c'est toujours mieux d'avoir des droits que de ne pas les avoir.
Ben non, le libre c'est le libre et le choix c'est le choix. C'est bien gentil d'utiliser le mot "libre" pour désigner "ce que je trouve qui serait super cool", mais on ne s'y retrouve plus, n'ayant pas la même définition. En attendant quand on parle de libre sur ce site, c'est généralement en référence à la définition de la FSF et donc, non, le libre ce n'est pas le choix.
[^] # Re: fsf et gnu
Posté par B16F4RV4RD1N . Évalué à 1.
ouais, un peu comme quand Stallman dit : "Don't Buy Harry Potter Books" ou "Boycott Blu-ray and HD-DVD" (avec un lien pointant vers http://fuckbluray.com/boycott )
pour moi la liberté c'est le choix, à partir du moment où on n'a plus la liberté dans son choix de vie (que cela soit avec l'argumentaire "cause toujours" ou "ferme ta gueule"), et bien on n'est plus libre.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: fsf et gnu
Posté par Yusei (Mastodon) . Évalué à 10.
Exactement: il essaye de te convaincre, et toi tu crois qu'il veut t'obliger.
Tu confonds ta liberté et la liberté du logiciel (si l'on peut dire). La définition de la FSF, qui est largement utilisée et à laquelle on pense en général, définit quatre libertés sur un logiciel garanties par une licence libre.
Prenons un exemple concret. Tu veux utiliser Firefox, qui est un logiciel libre, donc qui te garantit quatre libertés concernant ce logiciel. En quoi les libertés garanties par la licence de Firefox auraient la moindre influence sur ta liberté de choix de logiciels autres que Firefox ? Jamais le fait d'utiliser un logiciel libre ne va t'empêcher de choisir tes logiciels, car la notion de logiciel libre ne concerne que le logiciel lui même.
Tu remarqueras qu'une licence qui dirait "vous n'avez le droit d'utiliser ce logiciel que si vous n'utilisez aucun logiciel propriétaire" ne serait pas une licence libre, selon la définition de la FSF.
[^] # Re: fsf et gnu
Posté par Gniarf . Évalué à 0.
>> (...)
> Exactement: il essaye de te convaincre, et toi tu crois qu'il veut t'obliger.
je te signale que souvent, c'est foutrement bien imité.
[^] # Re: fsf et gnu
Posté par Yusei (Mastodon) . Évalué à 7.
Comme quand il s'agit de "convaincre" quelqu'un de ne pas parler en UTF-8 sur IRC ?
(et merde, je suis foutu, je commence à faire des références à des vieux journaux sans intérêt...)
[^] # Re: fsf et gnu
Posté par Gniarf . Évalué à 1.
[^] # Re: fsf et gnu
Posté par Gniarf . Évalué à 2.
# mouaich
Posté par TImaniac (site web personnel) . Évalué à 7.
Faut relativiser tout de même, les compilateurs n'ont jamais été aussi performant. C'est juste que maintenant on s'offre des services et une quantité de code qu'on ne pouvait pas se permettre avant à cause de limitations matérielles. Bref, ca n'a vraiment rien de paradoxal, c'est une saine émulation entre le besoin de ressources (calcul, mémoire) et l'offre des fabriquants.
Pour ce qui est du firewall (au sens firewall Windows j'entend), il faut bien voir qu'il ne se contente pas d'ouvrir ou fermer des ports, il contrôle tout ce qui passe, en entrée mais également en sortie, avec un contrôle non pas uniquement au niveau du port mais aussi au niveau protocole ou même applicatif. L'histoire de l'informatique montre qu'actuellement l'utilisateur ne maîtrise plus les programmes qui tournent sur sa machine, il est donc tout à fait logique d'avoir des "intermédiaires" de contrôle qui font le boulot à sa place, c'est le but de l'informatique non d'automatiser des tâches ?
Pour le goulot d'étranglement des débits, je ne vois rien de paradoxal, il montre juste la limitation du modèle classique client/serveur avec de multiples clients qui ont des ressources (ici débit) additionnées bien supérieures à l'unique serveur. Les technologies de P2P répondent à ce problème, et les FAI l'on bien compris : le prochain objectif, c'est un upload/download symétrique, chaque peer devenant un fournisseur de contenu.
[^] # Re: mouaich
Posté par Guillaume Knispel . Évalué à 8.
Vu comme ca ca semble parfait, pragmatique, réaliste, efficace, malheureusement la réalité et juste un peu différente et le glissement nous mene vers des zones plus sombres :
La performance des compilateurs nous évite juste d'avoir envie de coder en ASM pour 99.999% du code vu que ca n'a dans cette majeure partie des cas plus aucun interet.
Ca n'empeche pas les gens de pondre des algo pourrav, du code bloated, du code buggué, mal écrit, et finalement une masse de code qui certe est énorme, mais qui fonctionnelement n'apporte pas grand chose par rapport au code précédent, bien moins buggué, bien plus bref, clair, rapide, et finalement de l'ordre de peut etre juste 5% moins fonctionnel par rapport a ce qu'utilisent réélement les gens.
Plus je m'améliore dans le domaine du développement plus j'ai tendendance à trouver horrible et exécrable le code de certains logiciels gros et mal écrits, dans lesquels je peux trouver des bugs en 5 min rien qu'en lisant. Et pour l'instant, j'affirme que ca représente 90% de ce que je suis ammené à regarder et dissequer.
Si l'avenir est au code bloated et sale, écrit par des singes sans aucune notion théorique ni aucun recul ni aucune conception préalable (formelle ou informelle peut importe, juste histoire que les gens sachent un peu ce qu'ils sont en train de faire) qui le rendent libre en s'attendant que la "gentille communauté" vienne passer un coup d'éponge par derrière pour rendre le tout légèrement moins pourrav et puant, alors je vais avoir vraiment envi d'arreter l'info. Ou peut être d'initier une distribution qui ne contiendra que des logiciels de qualité, qui sait ?
D'autant que bien souvent on trouve rapidement des pistes pour faire quelque chose de 5x plus petit et élégant, malheureusement les gens ont tendance à ce complaire dans l'historique et dans les empilements anarchiques de code jamais refondus, un espèce de bazar sans cathédral d'où le refactoring serait bannis et où seul les changements microscopiques de 3 lignes sont admis, vagues corrections de symptomes qui ne s'attaquent jamais au fond du problème. Je vous laisse imaginer le résultat.
Et à voir le résultat des logiciels produits par les éditeurs propriétaires, les logiciels pour le grand publique sont dans une espèce de phase de décadence généralisée qu'ils soient donc libres ou proprio - si j'en crois ce que je vois quand j'utilise les merdes fournies avec le matos, genre les moultes logiciels incohérents et énormes sans raison fournis (sans raison non plus) avec un APN ou un imprimante, ma mention spéciale étant actuellement attribuée à HP et ses "drivers" de 1Go remplis de merde immondes bloated en dot Net pour ses imprimantes sous Windows. Faut-il avoir un core duo et 2Go de RAM pour imprimer et scanner des photos ? Apparement oui. Peut importe qu'il y a quinze ans ça marchait aussi bien avec un pentium 100 et que 1Go de disque aurait révolté toute la planette à l'époque.
Quand aux trucs "réputés" (? peut-être ils ne le sont plus autant maintenant)... Beurk. J'ai eu loccasion de voir quelqu'un travailler avec photoshop récement et j'affirme que certains des développeurs ont pondu des algo d'imagerie probablement sans écrire aucune équation ne serait ce que sur le coin d'un brouillon et même sans tester réellement le résultat où alors sur un écran de merde. Essayer "l'export Web" avec 3 ou 4 tons différents dans de leger degradés et en testant toutes les combinaisons de paramètres que vous pouvez imaginer pour vous en convaincre.
[^] # Re: mouaich
Posté par TImaniac (site web personnel) . Évalué à 3.
C'est la rançon du succès de l'informatique.
Je suppose que tu préfères l'époque où écrire un programme était réservé à "l'élite", où le programme était murement réfléchi par des Docteur en Math... Rien ne t'empêche de rester dans cette époque, tu sembles persuader que ce monde générait des programmes mieux sous tous les points de vue, libre à toi de tenter de rivaliser avec les produits actuels. Bon courage ;)
[^] # Re: mouaich
Posté par パパフラクス . Évalué à 5.
Par contre pas mal de developpeurs laissent le code comme ça leur vient au premier jet, alors qu'il savent ce qu'il faudrait faire pour correctement le refactoriser, et ça c'est criminel.
Cela dit ça ne me pose pas de problème, tant que je n'ai pas besoin de bosser avec ces développeurs.
D'ailleurs pas mal de prog fonctionne parfaitement bien vu de l'extérieur, alors que quand on voit le code, c'est tout pourri ;)
[^] # Re: mouaich
Posté par Rin Jin (site web personnel) . Évalué à 5.
Ce qui m'est déjà arrivé c'est de faire, rapidement, du code sale pour le reprendre plus tard, en marquant bien en commentaire que c'est sale, pour le retrouver plus tard et l'améliorer.
Généralement, j'oublie ce bout de code un temps et quand je veux le reprendre plus tard, on me dit "pas le temps".
Avec le temps et l'expérience, mon code sale est plus blanc, et je code plus vite, mais j'ai encore des gens qui me disent "ça marche, c'est bon, c'est fini", même quand je sais où et comment améliorer le soft.
[^] # Re: mouaich
Posté par パパフラクス . Évalué à 7.
Et sinon c'est sympa de signaler le code sale, tes successeurs sur le code te remercieront pour ça ;)
Au moins quand c'est pas signalé, je pré-suppose l'ignorance, et ça m'incite à l'indulgence. Dans ton cas, c'est la peine maximale! ;)
En fait ce que je veux dire, c'est que le travail en équipe est déjà difficile quand le code est nickel, il faut éviter de se créer des problèmes en plus inutilement. En réalité, quand tu mets ton code au propre, que tu prends le temps de faire les choses comme il faut, tu gagnes du temps, et tu en fait gagner au autres membre de l'équipe.
Mais ça, c'est pas tout le monde qui le comprends, et même parfois les chef dans une équipe de dev ont du mal à le comprendre, trop pris dans une course aux nouvelles features.
Pour moi le rêve, c'est quand ton chef dit:
"ça marche, c'est propre , c'est testé, c'est documenté(dans le code c'est mieux)"?
Si tu dis oui, il te répond:
"je peux voir?" ou un truc du genre. C'est pas trop pour faire la police, mais pour faire comprendre aux débutant par exemple, que si tu dis:
"j'ai pas activé le code parce que..." ou alors "oui, mais il faudrait d'abord que...", c'est que c'est pas fini.
Et si c'est pas trop la course, un de tes collègue regarde ce que tu as fait, pour voir s'il comprend tout.
Quand tu arrive, tu te dis, c'est quoi ces maniaques, et après tu comprends ton bonheur :)
[^] # Re: mouaich
Posté par briaeros007 . Évalué à 2.
Euh pas tout le temps ...
Je prend un exemple dans une librairie de thread. On devais implémenter certaines fonctions. Puis pour passer un test, il y a une autre fonction qu'on devait implémenter de la norme posix , mais cette fonction était appelé que deux fois pour toute l'utilisation du code.
On a mis une boucle active (oui je sais pas beau toussa) car faire du code propre ca aurais conduit a changer assez en profondeur la librairie et aurait pris énormément de temps. (Mais bon c'est bien marqué partout que c'est une attente active, et sur la doc c'est meme indiqué en rouge :D ).
Par contre le jour ou ils codent un systeme qui permet d'éviter de faire une attente active, alors c'est trois lignes à changer dans ce code;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.