dimanche 26 octobre 2008

Inhumain

Qu'est-ce que des actes inhumains ? À priori des actes qui ne peuvent-être accompli par des êtres humains. Aujourd'hui on qualifie d'inhumain tout un tas d'actes horribles et immoraux, mais qui sont fait par des hommes. C'est comme si on considérait que l'homme était incapable de commettre des atrocités, hélas l'histoire et l'actualité nous montre le contraire. Je pense que le mal est une caractéristique intrinsèque de l'esprit humain. Les bébés aiment griffer et taper les gens qui ont des visages qui leurs déplaisent. Les garçons aiment jouer à la « baston » au gendarme (armé bien entendu) et au voleur. Depuis tout petit l'Homme aime faire le mal. La haine fait partie intégrante de la nature humaine, n'en déplaise aux humanistes.

Le guru


Il cultive chaque jour son charisme, ses compétences sont reconnues de tous. Il est l'homme de la situation, il s'impose comme le leader. Tout le monde ou presque boit ses paroles, les réfractaires auront droit à des débats où sophisme et affirmations gratuites sont de rigueur. Le guru à l'habitude de ces débats et il en sort toujours vainqueur, parfois grâce à son argumentation, parfois grâce à sa grande gueule. Le guru est considéré comme un intégriste, intégrisme qu'il revendique. Le guru affectionne certaines pratiques (ou méthodes) qu'il met en œuvre qu'elle qu'en soit les conséquences, ainsi, il préfère comme tout le monde les réussites totale aux demi-échecs, mais aussi les échecs cuisants aux demi-réussites, pourvu que les pratiques soit appliquées... Le guru est expérimenté, il pense avoir compris les raisons de ses anciens échecs. Il pense aussi connaître la route qui mènera à la réussite. Il passe des mois à convaincre et persuader les gens qui l’entourent du bien fondé de ses opinions, il manipulera ses gens afin d'en faire de fidèles disciples. Le guru ne dit pas tout sur son passé, il n'est d'ailleurs, contrairement aux apparences, pas infaillible, et, lors de houleuses discussion, ses interlocuteurs peuvent lui démontrer qu'il se contredit. Le guru connait ses faiblesses et son armée de disciples est là entre autre pour le défendre pendant les débats. Les disciples du guru sont facilement identifiables, ils ont la voix de leur maitre, aux même questions ils répondront les mêmes réponses, ils défendront les mêmes opinions avec les mêmes arguments. Ces disciples (clones ?) sont entre-autre chargé de répandre la « bonne parole » du guru. Le guru est orgueilleux et assoiffé de pouvoir, il tente d'éliminer tout ce qui se trouve en travers de son chemin, il se méfit de ceux qui ne font pas partie ses disciples, disciples qu'il mènera sur le chemin de la réussite ou droit dans le mur...

dimanche 19 octobre 2008

Le résiginé

A son arrivé, il était plein de rêves d'ambitions, il avait des projets, il avait la rage, mais au fur et à mesure il a du revoir ses ambitions à la baisse, ses supérieurs hiérarchiques ont tués ses rêves. Une fois de plus. Il espérait pourtant ne pas reproduire les échecs connus dans d'autres entreprises. A son arrivé, il était trop naïf, il a l'impression d'avoir été trahi, une fois de plus, une fois de trop. Il a décidé d'aller chercher son bonheur ailleurs, car chaque jour lui confirme le fait qu'il ne le trouvera pas ici. Depuis, il est moribond, il attend patiemment l'autorisation de partir, on ne le consulte plus,il a perdu de sa superbe, il est presque devenu inutile, voir indésirable, il reste dans son coin, le regard vide en attendant l'autorisation de partir, partir vers une destination méticuleusement choisie, où il espère ne pas êtres confrontés aux même problèmes qu'avant, où il espère être compris, où il peut enfin s'exprimeret faire taire sa frustration, sa frustration de ne pouvoir agirparce que ses agissement ne sied guère à ses supérieurs et à ses clients. Désormais il ne se battra plus,enfin plus ici, car malgré tout il continu d'y croire, car il n'ose pas imaginer que ses aspirations ne puissent jamais êtres satisfaites.

