Disons qu'il y a un léger côté "Mooresque" au film, sans aller autant dans la simplification que le documentariste.
On est un peu emporté par le flot, et ce film est surtout intéressant pour intéresser les personnes non sensibilisée à cette approche à cette problématique et à se documenter par elle même.
Dans l'article elle dit quand même qu'elle souhaite du succès au film ! :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Surtout que les travaux de Douglas EngelBart sont très profond autant du point de vue philosophique que technique.
C'est AMHA beaucoup plus visionnaire que pas mal d'avancées algorithmique, qui sont plus faciles à approcher.
Il fallait imaginer au début des années 50 de commander une machine avec une interface sur un écran, alors que celui-ci n'existait que depuis quelques années !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour ceux qui aimerait creuser un peu plus cette question de l'origine du néolibéralisme, je vous invite à visionner une interview de Christian Laval, l'auteur de "L'homme économique, les racines du néolibéralismes".
Dans cet ouvrage hyper documenté et très fourni, Christian Laval (historien de la sociologie et de la philosophie) remonter jusqu'au moyen age (en survolant rapidement les racines antiques) pour comprendre comment on a pu en arrivé là.
On y comprend que cela est beaucoup plus profond qu'il n'y parait :
Tu demandes si le compilo Java ne peut pas faire de l'analyse globale, je te répond non et explique pourquoi.
Tu me répond que je me trompe parce que LLVM peut le faire.
Je sais que LLVM peut le faire, mais ce n'est pas répondre à ta question.
LLVM travaille sur un code assez bas niveau en analyse plus ou moins globale, effectivement c'est possible.
C'est plus une question de choix d'approche et de leur conséquence que de "qui a la plus grosse, et est pas assez fort pour le faire"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ca a été un peu dit plus haut, mais en gros ce n'est pas possible car Java fait de la compilation séparée.
Java, comme la plupart des langages objet fonctionne sur le principe de "Open World Assumption" : le code compilé peut recevoir du code par la suite, au runtime (plugin, etc...)
Ce que tu propose implique de partir sur du CWA ( Closed World Asumption), qui consiste à travailler sur la fermeture transitive du graphe du code où là tu peux virer le code mort. Les compilateurs basés là dessus sont rares (SmartEiffel et Lisaac à ma connaissance)
Gcc le fait en partie car sur du code procédural comme du C, c'est faisable. Sur de l'objet, c'est beaucoup plus compliqué, car le typage devenant dynamique, tu te retrouves avec des sites d'appels dans tous les sens et ta complexité explose (np complet).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Nous seront toujours édifiés devant la légèreté des application JavaEE que tout javaiste encence ( sur linuxfr, Dude en est le pretre attitré ), aussi aimerais-je savoir si un exemple aussi confondant de performance, de citoyenté (concernant les économies d'énergies) tel que http://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack(...)
est réalisable avce ton framework.
Je pense qu'il faut doubler cette stack qui est beaucoup trop petite pour prétendre à l'application imbitable qui rassure l'ingénieur dans sa maîtrise d'une usine à gaz dont il est le seul garant, gardant ainsi son territoire.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je constate un léger mieux, mais encore assez légé. Par contre, je constate avec plaisir que pour le moment, il ne s'emballe pas à consommer toutes les ressources CPU pour certaines pages chargées de javascript.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai pas vraiment étudié la question, mais si on on a un ORM où :
- Chaque tables est un objet singleton (en prototype, il sera non clonable). On pourra prendre comme convention qu'il a un s à la fin (comme dans ruby activerecord). Exemple, l'objet Tables
- chaque objet au singulier est clonable et représente une ligne d'une table. Exemple Tables contient une liste de Table.
Là ça pourrait marcher, grâce au fait qu'on ai un singleton par table ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
ça pose une question très profonde : comment éviter les framework bloatware ?
Parce que même si tu compiles tout ça, et que le compilateur te vire les 3/4 des appels qui ne sont que des appels, tu te retrouves avec un paquet de code qui ne sont que des abstractions.
Or, une abstraction, c'est une organisation humaine destinée à se retrouver mentalement dans la complexité du software.
On a le choix à faire du spécifique comme tu as fait, mais à donc ne plus avoir d'outil de "prémachage" sous la main, ou avoir les outils de prémachage et à devoir se battre contre une usine à gaz (où Spring/hibernate, etc... en sont le paroxysme, j'ai subi moi aussi...) tellement complexe qu'elle rend le développement impossible.
La hauteur de niveau des langages peut être une réponse. On peut voir par exemple avec Ruby, que certaines choses ne sont pas forcément nécessaire (au prix de performances moindre évidemment), vu l'approche interprété.
Le problème, c'est qu'en bas, on a toujours une bête machine de turing de base.
je ne sais pas ce qu'on pourrait faire de mieux... Un générateur de code, qui prend la description de ce qu'on veut faire, et génèrerai un truc spécifique... lisible ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Même si gcc est très bon pour ce genre de choses, les motifs qu'il est capable de paralléliser restent très limités, et bien souvent il suffit qu'il y ait un pointeur qui traine pour tout foutre en l'air. Dans la pratique, écrire du code que gcc peut paralléliser est souvent au moins aussi complexe que d'écrire directement le code parallèle avec les intrinsics. Et le plus embêtant c'est que la moindre petite modification anodine peut rendre le code non parallélisable, donc un patch par quelqu'un qui ne fait pas super gaffe peut-être catastrophique.
Le compilateur Lisaac a accès à une sémantique très "bas niveau" des calculs à effectuer, car les nombres sont tous des objets, et les opérateurs sont tous des messages classiques d'objets, à part les quelques primitives ( - , / , * , << ).
Comme les boucles sont elles mêmes déroulées de manière complète dans le langage très minimaliste en interne du compilateur, détecter des patterns de calculs afin de les optimiser au poil pour que GCC autovectorise, n'est pas insurmontable.
De plus, comme les boucles sont très uniformes de par le fait qu'elles sont définies en librairie, il est facile de les détecter et de cracher du C autovectorisable.
En C, ecrire du code autovectorisable est très difficile, mais pour un langage où le modèle est uniforme et assez minimaliste (c'est donc valable pour quelques langages), la simplicité fait que les patterns reviennent toujours au même et que leur détection en est ainsi facilitée.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Pour te situer le niveau du bonhomme, Dominique Colnet (SmartEiffel) m'a raconté que lorsque SmartEiffel est devenu GNU, il devait pour une raison ou une autre lui envoyer des données (en tar.gz je suppose). Dominique lui propose de lui envoyer ça en FTP : on est au début des années 90 et le mail était limité à l'époque.
Stallman lui répond que c'est pas possible pour lui car il n'existait pas de client ftp libre, et qu'il devait demander à son assistant de le faire pour ne pas toucher à un logiciel propriétaire (sale donc).
Assez hallucinant !
(J'avais pas demandé à Dom, mais ça m'a étonné qu'il n'existait pas de client ftp libre au début des années 90)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets
C'est ce que je pense, et je crois savoir que c'est ce que pense l'auteur du Lisaac.
On priorise comme on peut, tellement le roadmap est chargé.
La compilation séparée est un objectif depuis longtemps, mais ça pose pas mal de problèmes, car comme c'est quand même un projet de recherche, il y a pas mal de choses à inventer pour combiner le meilleur des deux techniques.
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
Où as-tu lu dans ce journal que je n'admettais pas qu'il y avait de limitations dans le langage ?
J'ai juste parlé des contrats hérités.. Ne me fait pas de procès d'intentions s'il te plait.
Évidemment que je l'admet, évidemment que le chemin est encore long et que le produit a beaucoup de limites.
Où ais-je dis le contraire sur ce journal ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Euh là tu montresuniquement que le bytecode est toujours de haut niveau, et que donc le boulot du JIT revient à compiler un code de haut niveau en code natif... comme le compilo Lisaac.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
Mais comme il ne fait pas d'analyse globale. Ton call on null pète au runtime, pas à la compilation, parce que la compilation te l'empêche intrinsèquement.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.
Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..
Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Re..
1) Pourquoi utiliser C (et ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page : http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pensais comme toi que c'était petit, mais en fait c'est un marché énorme, et ça ne fait que commencer !
Regarde autour de toi tout ce qui peut comporter un micro-controleur.. Tiens je fais l'exercice là maintenant :
- Chaine Hifi (pour gérer les programmation, l'interface, les fonctions réveils, etc...)
- Télé
- Four, lave-vaisselle, lave-linge
- décodeur tnt, dvd, etc...
- Clim, chaudière
- Etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Par contre, les bugs de logique me demandent souvent beaucoup de temps. Là ou en Lisaac je purais mettre un contrat, en C je peut mettre une assertion, donc la manière de faire est différente mais le résultat est proche.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités. Et de l'aveur de Dominique Colnet, il lui arrive assez souvent que son code pète sur un contrat posé il y a longtemps et assez haut dans l'arbre d'héritage.
Le fait qu'ils s'accumulent, et que tu puissent les poser sur du bas niveau (vu que tout est objet, tu peux les poser sur toutes les opérations), c'est un peu mieux que les asserts de C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Timaniac, je crois que tu travailles plus sur de l'informatique de gestion, et Nicolas sur de l'informatique embarqué très proche du processeur (Ils nous as souvent décrit ce qu'il fait).
L'info de gestion étant mon métier depuis pas mal de temps, je suis assez d'accord avec ce que tu dis, qui est pertinent pour l'info de gestion.
Mais, regardes un peu comment on développe des algos pour les moteurs d'avions (Nicolas nous a fait une pres sur le sujet, on peut te la passer s tu veux), ça n'a rien à voir.
Programmer pour de l'embarqué petit (genre des ARM à 16mhz et moins de 256 ko de mémoire), idem.
Ce sont de environnement, ou tu ne peux même pas mettre de code de debug dans ta cible, et où tu n'as pas forcément d'émulateur (sur ARM ça se trouve, mais sur d'autres archi...).
Donc, sur ce genre de cible, il vaut mieux que tout soit nickel à la compil.
Or, un des buts de lisaac, voire même sa cible principale, c'est la programmation système et embarqué. Donc les besoins ne sont pas les mêmes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Si je me souviens bien, la version lisaac prenait pas mal de mémoire de plus que la version C, ce qui nécessitait l'utilisation du swap, et donc ralentissait pas mal le calcul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Livre != film ?
Posté par Ontologia (site web personnel) . En réponse au journal La stratégie du choc. Évalué à 2.
On est un peu emporté par le flot, et ce film est surtout intéressant pour intéresser les personnes non sensibilisée à cette approche à cette problématique et à se documenter par elle même.
Dans l'article elle dit quand même qu'elle souhaite du succès au film ! :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Turing Awards
Posté par Ontologia (site web personnel) . En réponse au journal Prix Turing 2010. Évalué à 1.
C'est AMHA beaucoup plus visionnaire que pas mal d'avancées algorithmique, qui sont plus faciles à approcher.
Il fallait imaginer au début des années 50 de commander une machine avec une interface sur un écran, alors que celui-ci n'existait que depuis quelques années !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Pour aller plus loin
Posté par Ontologia (site web personnel) . En réponse au journal La stratégie du choc. Évalué à 5.
Dans cet ouvrage hyper documenté et très fourni, Christian Laval (historien de la sociologie et de la philosophie) remonter jusqu'au moyen age (en survolant rapidement les racines antiques) pour comprendre comment on a pu en arrivé là.
On y comprend que cela est beaucoup plus profond qu'il n'y parait :
http://www.dailymotion.com/video/x3zshy_christian-laval-lhom(...)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La nuit du code mort vivant
Posté par Ontologia (site web personnel) . En réponse au journal Des outils d'audit de code Java. Évalué à 2.
Le code mort dans un classe c'est intéressant, mais assez limité, et ça rejoint ce que tu dis, le programmeur est quand même censé le voir ! :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le compilateur ne fait pas ça ?
Posté par Ontologia (site web personnel) . En réponse au journal Des outils d'audit de code Java. Évalué à 2.
Tu me répond que je me trompe parce que LLVM peut le faire.
Je sais que LLVM peut le faire, mais ce n'est pas répondre à ta question.
LLVM travaille sur un code assez bas niveau en analyse plus ou moins globale, effectivement c'est possible.
C'est plus une question de choix d'approche et de leur conséquence que de "qui a la plus grosse, et est pas assez fort pour le faire"
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le compilateur ne fait pas ça ?
Posté par Ontologia (site web personnel) . En réponse au journal Des outils d'audit de code Java. Évalué à 2.
Java, comme la plupart des langages objet fonctionne sur le principe de "Open World Assumption" : le code compilé peut recevoir du code par la suite, au runtime (plugin, etc...)
Ce que tu propose implique de partir sur du CWA ( Closed World Asumption), qui consiste à travailler sur la fermeture transitive du graphe du code où là tu peux virer le code mort. Les compilateurs basés là dessus sont rares (SmartEiffel et Lisaac à ma connaissance)
Gcc le fait en partie car sur du code procédural comme du C, c'est faisable. Sur de l'objet, c'est beaucoup plus compliqué, car le typage devenant dynamique, tu te retrouves avec des sites d'appels dans tous les sens et ta complexité explose (np complet).
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Halala Java
Posté par Ontologia (site web personnel) . En réponse au journal Terracotta monte les JVM en grappe. Évalué à -1.
??
OK je -----> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Une image vaut mieux que tout un discours
Posté par Ontologia (site web personnel) . En réponse au journal JASMINe à la rescousse des architectes JavaEE. Évalué à 8.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Légèreté à battre
Posté par Ontologia (site web personnel) . En réponse au journal Jachère l'ultime applicatif JavaEE de consommation de ressources de fermes de calcul. Évalué à 5.
http://ptrthomas.files.wordpress.com/2006/06/jtrac-callstack(...)
est réalisable avce ton framework.
Je pense qu'il faut doubler cette stack qui est beaucoup trop petite pour prétendre à l'application imbitable qui rassure l'ingénieur dans sa maîtrise d'une usine à gaz dont il est le seul garant, gardant ainsi son territoire.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Google va avoir des problèmes avec le monde du libre
Posté par Ontologia (site web personnel) . En réponse au journal Android éjecté du noyau: l'avis de Greg Kroah-Hartman. Évalué à 10.
Qui deviendra le hérault du libre ?
Falloir que Google fasse attention, car même avec des milliers d'ingénieurs très compétents, le bloatware à la Microsoft pointe son nez..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# On pourrait peut être réécrire Hurd en Lisaac ?
Posté par Ontologia (site web personnel) . En réponse au journal Arch Hurd: Nouveau projet autour de GNU/Hurd. Évalué à 7.
- NON !
Bon ok, je ----------------> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Django
Posté par Ontologia (site web personnel) . En réponse au journal Choisir un framework web.... Évalué à 1.
# viemacs /etc/apache2/sites-available/monsiteQuoi ????!!
Tu n'utilises pas Vim ???!!!
Ok, je -----> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Django
Posté par Ontologia (site web personnel) . En réponse au journal Choisir un framework web.... Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Rapidité sous macOS
Posté par Ontologia (site web personnel) . En réponse à la dépêche Namoroka, Firefox 3.6, est sorti. Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La différence principale entre php et c++
Posté par Ontologia (site web personnel) . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 2.
- Chaque tables est un objet singleton (en prototype, il sera non clonable). On pourra prendre comme convention qu'il a un s à la fin (comme dans ruby activerecord). Exemple, l'objet Tables
- chaque objet au singulier est clonable et représente une ligne d'une table. Exemple Tables contient une liste de Table.
Là ça pourrait marcher, grâce au fait qu'on ai un singleton par table ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: La différence principale entre php et c++
Posté par Ontologia (site web personnel) . En réponse au journal On n'est pas vendredi et pourtant : impact environnemental de nos langages. Évalué à 4.
Parce que même si tu compiles tout ça, et que le compilateur te vire les 3/4 des appels qui ne sont que des appels, tu te retrouves avec un paquet de code qui ne sont que des abstractions.
Or, une abstraction, c'est une organisation humaine destinée à se retrouver mentalement dans la complexité du software.
On a le choix à faire du spécifique comme tu as fait, mais à donc ne plus avoir d'outil de "prémachage" sous la main, ou avoir les outils de prémachage et à devoir se battre contre une usine à gaz (où Spring/hibernate, etc... en sont le paroxysme, j'ai subi moi aussi...) tellement complexe qu'elle rend le développement impossible.
La hauteur de niveau des langages peut être une réponse. On peut voir par exemple avec Ruby, que certaines choses ne sont pas forcément nécessaire (au prix de performances moindre évidemment), vu l'approche interprété.
Le problème, c'est qu'en bas, on a toujours une bête machine de turing de base.
je ne sais pas ce qu'on pourrait faire de mieux... Un générateur de code, qui prend la description de ce qu'on veut faire, et génèrerai un truc spécifique... lisible ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Le compilateur Lisaac a accès à une sémantique très "bas niveau" des calculs à effectuer, car les nombres sont tous des objets, et les opérateurs sont tous des messages classiques d'objets, à part les quelques primitives ( - , / , * , << ).
Comme les boucles sont elles mêmes déroulées de manière complète dans le langage très minimaliste en interne du compilateur, détecter des patterns de calculs afin de les optimiser au poil pour que GCC autovectorise, n'est pas insurmontable.
De plus, comme les boucles sont très uniformes de par le fait qu'elles sont définies en librairie, il est facile de les détecter et de cracher du C autovectorisable.
En C, ecrire du code autovectorisable est très difficile, mais pour un langage où le modèle est uniforme et assez minimaliste (c'est donc valable pour quelques langages), la simplicité fait que les patterns reviennent toujours au même et que leur détection en est ainsi facilitée.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Je me réfère souvent à cette page du projet GCC ( http://gcc.gnu.org/projects/tree-ssa/vectorization.html ) qui décrit quelles type d'écriture sont éligible à l'autovectorisation (utilisation de MMX, SSE, etc...)
Parles-tu de ce genre de vectorisation ou d'autre choses ?
S'il s'agit de ce genre de vectorisation, en quoi le C89 a t-il a voir avec ce genre d'écriture ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: GNOME pourrait se séparer du projet GNU
Posté par Ontologia (site web personnel) . En réponse au journal GNOME pourrait se séparer du projet GNU. Évalué à 4.
Stallman lui répond que c'est pas possible pour lui car il n'existait pas de client ftp libre, et qu'il devait demander à son assistant de le faire pour ne pas toucher à un logiciel propriétaire (sale donc).
Assez hallucinant !
(J'avais pas demandé à Dom, mais ça m'a étonné qu'il n'existait pas de client ftp libre au début des années 90)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
C'est ce que je pense, et je crois savoir que c'est ce que pense l'auteur du Lisaac.
On priorise comme on peut, tellement le roadmap est chargé.
La compilation séparée est un objectif depuis longtemps, mais ça pose pas mal de problèmes, car comme c'est quand même un projet de recherche, il y a pas mal de choses à inventer pour combiner le meilleur des deux techniques.
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
Où as-tu lu dans ce journal que je n'admettais pas qu'il y avait de limitations dans le langage ?
J'ai juste parlé des contrats hérités.. Ne me fait pas de procès d'intentions s'il te plait.
Évidemment que je l'admet, évidemment que le chemin est encore long et que le produit a beaucoup de limites.
Où ais-je dis le contraire sur ce journal ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
Mais comme il ne fait pas d'analyse globale. Ton call on null pète au runtime, pas à la compilation, parce que la compilation te l'empêche intrinsèquement.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.
Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..
Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Re..
1) Pourquoi utiliser C (et ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page :
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
Regarde autour de toi tout ce qui peut comporter un micro-controleur.. Tiens je fais l'exercice là maintenant :
- Chaine Hifi (pour gérer les programmation, l'interface, les fonctions réveils, etc...)
- Télé
- Four, lave-vaisselle, lave-linge
- décodeur tnt, dvd, etc...
- Clim, chaudière
- Etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités. Et de l'aveur de Dominique Colnet, il lui arrive assez souvent que son code pète sur un contrat posé il y a longtemps et assez haut dans l'arbre d'héritage.
Le fait qu'ils s'accumulent, et que tu puissent les poser sur du bas niveau (vu que tout est objet, tu peux les poser sur toutes les opérations), c'est un peu mieux que les asserts de C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 2.
L'info de gestion étant mon métier depuis pas mal de temps, je suis assez d'accord avec ce que tu dis, qui est pertinent pour l'info de gestion.
Mais, regardes un peu comment on développe des algos pour les moteurs d'avions (Nicolas nous a fait une pres sur le sujet, on peut te la passer s tu veux), ça n'a rien à voir.
Programmer pour de l'embarqué petit (genre des ARM à 16mhz et moins de 256 ko de mémoire), idem.
Ce sont de environnement, ou tu ne peux même pas mettre de code de debug dans ta cible, et où tu n'as pas forcément d'émulateur (sur ARM ça se trouve, mais sur d'autres archi...).
Donc, sur ce genre de cible, il vaut mieux que tout soit nickel à la compil.
Or, un des buts de lisaac, voire même sa cible principale, c'est la programmation système et embarqué. Donc les besoins ne sont pas les mêmes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Si je me souviens bien, la version lisaac prenait pas mal de mémoire de plus que la version C, ce qui nécessitait l'utilisation du swap, et donc ralentissait pas mal le calcul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker