hocwp a écrit 331 commentaires

Bon voila en poussant un peu plus loin le nombre d'éléments.

Avec le 2eme algorithme :

Pour 100000: Lisp = 0.005s C = 0.009s C(O3) = 0.006s
Pour 1000000: Lisp = 0.409s C = 0.432s C(O3) = 0.407s
Pour 10000000: Lisp = 5.469s C = Segmentation fault (normal à cause des indices du tableau)
Pour 100000000: Lisp = 68.193s C = Segmentation fault
Pour 1000000000: Lisp = Plein de warning à la compilation : on atteint la limite de l'implémentation actuelle et des fixnum qui est à 536870911.

Je n'ai rien changer au code en Lisp (juste incrémenté nb-entries). Pour le code en C, je pense qu'il faut passer au malloc à la main et changer le type des indices.

Sinon, voila les derniers nombres amis trouvé avec 100000000 éléments testés :

(89477984 92143456)
(90437150 94372450)
(91996816 93259184)
(93837808 99899792)
(95629904 97580944)
(96304845 96747315)
(97041735 97945785)

Très bonne idée. Voila ce que j'obtiens pour 100000 éléments pour le 1er algorithme.
Python : 48m7.524s
Lisp : 46.021s
C : 46.012s

C'est ça qui est rigolo : on s'extasie sur le premier algo avec le javascript plus rapide que le python, puis le Lisp plus rapide que les 2. Et tout le monde est mis d'accord avec un changement d'algo qui place le python en 1er loin devant les autres. Et enfin le Lisp et le C qui se tire la bourre laissant le python derrière.
Tout ça pour dire que l'algo est vraiment le point central !

Bon ben avec O3, j'ai la même chose que sans pour la première version de l'algo.
Par contre pour le deuxième algo je passe de 0.058 à 0.017. La version en Lisp reste à 0.038 donc elle se place entre le C sans optimisation et le C avec optimisation.

J'ai rajouté une boucle dans l'algo parce que j'était curieux de voir la vitesse du langage et non la vitesse à laquelle il se lance. D'ailleurs sur ce terrain là le Lisp est clairement perdant. Mais bon, la REPL permet de compenser ce temps de démarrage.

J'ai utiliser gcc tout seul sans optimisations. Je test avec O3 dès que j'ai un peu plus de temps.

Oui, un bench ne donne qu'une petite idée du langage. Celui la ne dit rien sur l'occupation en mémoire du programme ou la vitesse avec laquelle on peut développer une application plus complexe.
Par contre je serais curieux de voir ce que donne OCaml sur ce genre d'algo (chouette je sens que je vais apprendre des choses :) .

Avec les variables locales, je passe de 7.099 à 5.891 et avec le luajit 1.716 sans les variables locales et 1.337 avec.
On obtient des résultats vraiment intéréssants.

Avant que les puristes me tombent dessus, c'est dans un forum que la discution s'est déroulée.

Je confirme, elle est parfaite sur des P3/1GHz/256Mo de ram après avoir fait un petit 'chattr +i' sur les fichiers importants (on est root par défaut) et avoir rajouté un DontZap dans le xorg.conf. Sur ce genre de machine, la xubuntu est un peu lourde (xfce) surtout du point de vue de la ram.

Oh ! merci pour cette découverte. Je sens que cette distrib va être parfaite pour les vieux ordis des écoles de mon village.

Ah, bon ?

Oui, j'ai regardé : il me semble qu'il utilise aussi un pdf converti avec convert puis ffmpeg. Donc on perd quand même les transitions.

Ok, merci pour ton retour d'info. J'ai lu sur les forums que certains faisaient une capture de leur écran pendant qu'ils visionnaient le diaporamma. Ce qui permet de garder les transitions que l'on perd dans la conversion en image par image. Pour automatiser tout ça il y a peut-être quelque chose à faire avec un Xnest + recordmydesktop. Je vais commencer par voir si la conversion image par image suffit.

Euh, je ne vois pas trop comment l'appliquer dans mon cas. Je n'ai pas détailler mais je n'ai pas prévu de mettre un navigateur web sur les bornes où je dois diffuser les présentations. Il y aura juste un lecteur vidéo en plein écran et il n'y aura pas que des présentations diffusées. Mais c'est peut-être une idée à creuser, merci.

Tu devrais regarder du côté des UUID qui permettent de s'affranchir de problèmes de nomage des partitions. http://doc.ubuntu-fr.org/uuid_et_label

En gros :

Faire une installation normale. Puis :

1) récuperer les uuid :
ls -l /dev/disk/by-uuid/

2) Mettre à jour le grub :
title Mon système
uuid 4a92bd1f-1db9-4d88-b4a4-1131d74e0c9a
kernel /boot/vmlinuz root=UUID=4a92bd1f-1db9-4d88-b4a4-1131d74e0c9a ro
initrd /boot/initrd.img

3) Mettre à jour le fstab :
UUID=4a92bd1f-1db9-4d88-b4a4-1131d74e0c9a / ext3 errors=remount-ro 0 1
UUID=3c6b87bf-9387-495a-82b3-19b719eff390 /home ext3 defaults 0 2
UUID=5998b20a-af9b-499b-a049-fbdcb45a7fcc none swap sw 0 0

Je viens de le retester et j'ai retrouvé le bon vieux stunt à la sauce OpenGL. Je sens que je vais encore perdre du temps :)
L'avertissement suivant m'a fait gagner pas mal de fps :
"Another effective way of improving the speed of Ultimate Stunts is disabling parts of the reflection rendering in ultimatestunts.conf."

Idem pour moi, je l'ai beaucoup apprécié. Il existe une version en GPL :
http://www.ultimatestunts.nl/index.php?page=0&lang=en
Mais je ne l'ai pas testée récemment.

Ah, cool, un jeu où il faut chercher l'intrus :)

Ils commencent à rajouter des fonctionnalités ? ------> [ ]

> A titre de comparaison pas forcement pertinent, nous avons un système Ubuntu 9.04 avec
> un kernel plus vieux (2.28 vs 2.30), un java différent, et X.org différent, et des drivers
> nvidia différents, mais utilisant gcc 4.3.3 comme gentoo.
>
C'est fait sur la même machine au moins ? :)

Je rajoute que c'est le Conseil Général qui fournit ces machines, pas le ministère de l'Education Nationale.

> Je trouve l'Education Nationale française bien en retard, quand je lis cela.

Ça se fait aussi en France (dans l'Oise en tout cas). Ce ne sont pas des OLPC mais des dual core qui ont été distribués aux élèves de 5ème et 4ème ainsi qu'aux professeurs l'an dernier. Ce n'est pas Linux qui a été utilisé mais Windows Vista avec un grand nombre de logiciels libres. Par exemple, il n'y a pas la suite MS Office mais c'est OpenOffice qui est privilégié.
Plus d'infos ici : http://www.oise.fr/Ordi_60.1589.0.html

Non, j'avais en tête le parc de machines de mon lycée. J'envisageais le cas où un petit rigolo pourrais faire des bêtises.
Pis chez moi, aucun risque, j'ai mis des grenades un peu partout dans mes tours. :)

Oui, mais il faut quand même pouvoir ouvrir la tour. Mais c'est vrai que le chiffrement de disque règle le problème.