La stratégie de Microsoft


Je ne comprends pas l'intérêt de .NET pour Microsoft. Il y a quelques années Sun à lancé Java qui a répondu aux attentes des entreprises, à savoir une plateforme qui permet de développer rapidement des logiciels. A cette époque Microsoft n'avait pas d'alternative. Non seulement Microsoft ne pouvait pas utiliser Java comme il le voulait, mais Java représentait une menace pour le groupe, en effet, java permet d'élaborer rapidement des applications multiplateformes et ce sur 4 plateformes (Windows, Linux, Mac OS et Solaris), les applications développées en Java n'ont plus besoin de Windows. Microsoft à donc élaboré sa solution, très proche de Java : .NET. Là ou Sun dit « si vous écrivez en Java, vous pourrez l'exécuter sur n'importe quelle plateforme (ou presque) », Microsoft répond « si vous l'exécutez sur Windows, vous pourrez l'écrire dans n'importe quel langage (ou presque) ». Les deux approches sont amusantes dans la mesure où techniquement, rien n'empêche quelqu'un de créer un langage et de le compiler en Byte-Code (langage intermédiaire de Java) et rien n'empêche quelqu'un de prendre un code IL (langage intermédiaire de .NET) et de le faire tourner sur une autre plateforme que Windows (le projet Mono en est la preuve). Même si les développeurs changent rarement de plateforme de développements et qu'il leur arrive rarement d'avoir besoin d'écrire des applications multiplateformes, l'initiative est intéressante, car elle permet de ne pas se fermer sur une seule plateforme. D'un autre coté s’il arrive rarement à un développeur de changer de langage de programmation, il peut être intéressant dans certains cas d'utiliser des langages qui leur permettent d'écrire certaines instructions plus facilement (je pense par exemple aux types inductifs qui existent dans très peu de langages impératifs orientés objets).
La stratégie de Microsoft c'est quoi ? Depuis très longtemps la stratégie du groupe de Redmond consiste à promouvoir le système d'exploitation Windows et les suites bureautiques Office. Il est bon de rappeler que Windows et Microsoft Office représentent à peu près 80 % des revenus de la firme. Par exemple, si Visual Studio est un excellent environnement de développement intégré c'est très certainement pour inciter les développeurs à développer sous Windows des applications qui pourront dans la plupart des cas ne s'exécuter que sous Windows. Est-ce que cette stratégie est dans l'intérêt de l'utilisateur ? Oui et non, certes étant donné que la plateforme d'exécution est figée on peut penser que l'éditeur peut se permettre des optimisations impossibles à mettre en œuvre si l'on ne connait pas à l'avance la plateforme d'exécution du logiciel. D' un autre coté, on enferme l'utilisateur sur une plateforme qu'il a choisi au départ mais sur laquelle il n'a pas forcément envie de passer le reste de ses jours. Il existe évidemment des marchés satellites comme le jeu vidéo et la recherche en ligne qui n'ont que peu d'influences sur les ventes de Windows et des suites Microsoft Office.
Vous l'avez compris le but de Microsoft avec .NET est d'offrir une plateforme de développement aussi facile d'utilisation que Java (voir plus) tout en « obligeant » les développeurs à développer des applications qui ne s'exécuteront que sous Windows. Au vu de la stratégie de Microsoft on n’est pas surpris de l'apparition de .NET.

