non, là il s'agit simplement de démontrer une manière de générer du C pour aboutir en terme de génération de code avec un algo "cache oblivious".
mais il y a tout dedans, j'entends les concepts de compilation du monde fonctionnel : la CPS, la state-continuation monade, plus encore une autre sauf erreur une state et je ne sais plus quoi. c'est un papier qui te balance 3 ou 4 concepts pour écrire ton compilateur, dans la veine, famille, purement fonctionnelle. as-tu fais de l'assembleur SIMD? entre la profondeur du pipeline, les branch mis-prediction, les interactions entre cache L1 et L2, je peux t'assurer que tu te tires une balle vite fait, à la pogne. des outils au dessus de asm SIMD, c'est une nécessité, pas de la branlette d'universitaire arrivé là par über bachotage aux p'tit tas de coco, à la ritaline bien bien dosée et qui fondamentalement ne sais rien faire de pragmatique. -- Philippe STRAUSS http://strauss.pas.nu/ Le 28 janv. 2014 à 15:18, dc <[email protected]> a écrit : > On 28/01/2014 12:20, Philippe STRAUSS wrote: >> et des fans de ce paper : >> http://www.cs.rice.edu/~taha/publications/conference/emsoft04.pdf > > Intéressant, oui, fan ? Non... > > Le monde académique continue sa quête du graal du "langage parfait qui résout > tout". > > Il est important d'y penser et d'essayer de nouvelles approches, mais ces > tentatives de trouver une méthode permettant de génèrer des programmes d'un > seul battement de cil me font un peu sourire; en fait c'est surtout cette > insistance a vouloir "mathématiser" la programmation qui me fait marrer. > > Dans cet article, les auteurs se focalisent une fois de plus sur la notion > d'algorithme; en considérant que la structure de donnée "suivra" puisqu'elle > peut-être polymorphe... Or, a mon humble avis, la structure de donnée est > intimement liée à l'algorithme. La complexité de l'ensemble peut résider > exclusivement dans l'algorithme, dans la structure de donnée ou... entre les > deux. > > De nombreux exemples de "langages" destinés à "éduquer" ces "idiots" de > programmeurs ont existés depuis très longtemps : Pascal, Modula, Ada... et > finalement Java. Inutile de parler des trois premiers... Java, avec sa > lourdeur est encore un de ces exemples tendant à démontrer qu'un bon langage > doit être "statique". Ca c'est pour la lourdeur de la syntaxe ! Mais ce qui > tue Java est le Garbage Collector, sensé gèrer la mémoire mieux que ces > "idiots" de programmeurs ! Pensée louable... résultat risible et pathétique. > Les performances de Java étant non métrisable dans bon nombre de situations. > Surtout, les performances étant non-déterministes, la démonstration de la > supériorité du formalisme tourne à la farce. > > Aujourd'hui, la masse d'information à gèrer étant parfois tellement énorme > que l'on est obligé d'adapter la structure de données afin d'assurer des > performances acceptables. L'algorithme etant naturellement affecté par ces > modifications structurelles ! > > Donc, en-dehors de calculs simples du style FFT, je doute que cette approche > (d'ailleurs en contradiction avec d'autres techniques tel que Event Base > Programming, etc.) soit d'une utilité quelconque pour la programmation en > général. > > En matière de concision et de formalisme, les auteurs feraient bien d'étudier > sérieusement APL :-) > > >> (à 40 balais commence à me faire chier d'être seul passionné par ce >> genre de sujets). > > A 56 ans, toujours passionné par les techniques de programmations, mais de > moins en moins à l'écoute d'études d'universitaires sans expérience et > manquant d'esprit critique. Une étude de ce genre devrait suivre le modèle > d'une dissertation, or, dans celle-ci, l'anti-thèse est absente; discréditant > ainsi le reste du discours. > > dc > > _______________________________________________ > gull mailing list > [email protected] > http://forum.linux-gull.ch/mailman/listinfo/gull
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
