mdlh a écrit 404 commentaires

Vu son adoration pour Knuth, il n'est pas impossible qu'il attende que ce dernier finisse The Art of Computer Programming pour finir le JMPL, question de courtoisie.

petit commentaire a propos du nom de l'archive: Le nom de famille de Benj c'est Bayart avec un t, comme TeX. Sinon tu risques de le facher.

Il me semble que l'on parle de trilateration, et non de triangulation dans ce cas specifique.

La triangulation estime la position d'un objet par rapport a la direction ou cet objet ce trouve (mesuree par an angle fait avec une direction repere) par rapport a des positions connues.

La trilateration est basee sur l'intersection de plusieures spheres, dont on connait la position des centres et plus ou moins leur rayon. Dans le cas d'antennes, la distance est estimee en utilisant la puissance mesuree.

Oui on peut effectivement. Il existe pas mal de solutions, encore faut-il que le programmeur ne soit pas epuise trop tot!

Pour les publications, on est attente de reponses des conferences.

A long terme c'est sous une license approuvee par l'OSI.
On gere d'autres choses que la memoire (taille des blocks par exemple) mais l'idee est la. Il y a plusieurs cibles mais en general la sortie est du source code, qui peut etre de l'OpenCL, mais optimise pour une cible donnee.
Si effectivement OpenCl offre une certaine souplesse au niveau ecriture et permet a partir d'un seul source code d'obtenir quelque chose d'executable sur les cartes AMD, NVidia, Lrb et meme des processeurs multi-coeurs, l'experience montre que si l'auteur veut obtenir quelque chose de performant, il faut malheureusement un source OpenCl ecrit pour chacune des cibles. C'est a ce niveau la que l'on se situe: Un language source en entre simplifiee, plusieurs code OpenCl en sortie.
On aimerait pouvoir se passer de la couche OpenCl, mais a part pour des binaires a executer sur des CPUs, on a aucun moyen de produire des executables pour les gpus, et Larrabee encore moins.

Sinon, pour ce qui est du rapprochement entre le GPU et le processeur, si cela va effectivement reduire les latences qui sont significatives pour des petits calculs, la bande passante entre la memoire et le GPU va etre grandement reduite. Hors beaucoup d'algos avances qui tournent aujourd'hui sur GPU sont malgre tout limite par la bande passante. Autant dire qu'ils vont prendre du plomb dans l'aile et que je ne suis pas certain que ce raprochement sera percu finalement comme le saint graal.

Je travaille sur la realisation d'un compilateur dont le but est de simplifier un peu la vie du programmeur pour ecrire des algos pour GPU. Le language dans l'esprit n'est pas eloigne de CUDA et de C. Cependant, un certain nombre d'elements du languages disparaissent. Ce sont ces memes elements qui influencent en partie la performance de l'algo sur ces GPUs. Sans rentrer dans les details et pour rester comprehensible pour ceux qui ne sont pas famillier avec CUDA, je vais faire une petite analogie avec le language C.

Il y a quelques annees, il etait courant d'utiliser le mot-clef "register" afin d'ameliorer les performances d'un algo. La difficulte etant de determiner quelles variables allaient recevoir ce mot-clef. Ensuite, les compilos sont devenus plus performants et, sauf quelques rares cas, sont en meilleur position pour detecter dans quels cas une variable doit rester dans un registre, ou dans quel cas il est plus intelligent de stocker la variable en memoire pour faire de la place.

Le principe ici est le meme: Le compilateur fait le boulot et adapte en fonction de la carte GPU cible.

Au passage, le langage propriétaire de CUDA comme OpenCL se base sur C99

Au passage, Cuda est un sous-ensemble de C++ plus que C99 etendu. Pour preuve la gestion de la memoire texture sous forme de templates et quelque declarations ici et la qui relevent de C++ plutot que de C.

En d'autres termes, crois-tu possible de mettre une couche d'abstraction au dessus d'un tel framework ?
C'est en cours de part chez moi ;-)