Pourquoi Java est privilégié par les entreprises ? Parce que Java est une plateforme qui gère automatiquement la mémoire et évite donc aux développeurs les erreurs de segmentations et autre fuites mémoires. Java dispose en plus d'une grosse libraire très riche et fort bien documentée. Les développeurs Java sont très actifs et sortent régulièrement des cadriciels permettant de faciliter le développement des logiciels. .NET propose les mêmes avantages.
Pourquoi Java est compilé en langage intermédiaire ? C'est pour ne pas être dépendant d'une plateforme particulière et ainsi être portable. Cette semi-compilation couplé à l'utilisation d'un ramasse-miette rend les exécutables compilés en Java assez lents, parce que non seulement le JIT (le compilateur « juste à temps ») devra finir la compilation en cours d'exécution mais en plus le ramasse-miette devra faire son travail tout au long de l'exécution du logiciel. Un programme compilé en Java est donc théoriquement fatalement plus lent qu'un programme compilé en langage machine et à fortiori plus lent qu'un programme compilé en langage machine s'exécutant sans ramasse miette. J'entends d'ici les Javaïstes et les .NETistes hurler qu'aujourd'hui les JIT sont très rapides (et ils n'ont pas tord) et que les ramasse-miettes sont de nos jours très rapides (ils ont raisons) et qu'aujourd'hui les programmes écrit en C# ou en Java sont aussi rapides que des programmes écrit en C/C++ voir plus. En effet, il est possible de bricoler un benchmark en faveur des langages disposant de ramasse-miettes, la gestion de la mémoire en C/C++ est statique voir déterministe et à donc peu de chance d'être intelligente. Alors que le ramasse-miettes fait son travail méticuleusement, sans erreur, il s'arrange pour libérer la mémoire au moment ou ça gênera le moins l'utilisateur de l'application. Pour ces raisons là il arrive que les langages disposant de ramasses miettes produisent des exécutables plus rapides que les exécutables ne nécessitant pas de ramasse-miettes. Pour qu'un exécutable disposant d'un ramasse miette soit plus rapide qu'un exécutable ne disposant pas d'un ramasse miette, il faut que la gestion de la mémoire par le ramasse-miettes soit tellement intelligente qu'elle « gomme » le temps d'exécution du ramasse-miettes. C'est possible, des benchmarks le prouvent, mais c'est difficile à faire, et je ne suis pas persuadé que c'est toujours possible. De plus, n'en déplaise aux fans de Java et .NET, rares sont les applications légères écrites en Java ou en .NET (je préfère dire .NET que C# ou VB.NET ou F# etc.) elles sont souvent bien plus lourdes (en mémoire et en CPU) et moins réactives que leurs alternatives compilées en langage machine. Bref, Java nous offre une portabilité et une facilité de développement qui se paye au prix d'une certaine lourdeur, lourdeur qui est loin d'être gênante pour la plupart des entreprises, d'où le succès de Java. Dans le cas de .NET bien qu'étant considéré comme étant un brin plus performant que son concurrent libre (Java), il offre les mêmes inconvénients que ce dernier sans pour autant offrir la portabilité. Alors oui, Mono existe et le projet avance, mais il n'avance pas aussi vite que le .NET de Microsoft et la portabilité des exécutables .NET n'est pas garanti (ni même prétendu) par Microsoft. Alors oui, Microsoft n'a stratégiquement pas intérêt à ce que .NET soit portable, sinon son alternative n'a aucun intérêt si ce n'est de plagier la solution de Sun. Mais pourquoi permettre cette portabilité ? .NET aurait été tout aussi agréable pour les développeurs si les exécutables étaient compilés directement en langage machine (en gardant bien sûr le ramasse-miettes). Il aurait évité l'apparition de projets comme Mono, qui sont très intéressants pour les utilisateurs et les développeurs mais pas pour la firme. Certes Mono à un train de retard sur Microsoft, mais ces derniers temps les choses se sont accélérées et le rêve de voir un .NET portable dans un avenir proche devient de plus en plus réaliste.

Des benchmarks ont montré que les langages compilés en langage machine disposant d'un ramasse miettes peuvent avoir des performances équivalentes aux C/C++, bien que je doute qu'en dehors du cadre du benchmarking ces résultats soient confirmés, il est clair que même en gardant le ramasse miette, compiler directement un langage en langage machine permet à un exécutable de s'exécuter beaucoup plus rapidement qu'un exécutable compilé en langage intermédiaire.

