C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.
non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.
La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.
là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.
A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.
En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
Le jit de java est du niveau de gcc -o0 ou gcc -o1, des mini optims "à la con" font de gain énorme de performances (genre virer les setter/getter qui ne sont pas inliner !)
Ton programme de preuve pourrait détecter que rien ne borne ton index et donc que tu as potentiellement un trou. Il pourrait déduire des bornes en détectant des tests ou un modulo sur l'élément.
C'est dans ses moments-là, ou il est marrant de constater que diminuer la mémoire dédiés par la VM peut augmenter les performances en rapprochant le déclenchement du GC.
Après, bien sûr, je ne cherche pas à dénigrer ton objectif et toute amélioration est bonne à prendre, mais si tu voyais la qualité générale des codes scientifiques, tu verrais que l’efficacité des algorithmes de résolution et la parallélisation sont des enjeux qui passent bien avant l’optimisation purement au niveau du code.
Il faut comprendre que le code est pourris ou l'inverse ? :)
D'un autre coté, une bonne implémentation peut te fait gagner un facteur 10, mais je suis d'accord qu'un bon algo peut aller bien au delà.
Je ne parle pas des intel à base de gpu non intel.
ATI je me rappelle les triangles qui clignotent, les plantages quasi immédiat. Mais souvent les problèmes sont dans les détails : impossible de passer en veille, ventilo non géré et à fond.
Si je veux jouer j'utilise un ordinateur ayant un OS de console de jeu : un PC windows.
AMD avec fusion doit avoir un support libre des shaders au travers de opengl 4.0 et opencl. AMD a fait le choix de cpu un peu faible, une mer de shaders (32 et 320 de mémoire) pour ses C50 et E-350. Or, sous linux, ils ne sont d'aucun intérêt.
Est-ce que quelqu'un sait si les shaders ATI sont pris en charge sous Linux en opengl ? Et avec quelle version ?
Quand j'écrivais "lourd", c'est pour définir un besoin d'optimisation du calcul. Par exemple, tout ce qui est fait avec matlab n'a pas vraiment besoin de grosses performances.
Une expression mathématique simple comme celle en arctan() présent dans un logiciel temps réel qui a besoin de tenir 2ms de temps de réaction ou bien un calcul de supercalculateur qui tourne pendant des jours correspond à ma définition si l'expression est présente dans les cœurs de boucles, si son temps d’exécution n'est pas négligeable sur le temps total de calcul.
Je n'allais pas aussi loin que les problèmes dont on a un système d'équation qui ne se résolvent pas.
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 3.
C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
"La première sécurité est la liberté"
# Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.
non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
obj.getVoiture().getFirstRoue()
là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ensuite, l'inline par le compilo devrait régler les problèmes de perf.
C'est le "devrait" le problème : le jit de sun ne le fait pas.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
A court terme, c'est parfaitement inutile.
A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.
En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ce genre d'optimisation de "delayed initialisation", se fait aussi à coup de pointeur nul que l'on teste avant utilisation.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Le jit de java est du niveau de gcc -o0 ou gcc -o1, des mini optims "à la con" font de gain énorme de performances (genre virer les setter/getter qui ne sont pas inliner !)
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
ocaml ?
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ton programme de preuve pourrait détecter que rien ne borne ton index et donc que tu as potentiellement un trou. Il pourrait déduire des bornes en détectant des tests ou un modulo sur l'élément.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
euh...
"La première sécurité est la liberté"
[^] # Re: porosité aux virus
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
C'est dans ses moments-là, ou il est marrant de constater que diminuer la mémoire dédiés par la VM peut augmenter les performances en rapprochant le déclenchement du GC.
"La première sécurité est la liberté"
[^] # Re: Marre des captcha
Posté par Nicolas Boulay (site web personnel) . En réponse au journal CAPTCHA. Évalué à 2.
Et avec 10 questions ? :)
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
J'ai fait beaucoup de C, si tu ne fais pas de gros calcul, je te conseil de passer à ocaml. C'est incroyable le gain de productivité.
"La première sécurité est la liberté"
[^] # Re: Pi
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cherche exemple d'expression de calcul lourd. Évalué à 2.
Mais si la microoptimisation est gratuitement faite par le compilateur ?
"La première sécurité est la liberté"
[^] # Re: Pi
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cherche exemple d'expression de calcul lourd. Évalué à 2.
Après, bien sûr, je ne cherche pas à dénigrer ton objectif et toute amélioration est bonne à prendre, mais si tu voyais la qualité générale des codes scientifiques, tu verrais que l’efficacité des algorithmes de résolution et la parallélisation sont des enjeux qui passent bien avant l’optimisation purement au niveau du code.
Il faut comprendre que le code est pourris ou l'inverse ? :)
D'un autre coté, une bonne implémentation peut te fait gagner un facteur 10, mais je suis d'accord qu'un bon algo peut aller bien au delà.
"La première sécurité est la liberté"
[^] # Re: L'argent
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 3.
Je ne parle pas des intel à base de gpu non intel.
ATI je me rappelle les triangles qui clignotent, les plantages quasi immédiat. Mais souvent les problèmes sont dans les détails : impossible de passer en veille, ventilo non géré et à fond.
Si je veux jouer j'utilise un ordinateur ayant un OS de console de jeu : un PC windows.
"La première sécurité est la liberté"
[^] # Re: L'argent
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 3.
Surtout le driver intel est libre, et c'est plus simple à gérer (pour les anciens modèles).
"La première sécurité est la liberté"
[^] # Re: L'argent
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche AMD s’investit dans ses pilotes libres.. Évalué à 5.
AMD avec fusion doit avoir un support libre des shaders au travers de opengl 4.0 et opencl. AMD a fait le choix de cpu un peu faible, une mer de shaders (32 et 320 de mémoire) pour ses C50 et E-350. Or, sous linux, ils ne sont d'aucun intérêt.
Est-ce que quelqu'un sait si les shaders ATI sont pris en charge sous Linux en opengl ? Et avec quelle version ?
"La première sécurité est la liberté"
[^] # Re: Pi
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cherche exemple d'expression de calcul lourd. Évalué à 1.
Quand j'écrivais "lourd", c'est pour définir un besoin d'optimisation du calcul. Par exemple, tout ce qui est fait avec matlab n'a pas vraiment besoin de grosses performances.
Une expression mathématique simple comme celle en arctan() présent dans un logiciel temps réel qui a besoin de tenir 2ms de temps de réaction ou bien un calcul de supercalculateur qui tourne pendant des jours correspond à ma définition si l'expression est présente dans les cœurs de boucles, si son temps d’exécution n'est pas négligeable sur le temps total de calcul.
Je n'allais pas aussi loin que les problèmes dont on a un système d'équation qui ne se résolvent pas.
"La première sécurité est la liberté"
[^] # Re: Curiosité + suggestion
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Cherche exemple d'expression de calcul lourd. Évalué à 2.
Il y a des exemples, je ne l'avais pas vu sous cet angle :)
"La première sécurité est la liberté"
[^] # Re: netbook
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lenove Edge 15. Évalué à 2.
Je parlais de notebook pas de machine qui coute >1000€.
Le dernier semble plus abordable, mais j'ai du mal à croire qu'un i3 ai plus de 5h d'autonomie en usage normal.
"La première sécurité est la liberté"
[^] # Re: netbook
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lenove Edge 15. Évalué à 5.
J'ai un ieeePc N270.
De la à dire qu'un atom c'est le retour au PII à 600 Mhz c'est vraiment être malhonnête ou être mal-informé.
En performance monocore, cela fait presque ça.
"La première sécurité est la liberté"
[^] # Re: netbook
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Lenove Edge 15. Évalué à 2.
http://www.cpubenchmark.net/cpu_lookup.php?cpu=Intel+Celeron+U3400+%40+1.07GHz
On dirait que c'est un poil plus rapide que les E350, mais j'ai un peu peur de l'autonomie réelle.
"La première sécurité est la liberté"