clang est un front-end qui transforme le code source en arbre syntaxique qui est ensuite traduit dans une forme intermediare que comprend LLVM. A moins que le resultat fournit par clang soit sous une forme incomprehensible ou confuse telle que LLVM ne peut rien optimiser, je doute qu'echanger clang avec le front-end de GCC se traduise pas une modification des performances de l'executable produit.

On peut tout à fait utiliser un véhicule uniquement sur circuit privé.

comme par exemple Chris Lattner? Employe Apple, travaillant sur LLVM?

Certes, mais au moins il existe ce droit dans cette declaration. Qu'elle n'ai pas de valeur en France, compte tenu de la qualite globale de leur argumentaire, c'est un detail mineur!

"le droit d'auteur est un droit de l'homme"

Celle là, c'est la meilleure.

Ah bon?

Declaration universelle des droits de l'homme, article 27:
Toute personne a le droit de prendre part librement à la vie culturelle de la communauté, de jouir des arts et de participer au progrès scientifique et aux bienfaits qui en résultent.
Chacun a droit à la protection des intérêts moraux et matériels découlant de toute production scientifique, littéraire ou artistique dont il est l'auteur.

quel serait l'intérêt de ces industriels de cacher ainsi leurs produits ?
A mon avis le Top 500 leur fait une bonne pub donc cela me semblerait bizarre qu'un fabricant cache délibérément les performances de ses produits non ?

Pour les fabricants peut-etre mais il faut malgre tout l'autorisation des clients. Il n'est pas difficile d'imaginer que, dans un secteur competitif, la non divulgation d'information sur les moyens mis en place soient strategiques.

Non.

Le ADD binaire ne s'applique que pour des entiers ou des flottants. Dans le cas de pas mal de language interpretes, surtout ceux avec un typage dynamique comme javascript, ce n'est pas parce que tu as:
i = appel_fonction (j)
k = i+1
et que jusque la tu as toujours eu i etant un entier, que tu n'auras pas a un moment appel_fonction (...) retournant une classe string, auquel cas i+1 est completement different. A moins que tu ne prouves que appel_fonction (...) retourne toujours un entier. On peut bien sur montrer un exemple avec un cas evident. Les cas reels sont quand a eux bien moins evident. Pour un programme javascript entier, ca peut prendre plusieurs secondes. Alors en temps reel...

en très gros, parce que j'avoue ne pas avoir tout compris, les améliorations en questions sont issues de recherches assez poussées de grosses têtes en université, et que parait-il, ce genre d'optimisation est l'avenir dans les interpréteurs de langage, les compilateurs en bytecode et cie...

Pour simplifier comment ca marche:
Il faut imaginer comment l'interpreteur fonctionne: une boucle sur le flux de bytecode et a l'interieur un gros switch pour chacune des valeurs possibles.

Pour chaque "case", le code effectue un certain nombre de tests: C'est quoi le type de la variable en entree? est-ce que la valeur est bien definie... ensuite il effectue le traitement approprie puis stocke le resultat en respectant une certaine convention comme ca le code qui est associe au prochain bytecode trouve tout comme il veut, quel qu'il soit. Mine de rien, une simple addition, ca prend du temps avec toute les verifications qui vont avec.

Ici l'idee est de dire: Au lieu d'avoir un case pour chaque bytecode, on pourrait rajouter des cas qui traite 2 bytecode successifs. La combinaison des deux codes permet au compilateur de supprimer des tests redondants, eviter une sequence stockage puis rechargement...

C'est pas nouveau et on trouve dans quelques interpreteurs ce genre de regroupement. Les sequences choisies sont celles qui sont communes a la majorite des applications. En fait, on parle de trace.

En fait, il m'est arrive il y a environ 2 ans de le faire manuellement pour certains code scientifiques (les sequences etant specifiques, peut reutilisables) dans python.