De plus, Microsoft semble mettre de coté les langages ne disposant pas de ramasse-miettes comme C/C++ (pourtant très utilisés pour écrire des clients lourds) au profit de sa plateforme .NET. Il parait même que des morceaux de Windows Vista seraient faits en .NET (en dehors du framework bien entendu), ce qui pourrait expliquer pourquoi ce système d'exploitation est aussi lourd. Dans les laboratoires de recherche de Microsoft un nouveau système d'exploitation est en cours de développement : Midori (à ne pas confondre avec le navigateur web) un système d'exploitation fait entièrement en .NET, certes ce projet est technologiquement intéressant et montre qu'on à pas besoin de langages comme C et C++ pour développer des OS. Mais qu’en est-il des performances de ce système ? On a vu récemment avec Windows Vista que la lourdeur d'un système d'exploitation peu être rédhibitoire, et que l'arrivée des ordinateurs ultra-portables va pousser à revoir la conception des applications afin de les rendre plus légères. En effet, pendant longtemps les éditeurs disait « si Monsieur X n'a pas assez de RAM pour faire tourner notre application il achètera des barrettes »; dans un marché ou la plupart des PC vendu sont des ordinateurs portables est-ce que cette attitude est encore crédible ? En période de récession économique et de crise du pouvoir d'achat, combien d'utilisateurs de PC (portables ou de Bureau ou même de Macintosh) seraient prêt à mettre à jour leur machine juste pour quelques logiciels ? Bref, si Java et .Net facilitent la vie des développeurs, les applications qui en résultent (lorsqu’il s’agit de clients lourds destiné au grand public) s’apparentent à des boulets accrochés aux pieds des utilisateurs finaux. Je trouve d’ailleurs quelques développeurs un peu égoïstes, ils ne se soucient guère du confort d’utilisation de leur logiciel, ils ne pensent qu’a leur confort. Ils préfèrent un programme agréable à développer qu’un programme agréable à utiliser, c’est étrange dans la mesure où les programmes sont avant tout fait pour être utilisés, l’informatique pour l’informatique ne sert à rien (c’est de la branlette intellectuelle). Microsoft semble adopter un comportement similaire en privilégiant .NET, ainsi il n’est pas impossible que plus tard, la plupart des clients lourds pour Windows soient écrit en .NET.
Un client lourd écrit en .NET est client qui porte trop bien son nom (lourd…) et qui donc n’est pas nécessairement bénéfique pour les utilisateurs, c’est de plus un logiciel potentiellement portable, qui pourra donc si le projet Mono le permet tourner sous Linux, Mac OS etc. Bref, un programme qui n’arrange pas les affaires de Microsoft, donc quel est l’intérêt de .NET pour Microsoft (et les utilisateurs….) ? Si les applications étaient directement compilé en langage machine, elles seraient moins pénibles pour les utilisateurs finaux, elles seraient, à priori, tout aussi agréable pour les développeurs, et elles rendraient plus difficile le portage des applications .NET sur d’autres plateforme, ce qui est mauvais pour les utilisateurs, mais bon pour la firme de Redmond. J’ai l’impression qu’avec .NET, Microsoft va droit dans le mur, si tous les logiciels Microsoft et les clients lourds pour Windows sont écrit en .NET les utilisateurs petit à petit fuiront ces logiciels comme ils le font avec Windows Vista (qui à aujourd’hui pour seul défaut sa lourdeur), Windows Vista qui ne peut pour l’instant être utilisé sur les ultra-portables justement à cause de sa lourdeur, ceci à obligé la firme a maintenir le vieillissant Windows XP afin de ne pas laisser Linux s’accaparer tout le marché.

Je pense qu’encore aujourd’hui, le C et le C++ ont encore de l’avenir, même si d’autres langages compilé en langage machines mais disposant de ramasse-miettes pourraient bien leur faire de l’ombre. Pour les applications Web, je pense que Java suffit largement, et je ne pense pas que les lacunes de Java soient assez rédhibitoires pour privilégier .NET.

dimanche 5 octobre 2008

L'optimisation des fonctions récursives en C/C++




Lors de mes pérégrinations geekesques, j’ai pu entendre dansquelques contrées universitaires, que les compilateurs C/C++ savaient optimiserles fonctions récursives. Certains disaient qu’elles étaient transformé enboucles itérative d’autres disaient que si elles étaient écrites correctementelles devenaient récursives terminales.

Qu’est-ce qu’une fonction récursive correctementécrite ?