L'idee developee ici est de dire: chaque application a ses propres traces characteristiques. Par exemple une boucle: le corps de la boucle ou une partie peut contenir une sequence de bytecode tres frequement executee. C'est ce que fait l'optimiseur:
- construction des traces;
- dermination des traces les plus frequement utilisee;
- emition et optimisation "JIT" du code interpreteur correspondant a l'execution sequentielle de chacun des "sous-codes" de l'interpreteur.

Donc oui, le concept applique ici n'est pas specifique a javascript, car l'optimiseur s'applique a n'importe quel bytecode. Mais les resultats en terme d'amelioration de performance dependent des optimisations trouvees par le compilateur. Ca depent du code source lui-meme et du compilo.

Tu sais, a 15km d'altitude, le planneur peut se permettre de piquer quelque secondes pour prendre de la vitesse.

Je ne suis pas de ceux qui le crie. J'essaye plutot de m'y interesser. Et plus j'apprends, plus je m'oppose a ceux qui le disent gratuitement.

Sinon, pour le non-lieu... c'est au moment de l'instruction il me semble, ce qui semble etre dit par ton lien. Le proces vient apres, si le procureur decide de saisir dans le cadre d'un crime. Donc le procureur n'a pas a prouver aupres du juge que la personne est inoccente dans ce cas. Il ne saisit pas.

Juste pour ma curiosite: Dans quel cas une victime peut accuser sans l'aval du procureur? Il me semblait que c'etait le procureur qui apres enquete prenait la decision de poursuivre au Penal ou non?
Il me semblait que la victime n'avait que 2 possibilites pour etre presente dans une juridiction penale:
- Constitution en partie civile
- Citation directe

Dans le premier cas, le procureur doit decider de poursuivre. Dans le second cas, c'est impossible pour les crimes car la citation directe ecarte l'instruction ce qui n'est pas possible lors d'un crime.

Pour conclure: tu as entierement raison.
Article 428 du code penal:
"L'aveu, comme tout élément de preuve, est laissé à la libre appréciation des juges."

Confondu avec un melange de mauvais souvenirs et le civil.

Mea culpa

Pour ajouter: L'aveu doit etre en effet valide par le juge. Ce qui inclue de s'assurer que celui qui commet l'aveu soit conscient des consequences d'un tel aveu, fait en dehors de toute pression (volontaire), qu'il corresponde avec les faits connus.

Tu as raison. Je partais du principe que le procureur ne s'amusait pas a poursuivre un individu qu'il estimait etre non coupable des faits que lui meme lui reproche.

Excellent exemple. Ici, c'est surtout l'abscence de la certitude de la peine. Non seulement le risque de se faire prendre est faible, mais en plus le risque est peu eleve de se faire condamner. Au pire la premiere fois, c'est "Petit polisson, c'est pas bien."

La moralite a effectivement plus de pouvoir. Mais certains s'en foutent.

Par contre il m'est arrive de discuter avec d'anciens delinquants. Il se sont "ranges" a regret. Juste parce que maintenant ils ont des gosses et ne veulent pas les laisser seuls si ils vont en taules. Passer quelque mois en taules ne les effrayaient pas [et certains l'on fait et s'en foutent, le jeu en valant la chandelle]. Mais lorsque l'environnement change, ils y repensent.

Connait pas le droit US, mais en France un juge est lie a une telle declaration dans un tribunal. Meme si il a un doute, il ne peut que condamner.

C'est une consequence du fait qu'un juge ne peut juger que sur ce qui lui est presente. Si la defense avoue sa culpabilite, le juge ne peut innocenter. Idem si le juge s'appercoit que la defense aurait pu demander l'application d'une loi qui aurait limite la peine: Si ce n'est pas souleve, le juge ne peut rien faire.

Croire que la peine empechera tout ou croire que la peine n'empeche rien du tout sont deux extremes.

Ton exemple est bien choisit. Mais quitte a prendre un extreme, prenons un autre: Traverser hors des passages pietons [encore faut-il que tu saches que c'est une contravention]. Le probleme dans cet exemple etant certes l'abscence de la certitude de la peine. Et de loin.