int fonction_recursive(int parametre){

if(parametre==0){



return parametre;

}

else

{

int tmp=parametre- 1;

return fonction_recursive(tmp);

}



}



C’est une fonction qui retourne uniquement un appel de fonction.



Ce que j’appelle une fonction récursive non correctement écrite c’est :

int fonction_recursive(int parametre){

if(parametre==0){

return parametre;

}

else

{

int tmp=parametre- 1;

returntmp + fonction_recursive(tmp);

}



}



Ici le return contient un appel de fonction plus uneopération. On m’a dit que ce type de fonction n’est pas optimisable par lecompilateur car pour mémoriser la variable tmp, le compilateur devra la placersur la pile. La pile grossira a chaque appel de fonction, ce qui nuira auxperformances, de plus à partir d’un certain nombre d’appels on se trouveconfronté a un stack overflow. On m’a dit aussi que certains compilateurs commeGCC sont capable d’optimiser les fonctions récursives correctement écrites.J’entends par optimisation effectuer les appels récursifs sans faire grossir lapile (vu qu’aucune variable n’a besoin d’être mémorisé) et donc sans aller audevant de quelques déconvenues (stack overflow…).

Ne sachant pas si le compilateur C/C++ de visual studio 2008pouvait en faire autant j’ai décidé de mener une expérience. Deuxcompilateurs : GCC 3.4.5 (mingw) et le VC++ 2008 le tout sous Windows.

Sur les deux plateformes la fonction correctement écrite estoptimisé, petit bémol VC++ (contrairement à GCC) n’est pas capable d’optimiser les fonctionset de générer des informations de débogage. Du coup on ne peut pas voir avec ledébogueur si la pile grossit ou pas. Pour s’avoir si l’optimisation était passéej’ai du passé en paramètre à la fonction un argument de très grande valeur.Cette valeur provoquait un stack overflow sans optimisation. Avecl’optimisation la fonction se terminait sans erreur.

La fonction non correctement écrite est (à ma grandesurprise) optimisé par VC++ mais pas par GCC (expérience à renouveler avec GCC4.3), la encore seule un argument de très grande valeur m’a permis de vérifierque l’optimisation a été bien effectuée.

Metal hardcore et Metalcore

Certes, metalcore est étymologiquement la contraction de metal hardcore, mais je constate qu’aujourd’hui, le metalcore ne mérite pas vraiment son suffixe. En effet, j’ai du mal à voir le point commun entre killswitch engage et hatebreed… Ils sont pourtant casés dans la même boite : le metalcore. Sans être mauvaise fois, je dois reconnaître qu’on retrouve quelques éléments hardcore (vocaux pour la plupart…) dans la plupart des groupes de la vague metalcore, mais ces éléments sont tellement rares et tellement peu significatifs que je ne pense pas qu’on puisse caser ces groupes dans le metal hardcore. Quand je parle de metal hardcore je parle d’un mélange de metal et de hardcore. Quand je dis hardcore, je pense évidement à des groupes comme outbreak, sick of it all, madball etc… Si l’on retrouve aisément des influences hardcore dans des groupes de metal hardcore comme hatebreed, terror, biohazard elles sont moins évidentes à trouver dans des groupes comme trivium ou bleeding through. Par contre il n’est guère compliqué de retrouver des influences death, thrash, heavy dans les groupes de la vague metalcore. Ces groupes semblent d’ailleurs très influencés par le death melodique suédois (in flames, soilwork, arch enemy etc…) au point qu’on trouve plus de similitude entre la scène death scandinave et ces groupes qu’avec les groupes de metal hardcore que j’ai cité plus tôt, paradoxal non ? Cette confusion des genres conduit à des aberrations comme the black dahlia murder (groupe américain pratiquant un death metal « à la suédoise ») qui est classé dans le metalcore, alors que ce groupe n’a manifestement rien de hardcore. A vrai dire, aujourd’hui, tout ce qui n’est pas du death, du black, du heavy, du hardcore, du neo, du thrash est classé dans le metalcore. C’est pour cela que je fais la différence entre les groupes de metal hardcore (aux influences hardcore bien marquées) et les groupes de metalcore (aux influences death suédoise).