Articles précédents : Articles
- [9] Rétrospective LinuxFr.org de l'année 2009
- [86] Sauvons MySQL !
- [13] Statistiques 2009 du site LinuxFr.org
- [1] Un courrier de sensibilisation des acteurs locaux par jour dans les Alpes du sud en 2010
- [29] MariaDB et Drizzle : Pour repartir sur de bonnes bases !
- [25] Pour Noël - Avez vous pensé à offrir des cadeaux autorisant la libre diffusion ?
- [16] Hardware Detection Tool (HDT), un module particulier de Syslinux
- [35] Le SFLC contraint de passer à l'étape ultime pour faire respecter la GPL
- [3] Meilleurs contributeurs LinuxFr : Les gagnants de novembre 2009
- [0] Un Agenda du libre pour le Québec
Liens connexes
- Site dédié à ce record (3431 clics)
- Quelques décimales de Pi (993 clics)
- Communiqué de presse du record (595 clics)
- Article Slashdot à l'origine de la dépêche (675 clics)
- Fichier pdf détaillé (pour matheux) (986 clics)
Dépêche modérée par
Dépêche éditée par
Articles : Fabrice Bellard bat le record des décimales de Pi
Posté par Bilbo (). Modéré le 05 janvier 2010.La performance vient surtout du matériel utilisé : Fabrice a utilisé un ordinateur de bureau tournant sous Fedora 10, alors que le précédent record, ayant calculé environ 2 577 milliards de décimales, avait utilisé un supercalculateur japonais (113 téraflops en pointe soit la quarante-deuxième position au dernier Top500).
Site dédié à ce record (3431 clics)
Quelques décimales de Pi (993 clics)
Communiqué de presse du record (595 clics)
Article Slashdot à l'origine de la dépêche (675 clics)
Fichier pdf détaillé (pour matheux) (986 clics)
> Lire la suite (172 commentaires, moyenne: 4). [dépêche : 1381 caractères]
La matériel utilisé est un simple ordinateur de bureau, avec un processeur Intel Core i7 à 2,93 GHz, 6 Gio de mémoire vive et un RAID 0 de 5 disques de 1,5 To, utilisant ext4 pour gérer les gros fichiers générés. Le calcul des 2 700 milliards de décimales a duré 103 jours, les phases de vérification et de conversion en base 10 ont pris 28 jours supplémentaires.
Le précédent record a été calculé en 29 heures sur une grille de 640 nœuds, contenant chacun 4 Opteron. Selon la FAQ la machine du précédent record était 2 000 fois plus puissante mais le temps de calcul du nouveau record a été 96 fois plus long... ce qui fait que le calcul de Fabrice a été environ 20 fois plus efficace que celui du super-calculateur.
Ceci est expliqué car le calcul de Pi est très consommateur d'entrées/sorties.
Et après ?
Il faut bien evidement saluer l'exploit mais une question subsiste pour un néophyte tel que moi : à quoi cela sert ?
L'exploit tient-il à la performance du matériel couplé à une bonne implémentation ?
Ou bien ce mode de calcul va t'il ouvrir de nouvelles portes (aux fenêtres) ?
Merci d'éclairer ma lanterne.
-
[^]Re: Et après ?
Posté par David Tschumperlé (page perso, ) le 05/01/2010 à 15:17. (lien). Évalué à 10.A tracer des cercles de manière précise ? :p
-
[^]Re: Et après ?
Posté par Nonolapero (page perso, ) le 05/01/2010 à 15:35. (lien). Évalué à 7.Plutôt à en calculer le périmètre ou l'aire précisément.
Pour tracer un cercle mieux vaut un bon compas que 2700 milliards de décimales à π (pratique le bépo pour les lettres grecques).-
[^]Re: Et après ?
Posté par tcourbon (page perso, ) le 05/01/2010 à 15:38. (lien). Évalué à 10.J'ajoute que d'après wikipedia, les 39 première décimale de Pi suffisent à évaluer avec une précision inférieur au diamètre d'un atome d'Hydrogène le périmètre d'un cercle de la taille de l'univers connu et observable.
Donc c'est essentiellement la performance qui est intéressante.
(à quoi ça sert de courir le 100 en moins de 10 secondes ?)-
[^]Re: Et après ?
Posté par Jokernathan () le 05/01/2010 à 15:51. (lien). Évalué à 10.> (à quoi ça sert de courir le 100 en moins de 10 secondes ?)
Échapper aux flics ? ^^
-
[^]Re: Et après ?
Posté par Grunt () le 05/01/2010 à 15:52. (lien). Évalué à 10.(à quoi ça sert de courir le 100 en moins de 10 secondes ?)
À faire le tour d'un cercle de 31,831 mètres de diamètre le plus rapidement possible.-
[^]Re: Et après ?
Posté par KiKouN (Jabber id, ) le 05/01/2010 à 16:14. (lien). Évalué à 10.Pourrai-tu être plus précis sure le diamètre du cercle, s'il te plait.
--
KiKouN, Bucheron-Geek
Aidez des enfants à organiser un jeu de type famille en or.
A la question Citez quelque chose qui se plante., priez de ne pas répondre Windows. Merci.
-
-
[^]Re: Et après ?
-
[^]Re: Et après ?
Posté par Laurent Cligny (page perso, ) le 05/01/2010 à 17:02. (lien). Évalué à 8.Certes mais du coup avoir un très grand nombre connu de décimales de Pi permettrait d'évaluer le périmètre d'un cercle de la taille de l'univers connu et observable avec une précision inférieure au diamètre d'un quark ou même inférieure au diamètre d'un bozon de Higgs.
Bon il ne reste plus à Fabrice Bellard de s'attaquer à la découverte de ce f[a|u]meux Boson. Du coup il sait à quoi utiliser son PC maintenant. C'est quel genre d'interface de connexion pour PC qu'il y a de dispo sur le LHC ?-
[^]Re: Et après ?
Posté par Pierre Jarillon (page perso, ) le 05/01/2010 à 20:38. (lien). Évalué à 2.Un autre chiffre pour montrer l'énormité du nombre de décimales : 1 suivi de 80 zéros ça vous dit quelque chose ? C'est le nombre estimé d'atomes dans l'univers !
Je pense que ce très rapide calcul est très suffisant pour nos besoins courants :
/* 2400 premières décimales de Pi */
#include <stdio.h>
long a=10000,b,c=8400,d,e,f[8401],g;
main()
{
for(;b-c;)f[b++]=a/5;
for(;d=0,g=c*2;c-=14,printf("%.4d",e+d/a),e=d%a)
for(b=c;d+=f[b]*a,f[b]=d%--g,d/=g--,--b;d*=b);
}
Pour compiler : cc -o pi pi.c
Pour voir le résultat : ./pi-
[^]Re: Et après ?
Posté par fabien () le 05/01/2010 à 20:58. (lien). Évalué à 4.1 suivi de 80 zéros ça vous dit quelque chose ? C'est le nombre estimé d'atomes dans l'univers !
Loin de moi l'idée de remetre en cause une affirmation, mais (et c'est une vraie question hein) comment ce nombre à t'il été estimé ?
rien qu'en pensant au nombre de galaxies, et au nombre de systemes solaire dans une galaxie... au nombre de planetes... c'est enorme....-
[^]Re: Et après ?
Posté par Zenitram (page perso, ) le 05/01/2010 à 21:25. (lien). Évalué à 3.rien qu'en pensant au nombre de galaxies, et au nombre de systemes solaire dans une galaxie... au nombre de planetes... c'est enorme....
10 puissance 80 c'est énorme aussi... égalité sur la taille.-
[^]Re: Et après ?
Posté par fabien () le 05/01/2010 à 21:47. (lien). Évalué à 3.il peut y avoir un infini entre deux infinis...
-
[^]Re: Et après ?
Posté par Pierre Jarillon (page perso, ) le 05/01/2010 à 22:24. (lien). Évalué à 2.Ça veut dire quoi ? Est-ce de la poésie ? Voir les quatre sens des mots : http://pjarillon.free.fr/redac/4-sens.html
-
[^]Re: Et après ?
Posté par fabien () le 05/01/2010 à 23:05. (lien). Évalué à 2.ben ca veux dire que l'on parle de deux mesures : le nombre d'astre de l'univers et du nombre 10^^80.
Les deux sont enorme, certes mais ca n'empecherait pas que l'une soit bien bien plus grande que l'autre (par exemple 10^^30 plus grande pourquoi pas)... donc que dire "c'est énorme aussi." ne suffit pas, et n'implique pas "d'égalité sur la taille" (je repondais au poste de Zenitram).
ensuite, on peut prendre ma phrase comme une poésie, c'est pas faux, (et peut être pas involontaire), mais il n'en reste pas moins que l'infini n'étant pas "fini" on ne peux pas parler d'égalité. lim e(x) [quand x tends vers l'infini] n'est pas egal à lim sqrt(x) [quand x tends vers l'infini] pourtant on vois bien que la premiere sera vachement plus grande...
alors oui, j'ai utilisé le concept d'infini pour exprimer des grandeurs imenses (mais pas infini) n'est pas exact, mais c'est pour illustrer mon propos. les puristes ne m'en voudrons pas trop j'espere.
sinon, je ne sais toujours pas d'ou sort cette estimation du nombre d'atome? Alors qu'on ne connais qu'un faible pourcentage de notre propre planete...-
[^]Re: Et après ?
Posté par baud123 (Jabber id, page perso, ) le 05/01/2010 à 23:49. (lien). Évalué à 6.sinon, je ne sais toujours pas d'ou sort cette estimation du nombre d'atome? Alors qu'on ne connais qu'un faible pourcentage de notre propre planete...
de la valeur de c (aka vitesse de la lumière à 299792458 m/s)
de l'âge estimé de l'univers depuis le big bang
=> ça donne la taille de notre "bulle" d'univers
de la taille d'un atome
sans doute modéré par une densité (ya un peu de vide)
avec de grosses approximations et une formule triviale
=> le calcul du résultat est laissé à titre d'exercice
PS : pour la matière noire, trous noirs et autres trous de vers voire cordes qui traînent dans le coin (pan !) je ne suis plus là hein, je laisse parler les sachant :p-
[^]Re: Et après ?
Posté par tiot (Jabber id, page perso, ) le 05/01/2010 à 23:59. (lien). Évalué à 7.Pour un peu plus de précisions il y a un article sur wikipedia : http://fr.wikipedia.org/wiki/Masse_de_l%27Univers
-
-
[^]Re: Et après ?
Posté par koxinga () le 06/01/2010 à 07:01. (lien). Évalué à 0.'lim e(x) [quand x tends vers l'infini] n'est pas egal à lim sqrt(x) [quand x tends vers l'infini]'
Et quelle est la différence selon toi ?-
[^]Re: Et après ?
Posté par Xavier Claude () le 06/01/2010 à 07:55. (lien). Évalué à 3.C'est pas : lim sqrt(x) [quand x tends vers l'infini]- lim e(x) [quand x tends vers l'infini] ?
--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)-
[^]Re: Et après ?
Posté par Grunt () le 06/01/2010 à 11:27. (lien). Évalué à 4.Ça n'existe pas, ça. Tu n'as pas le droit de soustraire deux limites infinies, on n'est pas chez mémé !
Tu confonds avec:
lim (e(x) - sqrt(x)) [quand x tend vers l'infini],
qui existe bel et bien et vaut +∞-
[^]Re: Et après ?
Posté par fabien () le 06/01/2010 à 18:09. (lien). Évalué à 1.d'où ce que je disait : "il peut y avoir un infini entre deux infinis".
-
[^]Re: Et après ?
Posté par Jean-Philippe Garcia Ballester (Jabber id, page perso, ) le 06/01/2010 à 19:48. (lien). Évalué à 2.Non, les deux limites sont bien égales, c'est juste que l'opération de soustraction n'est pas définie. Voir {http://fr.wikipedia.org/wiki/Droite_réelle_achevée}
-
-
-
-
-
-
[^]Re: Et après ?
Posté par campagnard () le 06/01/2010 à 14:40. (lien). Évalué à 4.Ca me fait penser à un truc que j'avais lu dans un bouquin sur l'infini gagné a un concours de maths au collège (oui c'est vieux) :
Il y a une infinité de nombre entiers naturels. Et pourtant, entre chacun d'entre eux, il y a une infinité de nombres réels. Cela ne veut pas dire pour autant que l'ensemble des entier naturels est plus petit que l'ensemble des nombres reels. Les deux sont infinis, meme si l'un contient l'autre plus un nombre infini de fois un nombre infini d'autres nombres.-
[^]Re: Et après ?
Posté par ʇpooɹquooɥɔs sɐȷoɔᴉu (Jabber id, ) le 06/01/2010 à 14:46. (lien). Évalué à 4.En fait, justement, on peut prouver que l'ensemble des entiers naturels est plus petit que l'ensemble des réels Argument_de_la_diagonale_de_Cantor
--
Tous les nombres premiers sont impairs, sauf un.
Tous les nombres premiers sont impairs, sauf deux.
-
[^]Re: Et après ?
Posté par koxinga () le 06/01/2010 à 17:56. (lien). Évalué à 1.Il existe plusieurs types d'infini différent, la question étant de savoir si deux ensembles infinis peuvent être mis en bijection l'un avec l'autre. Dans cette idée, l'ensemble des nombres réels est 'plus grand' que l'ensemble des nombres entiers.
Par contre, ton raisonnement tient plus facilement si tu considères les rationnels, il y en a bien une infinité entre chaque nombre entier, mais on peut le mettre en bijection avec l'ensemble des nombres entiers.
-
-
-
-
-
[^]Re: Et après ?
Posté par Mikis () le 06/01/2010 à 12:16. (lien). Évalué à 10.1 suivi de 80 zéros ça vous dit quelque chose ? C'est le nombre estimé d'atomes dans l'univers !
Loin de moi l'idée de remetre en cause une affirmation, mais (et c'est une vraie question hein) comment ce nombre à t'il été estimé ?
Chuck Norris les a compté.
2 fois. Puis il a fait une moyenne.-
[^]Re: Et après ?
-
-
-
[^]Re: Et après ?
Posté par Gui13 () le 05/01/2010 à 22:43. (lien). Évalué à 2.Code un peu tordu: ni b ni e ni g ne sont initialisés: ca va partir dans les champs!
-
[^]Re: Et après ?
Posté par miod () le 06/01/2010 à 09:23. (lien). Évalué à 3.Ce sont des variables globales, elles sont donc initialisées à zéro.
-
[^]Re: Et après ?
Posté par THEpini (page perso, ) le 06/01/2010 à 10:35. (lien). Évalué à 5.Hmm, ça c'est un sacré effet de bord de la façon dont les programmes sont chargés en mémoire aujourd'hui sous linux (et ne parlons pas de ce qu'en disent les standards).
Personne n'est choqué par ce genre de pratique douteuse ?-
[^]Re: Et après ?
Posté par Arcaik () le 06/01/2010 à 11:40. (lien). Évalué à 4.\0_
Les variable global et la façon de coder général est(sont)… HORRIBLE !-
[^]Re: Et après ?
Posté par Landry MINOZA (page perso, ) le 06/01/2010 à 13:01. (lien). Évalué à 6.Un peu comme ton français quoi.
-
-
[^]Re: Et après ?
Posté par cykl () le 06/01/2010 à 13:16. (lien). Évalué à 5.Ca fait bien 6 ans que j'ai pas écrit une ligne de C mais si je me souviens bien de la spec C99 un objet qui possède une "static storage duration" est initialisé à 0/NULL.. Ici on a des objets qui sont en "external linkage". Donc si j'ai pas tout oublié je vois pas en quoi c'est douteux.
Ce sont les objets en "automatic storage duration" qui ne sont pas initialisés.
-
[^]Re: Et après ?
Posté par lasher () le 06/01/2010 à 14:51. (lien). Évalué à 5.Hmm, ça c'est un sacré effet de bord de la façon dont les programmes sont chargés en mémoire aujourd'hui sous linux (et ne parlons pas de ce qu'en disent les standards).
Non. La norme du C dit explicitement que les variables statiques et globales sont initialisées à 0. Rien à voir avec UNIX ou Linux.-
[^]Re: Et après ?
Posté par Thomas Douillard () le 06/01/2010 à 15:00. (lien). Évalué à 6.Se servir de ça juste pour économiser des lignes de code ça reste quand même bien crade, et ce n'est qu'un des truc qui rend le code cité ici pas forcément trivial à comprendre.
C'est une philosophie une certaine recherche d'une esthétique moche ...-
[^]Re: Et après ?
-
-
-
[^]Re: Et après ?
Posté par miod () le 07/01/2010 à 11:01. (lien). Évalué à 4.Un effet de bord ? Pas vraiment.
Suppose que les pages mémoire de ton processus ne soient pas initialisées avec des octets à zéro. Le noyau ne peut pas te donner une page mémoire ayant été auparavant utilisée par un autre processus ou par le noyau lui-même, cela n'est pas acceptable en termes de sécurité et puis ça te ferait certainement plaisir, sur un système multi-utilisateur, que quelqu'un lance un programme avec un gros tableau global non initialisé, et y trouve un mot de passe que tu as entré l'instant d'avant, ou ton numéro de carte bleue entré dans ton navigateur, ou toute autre information sensible).
Il est donc nécessaire que le noyau contrôle le contenu des pages mémoire de chaque processus, même celles qui contiennent des données non initialisées.
Alors, bien sûr, le noyau pourrait les remplir avec des valeurs pseudo-aléatoires, ou une valeur systématique mais différente de 0 (par exemple, 42).
Mais comme entretemps l'initialisation à zéro est passée dans la norme du C, et que beaucoup de programmes existants se mettraient à mal se comporter si cela venait à changer... il n'est plus possible de revenir sur ce choix.
-
-
[^]Re: Et après ?
Posté par Mounir (page perso, ) le 06/01/2010 à 10:47. (lien). Évalué à 3.http://en.wikibooks.org/wiki/C_Programming/Variables :
Variables declared static are initialized to zero (or for pointers, NULL) by default.
Rah, il a raison. C'est une honte ! :)-
[^]Re: Et après ?
Posté par THE_ALF_ () le 06/01/2010 à 12:32. (lien). Évalué à 7.N'empêche, ça coûte quoi de toujours initialiser ses variables à zéro ? C'est quand même plus propre, plus lisible, et on est sûr qu'il n'y a pas de problèmes à ce niveau...
--
L'univers de propensions qui est le notre est intrinsèquement créatif (K. Popper).-
[^]Re: Et après ?
Posté par Nicolas Boulay () le 06/01/2010 à 14:37. (lien). Évalué à 2.Dans le noyau linux, ils ne le font plus car cela fait beaucoup de code au final.
--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
-
-
-
[^]Re: Et après ?
-
-
-
-
[^]Re: Et après ?
Posté par ploum (page perso, ) le 05/01/2010 à 17:09. (lien). Évalué à 3.tu fais comment les lettres grecques en bépo ? Je pensais que c'était pas possible sous X :
https://bugs.freedesktop.org/show_bug.cgi?id=21475-
[^]Re: Et après ?
Posté par Nonolapero (page perso, ) le 05/01/2010 à 17:36. (lien). Évalué à 1.C'est parce qu'au boulot je suis sous Windows.
Ya un fil sur le forum bépo > http://forum.bepo.fr/viewtopic.php?id=124
-
-
-
[^]Re: Et après ?
Posté par Selso (page perso, ) le 06/01/2010 à 00:03. (lien). Évalué à 0.Les cercles que tu dessines au compas contiennent le nombre "pi" ! y'a pas plus exacte :)
-
[^]Re: Et après ?
Posté par Xavier Claude () le 06/01/2010 à 08:08. (lien). Évalué à 6.Sauf que ton compas a une légère variation due à la flexibilité de la tige et de la fixation. Je pense que 2700 milliards de décimale c'est quand même plus précis.
--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)
-
[^]Re: Et après ?
Posté par François B. () le 06/01/2010 à 10:29. (lien). Évalué à 7.Pourquoi s'embêter avec un compas alors qu'on peut calculer pi avec des hotdogs congelés ?
http://www.wikihow.com/Calculate-Pi-by-Throwing-Frozen-Hot-D(...)-
[^]Re: Et après ?
Posté par Rémi Hérilier (page perso, ) le 06/01/2010 à 12:04. (lien). Évalué à 1.J'prèfère quand même la version de Buffon avec des aiguilles, y'a moins à laver vu la quantité de saucisses à lancer pour avoir une bonne approximation :-p
-
-
-
-
[^]Re: Et après ?
Posté par Bilbo () le 05/01/2010 à 15:36. (lien). Évalué à 10.La FAQ du record explique que le but de Fabrice n'est pas tant les décimales de Pi (dont il n'a en fait pas grand chose à faire), mais plutôt les algorithmes de l'arithmétique multiprécision.
Pour juste traduire la FAQ :
L'arithmétique multiprécision des grands nombres a peu d'utilisation pratique, mais quelques algorithmes concernés sont intéressants pour faire d'autres choses. En particulier :
* La transformée de Fourier discrète. Cette transformée est très utilisée dans beaucoup d'algorithmes et la plupart des équipements électroniques modernes (comme les télévisions numériques, les téléphones mobiles ou les lecteurs de musique) en contiennent au moins une implémentation.
* La gestion fiable d'un grand espace disque, au moins sur un ordinateur. Des méthodes spécifiques ont été développées pour assurer la haute fiabilité et la grande bande passante d'entrées/sorties disque. Les mêmes idées peuvent être appliquées à d'autres domaines comme le streaming video ou les accès aux bases de données.
* Le calcul en lui-même est un test poussé d'un ordinateur, ainsi que de son processeur, sa mémoire, son stockage disque et son système de refroidissement. Une erreur d'un seul bit pendant le calcul donne un mauvais résultat. Un mauvais refroidissement donne une erreur matérielle.
-
[^]Re: Et après ?
Posté par Gregory Auzanneau (page perso, ) le 05/01/2010 à 17:01. (lien). Évalué à 2.Une question me taraude, pourquoi avoir décidé de s'arreter à 2700 M ?
J'ai pu lire dans le Press Release qu'il lui restait 6,4To de disponible (7,5T - 1,1T) (pfiou, quand je pense que j'ai qu'un disque de 64Go sur ma machine...)
Pourquoi ne pas avoir attendu quelques jours de plus et faire un chiffre rond comme 3000 M ? (Choix personnel, Autre ?)
Vu que c'est très gourmand en entrée/sortie, pourquoi avoir choisi de simples disques SATA assez lent ? Même en RAID0, le tps d'accès est lent sur ces disques (Peut-être que ça ne lit jamais, que ça ne fait qu'écrire)
En tout cas, félicitation pour ce record !-
[^]Re: Et après ?
Posté par Laurent Cligny (page perso, ) le 05/01/2010 à 17:06. (lien). Évalué à 2.Pourquoi ne pas avoir attendu quelques jours de plus et faire un chiffre rond comme 3000 M ?
Peut-être parce qu'on apprend ces temps-ci que polluer et gaspiller l'énergie c'est mal ?-
[^]Re: Et après ?
Posté par tankey () le 06/01/2010 à 10:41. (lien). Évalué à 5.:-)
M'enfin le gaspille d'énergie par les citoyens, ok, c'est vrai. Mais bon, moi quant je pense que les climatisations sont toujours posées en tant qu'éléments autonomes sur les batiments des entreprises, ça me fait rire "le citoyen coupable" ... Et pourtant forcer l'installation de nouvelles climatisations d'une part, et le renouvellement du parc d'autre part, par les mêmes éléments, mais alimentés avec un panneau solaire... Cela ne remet pas en cause le principe de "l'unité moins chère" et cela participerait bien plus largement à la réduction de la consommation. Car imaginons que seulement 12~18% de l'éléctricité consommée par les climatisations soit issue de leur propre panneau solaire individuel. Ramenons le coût énergétique de production des unités... on obtiens peut être seulement moins de 10% de consommation électrique non répercurtée sur le réseau général... 10% c'est rien ? pas sûr...
Surtout qu'au moment où on a besoin de clim', c'est le moment où le soleil tape... donc 12~15% est vraiment une estimation basse en plus d'être au pif... les panneaux d'aujourdhui savent faire pas (trop) mal avec peu de surface... Mais même 10% d'économies... (et sans parler de l'impact positif d'un tel plan sur l'économie)
ça semble tellement évident... peut être trop ? A moins, que comme de nombreux autres, le parti écolo préfère la taxe carbonne où seuls les citoyens payent, et pas les entreprises ...
???-
[^]Re: Et après ?
Posté par Nicolas Boulay () le 06/01/2010 à 12:07. (lien). Évalué à 3.Une clim c'est ~3-5kw, 3-4k€. 1m² de panneau, c'est ~100W. Une installation de 3kw coute ~25k€.
On peut donc calculer que la clim de 3k€ aurait besoin de 25k€ de panneaux solaires, difficile à faire passer la pilule.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Et après ?
Posté par Fanboy Scout () le 06/01/2010 à 13:53. (lien). Évalué à 0.Une clim c'est ~3-5kw
De puissance oui, pas de consommation...( 3 à 4x moins généralement )-
[+] [^]Re: Et après ?
Posté par Xavier Claude () le 06/01/2010 à 14:04. (lien). Évalué à -1.Comment tu fais pour produire moins que ce que tu consommes?
--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)-
[^]Re: Et après ?
Posté par Xavier Claude () le 06/01/2010 à 14:06. (lien). Évalué à 2.Je voulais dire l'inverse: comment tu fais pour produire plus que ce que tu consommes? Et depuis quand la puissance n'est pas consommée?
--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)-
[^]Re: Et après ?
Posté par Fanboy Scout () le 06/01/2010 à 14:13. (lien). Évalué à 6.Parce que la majorité de l'énergie ne vient pas de l'électricité mais de l'air dans le cas d'une climatisation ( air/air ), c'est le principe de la pompe à chaleur.
-
[^]Re: Et après ?
Posté par Nicolas Boulay () le 06/01/2010 à 14:33. (lien). Évalué à 2.N'importe quoi, ne confond pas les conneries marketing avec la réalité.
En gros, en chauffage, une pompe à chaleur produit la même chaleur avec 4 fois moins d'énergie qu'avec une résistance (la chaleur est transporté de l'extérieur en plus). C'est tout. Il n'y a aucune "puissance" de plus, simplement une plus grande efficacité.
Et cela n'est pas le cas en mode froid.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Et après ?
Posté par khivapia () le 06/01/2010 à 14:56. (lien). Évalué à 4.Euh je ne comprends pas la différence. Dans le cas d'un chauffage, par exemple, avec 1kW (ordre de grandeur pour fixer les idées) électrique on peut faire passer 3 kW de chaleur de l'extérieur vers l'intérieur. Pourquoi avec une clim on ne pourrait pas, avec toujours 1kW électrique, faire passer 3kW de chaleur de l'intérieur vers l'extérieur ??
Évacuer la chaleur est la puissance utile de la clim et c'est certainement celle qui est mise en avant par les constructeurs.
-
-
-
[^]Re: Et après ?
Posté par nayco (page perso, ) le 06/01/2010 à 16:17. (lien). Évalué à 3.Parce qu'une climatisation ne produit pas de chaleur (ou de froid), elle la déplace.
Donc l'énergie consommée par une clim est essentiellement dédiée à compenser des pertes mécaniques :) !-
[^]Re: Et après ?
Posté par Xavier Claude () le 06/01/2010 à 16:29. (lien). Évalué à 3.Parce qu'une climatisation ne produit pas de chaleur (ou de froid), elle la déplace.
Elle «produit» quand même de la chaleur, sinon elle pourrait pas réduire la température intérieur plus basse que celle extérieur, comme un frigo.--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)-
[^]Re: Et après ?
Posté par nayco (page perso, ) le 06/01/2010 à 23:04. (lien). Évalué à 2.Tu m'as forcé à réfléchir, rhaaa, pas bien. Mais ça me permet de clarifier : L'idée est de comprendre pourquoi elle consomme moins d'énergie électricique que ce qu'elle déplace comme énergie calorifique.
L'énergie électrique consommée par une climatisation est en gros égale à celle utilisée pour comprimer le fluide calo-porteur (ce qui le réchauffe, cette énergie calorifique lui est ensuite "volée" par le dissipateur à l'extérieur) d'une part, et celle perdue lorsque le compresseur "pousse" le liquide à travers tout le circuit, notamment dans le fin capillaire. Cette dernière étape "produit" d'ailleurs du froid car elle force le gaz à se détendre.
Or, produire du froid, c'est arracher de la chaleur au milieu environnant... La pièce à refroidir, par exemple.
-
-
-
-
-
-
[^]Re: Et après ?
Posté par Thomas Douillard () le 06/01/2010 à 14:13. (lien). Évalué à 2.Le calcul il est à faire par rapport à la quantité d'argent qui aurait été consommée en achat d'électricité pour faire tourner la même clim, plutôt, pour savoir si ça vaut le coût de payer un emprunt pour financer l'installation des panneaux, par exemple.
-
[^]Re: Et après ?
Posté par Nicolas Boulay () le 06/01/2010 à 14:36. (lien). Évalué à 2.25k€/installation / 0.1€/kw = 250 000.
En gros, il te faut 11 ans pour rentabiliser tes panneaux solaires à 0.1€/Kw chez EDF.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."-
[^]Re: Et après ?
Posté par Thomas Douillard () le 06/01/2010 à 14:40. (lien). Évalué à 2.En supposant que le coût du kw/h reste constant, ce qui est pas si sûr, il risque d'y avoir une variation du coût de l'énergie dans un avenir plus ou moins proche, négociations sur le climat, prix du pétrole toussa ...
Ça peut être un paris gagnant, et somme toute en fonction de la durée de vie du bâtiment ça peut être un paris gagnant.-
[^]Re: Et après ?
Posté par Nicolas Boulay () le 06/01/2010 à 23:34. (lien). Évalué à 2.De l'autre coté, il faut ajouter le coût de l'assurance (vol/casse) et l'entretien des panneaux.
Même si l'électricité augmente, cela ne sera pas rentable avant 10 ans.--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
-
-
-
-
-
[^]Re: Et après ?
-
[^]Re: Et après ?
Posté par nomorepost () le 05/01/2010 à 17:13. (lien). Évalué à 3.L'intérêt était sans doute de démontrer que l'algorithme utilisé était plus efficient en ressource et en temps, pas de battre le record de décimales, ce qui n'apporte rien.
-
[^]Re: Et après ?
Posté par khivapia () le 05/01/2010 à 17:47. (lien). Évalué à 10.Disons que pour démontrer que l'implémentation réalisée était plus efficace, il fallait qu'il batte le record, ensuite peu importe de combien. C'est souvent la façon de procéder en recherche.
De toutes façons il n'aurait pas servi à grand-chose qu'il le batte de beaucoup plus : les chercheurs détenant le précédent record pourront de toutes façons largement le dépasser en faisant simplement tourner leur calculateur deux jours de plus. Ce qui est intéressant est de battre le record petit à petit (à moins d'une grosse découverte qui rende tout le calcul extrèmement rapide de toutes façons), afin de pouvoir comparer plus facilement les diverses données (temps, mémoire, IO) des implémentations.
-
-
[^]Re: Et après ?
-
[^]Re: Et après ?
Posté par zero heure (Jabber id, page perso, ) le 06/01/2010 à 15:37. (lien). Évalué à 1.Vu que c'est très gourmand en entrée/sortie, pourquoi avoir choisi de simples disques SATA assez lent ? Même en RAID0, le tps d'accès est lent sur ces disques
tu peux expliquer ? je n'ai pas compris...
tu veux dire lent par rapport à quoi ?--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm-
[^]Re: Et après ?
Posté par Nicolas Boulay () le 06/01/2010 à 23:37. (lien). Évalué à 3.Par rapport à un SSD, mais j'ai du mal à imaginer le prix de 7To en SSD.
--
"Plus un État censure, moins il est démocratique. Mais parce qu’on vous ment sur internet, on va le censurer pour ceux qui télechargent."
-
-
[^]Re: Et après ?
-
-
[^]Re: Et après ?
Posté par Benjamin Henrion (page perso, ) le 05/01/2010 à 18:55. (lien). Évalué à 10."à quoi cela sert ?"
A la Quadrature Du Net de vendre plus de posters avec des décimales de PI.-
[^]Re: Et après ?
Posté par hervé Couvelard (Jabber id, page perso, ) le 06/01/2010 à 15:14. (lien). Évalué à 4.La quadrature du net ? Les 3,1415926 mecs dans un garage ?
-
-
[^]Re: Et après ?
Posté par tibboH () le 06/01/2010 à 15:06. (lien). Évalué à 2.Je me rappelle il y a longtemps d'avoir lu un article sur le sujet.
L'un des objets du calcul des décimales de PI est la recherche d'une période dans les décimales en question.
En effet, PI est un irrationnel, qui ne peut donc être expirmé en fraction. Même si c'est un fait avéré, il n'y a pas de démonstration de ce fait (vérifier mes dires), ni de son contraire.
Hors, tout nombre décimal ayant une période dans ses décimales est un rationnel. Donc rechercher toute les décimales de PI revient à chercher si, in fine, il est rationnel
Exemples:
0.219219219... = 219/999 = 73/333
123.78787878 = 123 + 78/99 = 4085/33
Mais je suis sûr que des mathophone en parleraient mieux que moi, et avec plus d'exactitude.-
[^]Re: Et après ?
Posté par ʇpooɹquooɥɔs sɐȷoɔᴉu (Jabber id, ) le 06/01/2010 à 15:23. (lien). Évalué à 4.Il y a une démonstration (que je ne connais pas) du fait que Pi est irrationnel : http://fr.wikipedia.org/wiki/Pi#De_la_nature_de_.CF.80
--
Tous les nombres premiers sont impairs, sauf un.
Tous les nombres premiers sont impairs, sauf deux.
-
[^]Re: Et après ?
Posté par Thomas DEBESSE () le 07/01/2010 à 11:33. (lien). Évalué à 7.π est un nombre rationnel…
…en base π.--
† In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.
-
-
[^]Re: Et après ?
Posté par Mikaël Cordon (Jabber id, ) le 06/01/2010 à 20:42. (lien). Évalué à 2.Ben déjà, être le seul à connaître une suite de chiffres que personne ne peut reproduire, c’est intéressant en cryptographie :)
Mais bon, 131 jours pour crypter un mail… :D-
[^]Re: Et après ?
Posté par Crazy Diver () le 07/01/2010 à 01:46. (lien). Évalué à 3.Surtout que c'est difficile de "crypter" un mail, en général on utilise la PK du destinataire pour chiffrer ...
Désolé :-)
-
[^]Re: Et après ?
-
[^]Re: Et après ?
Posté par Thomas Douillard () le 09/01/2010 à 20:54. (lien). Évalué à 2.T'es ouf, personne ne peut reproduire les suites de calcul de Pi ? Tout le monde connait les algos !
D'ailleurs il y a des gens qui battent des records en quelques jours de calculs à peine ...
-
Comme quoi ...
Comme quoi tout n'est pas efficacement parallélisable.
Sinon, il est quand même fort ce Fabrice. Chapeau.
-
[^]Re: Comme quoi ...
Bof
Je connais toutes les décimales de Pi. Dans le désordre.
Tous les nombres premiers sont impairs, sauf un.
Tous les nombres premiers sont impairs, sauf deux.
-
[^]Re: Bof
Posté par Snarky (Jabber id, page perso, ) le 05/01/2010 à 19:53. (lien). Évalué à 4.Et bien, Chuck Norris les connais par cœur, et dans l'ordre...
--
Milite pour un about:black sur les navigateurs ! ( シ Sauvons la planète ツ )-
[^]Re: Bof
Posté par Barret Michel (Jabber id, page perso, ) le 06/01/2010 à 09:16. (lien). Évalué à 7.Il les a même déjà récité 2 fois.
--
Debian Squeeze
-
Pour la seconde fois
On notera que ce même monsieur avait déjà obtenu un record de nombre de décimale de pi en 1997 (à l'époque, 1000 milliards de chiffres en base 2), mais à priori, en utilisant une formule différente.
Plus d'info à partir de là : http://fr.wikipedia.org/wiki/Fabrice_Bellard
-
[^]Re: Pour la seconde fois
Posté par nomorepost () le 05/01/2010 à 15:56. (lien). Évalué à 10.Oui, ca devient vraiment obsessionnel ce record chez lui.
Il faut craindre qu'il aille de mal en PI.
et ...
Pas seulement l'auteur de Qemu, mais également de kQemu, "module noyau d'accélération de machine virtuelle" (touss) qui avait fait grand bruit lors de sa sortie. Encore plus de bruit lors de sa libération ;) Et sur lequel repose, il me semble, les meilleures solutions de virtualisations d'aujourdhui : de type KVM, qui est dérivé de kQemu, me semble t il.
Egalement auteur d'un 'compilateur' assez fulgurant : compiler un noyau linux en moins de 8 minutes, c'est assez fulgurant. Là encore c'était la perf' absolue recherchée il me semble. Ce "méga parseur" est vraiment incroyable.
A noter que Mr Bellard, dans sa faq, précise qu'il va rendre disponible une version Linux et une version windows de ce programme. Et que "open source" n'est pas au menu dans un futur proche, pour ce programme là. Pour le temps de calcul, il m' avait semblé lire 116 jours (??). Le fichier final, ne contenant que son PI, fait plus de 1 tera... Donc bon, pour télécharger son résultat de PI ça va être difficile. PAr contre il propose une interface donnnant la décimale à l'emplacement voulue (lien en dépêche) Donc en plus... il y a le papier cadeau autour :)
-
[^]Re: et ...
Posté par patrick_g (page perso, ) le 05/01/2010 à 16:12. (lien). Évalué à 5.C'est quand même un truc un peu gênant cette histoire de code source non ?
Extrait de la FAQ ( http://bellard.org/pi/pi2700e9/faq.html ):
Will the program used to establish the Pi computation record be publically available ?
Yes, I plan to release a Linux and a Windows version (64 bit only).
Will you release the source code ?
Not in the foreseeable future.
Pourquoi ne pas publier le code source et envisager de fournir uniquement des binaires ?-
[+] [^]Re: et ...
Posté par arnaudus () le 05/01/2010 à 16:49. (lien). Évalué à -3.Sans code source, l'"exploit" n'a aucune valeur: il n'y a aucun moyen de vérifier si son algo, c'est pas simplement "prendre les décimales existantes et ajouter N chiffres aléatoires".
Plus sérieusement, sans code source, on ne peut pas savoir si l'algo implémenté est le même que l'algo publié. Puisqu'il ne s'agit que d'une sorte de benchmark, je ne vois pas comment on peut considérer ça comme sérieux.-
[^]Re: et ...
Posté par tiot (Jabber id, page perso, ) le 05/01/2010 à 17:10. (lien). Évalué à 7.Il y a un algorithme pour calculer rapidement la nième décimal binaire de π. On peut alors vérifier si les décimales ont été choisies au pif.
-
[^]Re: et ...
Posté par arnaudus () le 06/01/2010 à 09:25. (lien). Évalué à 3.Ca ne règle en rien le problème de savoir si l'algo implémenté est bien l'algo publié. Je ne sais pas comment vous bossez en info, mais dans une discipline scientifique classique, une telle «démonstration» serait totalement inacceptable.
-
[^]Re: et ...
Posté par Xavier Claude () le 06/01/2010 à 09:56. (lien). Évalué à 8.Je ne sais pas comment vous bossez en info, mais dans une discipline scientifique classique, une telle «démonstration» serait totalement inacceptable.
En info, tu déposes d'abord un brevet qui couvre la génération de n'importe quel nombre et puis tu menaces les boîtes qui générent des nombres et t'attend les royalties. Le code n'est pas vraiment important.--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)-
[^]Re: et ...
Posté par tankey () le 06/01/2010 à 10:12. (lien). Évalué à 0.Je ne sais pas comment tu bosses, ni comment "ils" bossent. Je ne sais qu'une chose :
Sortie d'un bon dé-assembleur / décompilo, seule la bonne foi compte. En effet, que tu publies le code source ne garantie pas grand chose si les gens se contentent du binaire. Le source peux très bien différé légèrement du binaire livré. C'est donc un rapport de confiance, renforcé il est vrai, ici, par le fait que si les sources sont dispos, on peux se moquer du binaire livré et ne travailler qu'avec les sources...
M'enfin bon, maintenant on voit tellement de gentoo, freebsd, et même netbsd users, qui finalement n'utillisent que des binaires précompilés... que ceux utilisant les sources réellement doivent être vraiment rares de nos jours.
zut on est que mercredi :p
-
-
[^]Re: et ...
Posté par khivapia () le 06/01/2010 à 09:59. (lien). Évalué à 5.Ici on parle vraiment d'un problème d'implémentation, l'algorithme utilisé importe finalement assez peu, ce qui compte c'est vraiment le soin apporté à l'implémentation (et la gestion du cache en particulier vu que les entrées-sorties sont primordiales).
Le fait de battre des records pour comparer des implémentations et des algorithmes est assez classique en info, notamment dans le cas des algorithmes cryptologiques (cryptographie et cryptanalyse).
En crypto en effet, pour évaluer la sécurité des algorithmes de factorisation d'entiers par exemple (pour casser des clefs RSA) il est nécessaire de savoir leur potentiel réel, pas leur potentiel "théorique" au sens "complexité" : un algorithme peut avoir une complexité largement inférieure à un autre, s'il fait beaucoup d'entrées-sorties, se distribue mal et que la formule de complexité cache des constantes monstrueuses, il n'est pas important pour la sécurité : il ne serait performant que pour des tailles de clefs largement inutilisées. Ici c'est un peu la même chose que Fabrice Bellard a cherché à comparer.
-
-
-
[^]Re: et ...
Posté par Christophe Merlet (page perso, ) le 05/01/2010 à 17:36. (lien). Évalué à 7.> Sans code source, l'"exploit" n'a aucune valeur: il n'y a aucun moyen de vérifier si son algo, c'est pas simplement "prendre les décimales existantes et ajouter N chiffres aléatoires".
S'il fournit un binaire de 25ko qui sait générer les 2000 miliards premières décimales, je ne voit pas pourquoi il faudrait douter des décimales suivantes...-
[^]Re: et ...
Posté par Xavier Claude () le 06/01/2010 à 09:18. (lien). Évalué à 3.
wget -O pi.txt http://ladressedes2000milliardspremièresdécimales
cat /dev/random>> pi.txt
--
Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. (R. Devos)-
[^]Re: et ...
Posté par b (page perso, ) le 06/01/2010 à 17:27. (lien). Évalué à 3.Un accès réseau, ca se repère facilement, meme sans les sources.
-
-
-
-
[+] [^]Re: et ...
Posté par nomorepost () le 05/01/2010 à 17:01. (lien). Évalué à -2.Bon suite à vos récriminations, j'ai fini par convaincre Fabrice et je vous livre les sources en exclusivité.
Libre à vous de confirmer le résultat par l'algorithme qui vous convient.
import random
#old result
pi='3.14159265359.......5'
l=len(pi)
def calc_pi(n):
____c=''"
____if n <= l:
________print pi[0:n]
____else:
________for i in xrange(n-l):
____________c=c+random.choice('0123456789')
____print pi+c
-
-
[^]Re: et ...
Posté par Gui13 () le 05/01/2010 à 16:13. (lien). Évalué à 3.Moins de 15 secondes, s'il vous plaît!
http://bellard.org/tcc/tccboot.html
-
[^]Re: et ...
Posté par Samuel Thibault (page perso, ) le 05/01/2010 à 20:32. (lien). Évalué à 10.Heu, non, KVM et autres ne sont pas dérivés de kQemu, ils utilisent la base de drivers de qemu seulement, qui certes est un composant essentiel de qemu, mais n'est pas sa raison première: _q_emu c'est surtout "quick" emu, avec un moteur JIT qui recompile des morceaux de codes en natif pour aller bien plus vite que bochs & co qui ne font qu'interpréter en direct. Ce que fait kQemu, c'est bidouiller avec le noyau pour se passer le plus souvent possible de recompiler le code et directement l'exécuter en natif. Ce que font kvm, Xen en virtualisation totale, virtualbox, etc., c'est utiliser la fonctionnalité vmx/svm des processeurs récents pour que ce soit le processeur lui-même qui s'occupe de la bidouille (ce qui rend la chose encore plus rapide, donc).
kQemu et KVM ont donc un principe assez similaire: remplacer la partie recompilation de code de qemu, mais les implémentations n'ont rien à voir :)-
[^]Re: et ...
-
2000/96 ~ 20
la machine du précédent record était 2 000 fois plus puissante mais le temps de calcul du nouveau record a été 96 fois plus long... ce qui fait que le calcul de Fabrice a été environ 20 fois plus efficace
[rapport Puissance]/[rapport temps] = [SU]
Tu nous mélangerais pas un peu des choux et des salades des fois ?
Je suis pas sur de ton calcul d'efficacité...
"Reality is just a point of view" P_K_DICK
---
"Gentoo" is an ancient african word, meaning "Read the F*ckin' Manual". "Gentoo" also means "I am what I am because you all are freaky n3rdz"
-
[^]Re: 2000/96 ~ 20
Posté par tcourbon (page perso, ) le 05/01/2010 à 15:36. (lien). Évalué à 5.C'est ce que déclare le monsieur détenteur de l'exploit.
Extrait :
The previous Pi computation record of about 2577 billion decimal digits was published by Daisuke Takahashi on August 17th 2009. The main computation lasted 29 hours and used 640 nodes of a T2K Open Supercomputer (Appro Xtreme-X3 Server). Each node contains 4 Opteron Quad Core CPUs at 2.3 GHz, giving a peak processing power of 94.2 Tflops (trillion floating point operations per second).
My computation used a single Core i7 Quad Core CPU at 2.93 GHz giving a peak processing power of 46.9 Gflops. So the supercomputer is about 2000 times faster than my computer. However, my computation lasted 116 days, which is 96 times slower than the supercomputer for about the same number of digits. So my computation is roughly 20 times more efficient.
meuh
La vache, c'est de pis en pis. Mon dieu que c'est lait.
-
[^]Re: meuh
Posté par Pierre Tramo (page perso, ) le 05/01/2010 à 16:38. (lien). Évalué à 10.Je te trouve sévère, moi j'estime que c'est du bel art
-
[^]Re: meuh
Posté par Benjamin G. ( Prae ) (page perso, ) le 05/01/2010 à 23:29. (lien). Évalué à 1.Tu vas pas en faire un fromage non plus !
Fabrice Bellard..
Je me souviens d'un programme de synthèse vocale dudit Fabrice, parole.com je croit, qui fonctionnait sous DOS, en 1989... !
Que de chemin parcouru !!
Par contre, ça ne sert à rien de calculer les décimales de Pi, puisque Chuck Norris les connaît toutes.. !!
-
[^]Re: Fabrice Bellard..
Posté par Wawet76 (page perso, ) le 05/01/2010 à 19:36. (lien). Évalué à 1.Le bidule qui parlait en utilisant le buzzer du PC ?
Que de souvenirs... snif, snif.
Mais tu es sûr de toi ? il n'en parle pas sur son site. http://bellard.org/-
[^]Re: Fabrice Bellard..
Posté par alzorglub () le 06/01/2010 à 12:40. (lien). Évalué à 2.j'ai vu ça, mais curieusement je suis quasi sûr de me souvenir que le programme lisait sa propre phrase de copyright, je crois entendre encore le "copyright 1989 fabrice bellard"
Faudrait lui demander
J'avais aussi oublié le fameux lzexe !
Je me sens vieux :(
-
Phôte
Le précédent record été calculé en 29 heures
:o
-
[^]Re: Phôte
Posté par patrick_g (page perso, ) le 05/01/2010 à 17:21. (lien). Évalué à 3.Il manquait le "a". C'est corrigé.
Ordinateur de bureau
J'aime beaucoup le terme "ordinateur de bureau" pour une machine ayant 6Gio de mémoire et 5 disque de 1,5To...
Mais saluons l'exploit tout de même.
-
[^]Re: Ordinateur de bureau
Posté par Guid (page perso, ) le 05/01/2010 à 16:47. (lien). Évalué à 2.6 Gio de mémoire, c'est plus vraiment extraordinaire.
De nos jours, 4Gio -sur les machines vendues actuellement- c'est plutôt courant.--
If you and dead people can read hex, how many people can read hex?-
[^]Re: Ordinateur de bureau
Posté par Bilbo () le 05/01/2010 à 17:01. (lien). Évalué à 2.Je pense aussi que le terme "ordinateur de bureau" (desktop computer) est à opposer à serveur, qui lui a :
* de la mémoire vive à correction automatique d'erreur (ECC RAM) ;
* des alimentations redondantes ;
* des disques supposés plus fiables ;
* un système de refroidissement adapté à un uptime de plusieurs dizaines de jours ;
* ...
-
-
[^]Re: Ordinateur de bureau
-
[^]Re: Ordinateur de bureau
Posté par Zenitram (page perso, ) le 05/01/2010 à 17:19. (lien). Évalué à 3.J'aime beaucoup le terme "ordinateur de bureau"
Je peux te faire rentrer tout ça dans un boitier moyen tour, la "référence" pour un ordinateur de bureau.
De plus, une machine de ce type doit coûter moins de 2000€.
Bref, rien de gigantesque.
Donc oui, c'est un ordinateur de bureau.
si tu te bases sur la performance, ton PC que tu as chez toi est une serveur hyper-sophistiqué pour les gens vivant en 1990. Est-ce que tu considères pour autant que ta machine n'est pas une ordinateur de bureau?-
[^]Re: Ordinateur de bureau
Posté par Boa Treize (page perso, ) le 05/01/2010 à 17:58. (lien). Évalué à 5.J'aurais quand même plutôt tendance à appeler ça une station de travail.
-
[^]Re: Ordinateur de bureau
Posté par campagnard () le 06/01/2010 à 15:08. (lien). Évalué à 4.Ta compétence "chipotage" vient d'augmenter de 3 niveaux d'un coup, félicitations !
-
-
[^]Re: Ordinateur de bureau
Posté par Chaddaï Fouché () le 05/01/2010 à 18:01. (lien). Évalué à 4.si tu te bases sur la performance, ton PC que tu as chez toi est une serveur hyper-sophistiqué pour les gens vivant en 1990. Est-ce que tu considères pour autant que ta machine n'est pas une ordinateur de bureau?
Non, pas un serveur ultra-sophistiqué, un super-calculateur !! Le record en 90 était de 23,2 GFlops, aujourd'hui, le plus faible des core 2 duo fait du 9.6 GFlops et les meilleurs intels (pour ordinateur de bureau) sont au-delà des 50 GFlops.
--
Jedaï-
[^]Re: Ordinateur de bureau
Posté par Antoine J. (Jabber id, ) le 05/01/2010 à 23:00. (lien). Évalué à 6.Quand on voit ce qu'on faisait avec un supercalculateur de 1990 et ce qu'on fait avec un ordinateur de bureau maintenant, c'est triste.
-
[^]Re: Ordinateur de bureau
-
-
question con ???
je vais peux être passé pour un con mais je préfère demander :
2 700 milliards de décimales c'est en binaire ou en decimal ?
d'ailleurs les chiffres après la virgule en binaire ou appelle ca aussi des decimales ou pas ?
(maintenant vous comprenez pourquoi je sens que je passe pour un con)
-
[^]Re: question con ???
-
[^]Re: question con ???
Posté par B. (Jabber id, page perso, ) le 05/01/2010 à 18:33. (lien). Évalué à 4.d'ailleurs les chiffres après la virgule en binaire ou appelle ca aussi des decimales ou pas ?
Sachant que décimal veut dire dixième (du latin decimus « dixième » , de decem « dix »), ça m'étonnerait. C'est pour la numération en base dix seulement.-
[^]Re: question con ???
Posté par Antoine Labitte () le 05/01/2010 à 18:40. (lien). Évalué à 2.bin c'est pour ca aussi que je trouve ca bizard.
"Decimale" je sais bien que ca vient de la base dix mais on les appelle comment alors ces ch'ti chiffres après la virgule en binaire?-
[^]Re: question con ???
Posté par Antoine Labitte () le 05/01/2010 à 18:51. (lien). Évalué à 4.après quelque recherche je suis tombé sur partie "fractionnaire" qui marche dans toute les bases.
puis en demandant a mes collègues de boulot y'a la "mantisse" qui marcherai aussi comme terme.
Mais je ne trouve pas d'équivalent juste pour le binaire.
Et je n'ai pas vu non plus d'interdiction ni d'utilisation du terme décimales pour les chiffres après la virgule en binaire...
Sur ce bonne soirée a tous moi, je m'rentre!-
[^]Re: question con ???
-
[^]Re: question con ???
-
-
-
-
[^]Re: question con ???
Posté par steph1978 () le 09/01/2010 à 19:21. (lien). Évalué à 2.De ce que j'ai compris, le calcul est principalement fait en binaire et converti ensuite - ou au fur et à mesure, j'ai pas l'info - en décimal.
Sur cette page, http://bellard.org/pi/pi2700e9/pidigits.html, il donne un extrait, c'est du décimal.
et la calculette?
Va falloir la Casio© modèle King Size pour mettre tout ça...
Troll is te veel
-
[^]Re: et la calculette?
Posté par Benjamin G. ( Prae ) (page perso, ) le 05/01/2010 à 23:30. (lien). Évalué à 3.Prétentieux va !
Mensonge !
Je trouve pas le fichier des résultats à télécharger !
Le petit fichier de... 2,5 To environ... Mais il a le droit de le compresser ;)
Milite pour un about:black sur les navigateurs ! ( シ Sauvons la planète ツ )
-
[^]Re: Mensonge !
-
[^]Re: Mensonge !
Posté par _kd () le 05/01/2010 à 20:53. (lien). Évalué à 10.C'est pour ça que le programme est fourni. De 2.5 To à 25 ko, ça fait un sacré ratio, mais il faut plusieurs mois pour tout décompresser.
-
[^]Re: Mensonge !
Posté par Snarky (Jabber id, page perso, ) le 05/01/2010 à 23:43. (lien). Évalué à 2.Où tu à vu que le programme était fourni ?
Vue dans le FAQ:
Will the program used to establish the Pi computation record be publically available ?
Yes, I plan to release a Linux and a Windows version (64 bit only).
Will you release the source code ?
Not in the foreseeable future.--
Milite pour un about:black sur les navigateurs ! ( シ Sauvons la planète ツ )
-
-
[^]Re: Mensonge !
Posté par Victor STINNER (Jabber id, page perso, ) le 05/01/2010 à 22:28. (lien). Évalué à 7.Le petit fichier de... 2,5 To environ... Mais il a le droit de le compresser ;)
Les décimales de pi sont plutôt aléatoires et donc difficiles à compresser.-
[^]Re: Mensonge !
Posté par Axioplase ıɥs∀ (page perso, ) le 06/01/2010 à 04:13. (lien). Évalué à 2.>> Les décimales de pi sont plutôt aléatoires et donc difficiles à compresser.
Les décimales de pi sont toutes contenues dans l'intervalle [0-9], ce qui tient sur 5 bits.
À la louche, tu peux donc couper en deux la taille du fichier.
Ensuite, l'aléatoire n'empêche pas du tout qu'il y ait des ça et là des séquences qui se compressent bien. Mais sans analyser le code à la main, à mon avis, un algo de type Huffman doit permettre d'avoir un plutôt bon résultat de compression en un temps rapide.--
Je ne suis pas toujours de mon avis.-
[^]Re: Mensonge !
Posté par B. (Jabber id, page perso, ) le 06/01/2010 à 16:53. (lien). Évalué à 3.J'imagine qu'il n'a pas utilisé un bête fichier texte pour stocker ses résultats et qu'il tient déjà compte qu'il n'y a que c'est ente 0 et 9. De plus, Huffman ne va pas servir à grand chose puisque toutes les suites de nombre dans pi ont les même fréquence d'apparition.
-
[^]Re: Mensonge !
Posté par ʇpooɹquooɥɔs sɐȷoɔᴉu (Jabber id, ) le 06/01/2010 à 17:03. (lien). Évalué à 2.Si tu as la preuve, ça intéresse du monde, je pense...
--
Tous les nombres premiers sont impairs, sauf un.
Tous les nombres premiers sont impairs, sauf deux.-
[^]Re: Mensonge !
Posté par B. (Jabber id, page perso, ) le 06/01/2010 à 17:46. (lien). Évalué à 4.J'y suis peut-être allé un peu fort, mais les décimales qu'on connaît sont a peut près distribuées de manière équiprobable. Il n'y a pas de preuve que pi est normal, mais on ne pourra rien gagner avec un codage de Hoffman.
-
[^]Re: Mensonge !
Posté par Thomas Douillard () le 06/01/2010 à 18:08. (lien). Évalué à 3.les meilleurs codages sont probablement les programmes de génération. http://fr.wikipedia.org/wiki/Th%C3%A9orie_algorithmique_de_l(...)
-
[^]Re: Mensonge !
Posté par Axioplase ıɥs∀ (page perso, ) le 07/01/2010 à 03:29. (lien). Évalué à 2.Même si je vais en ton sens, je pense qu'il y a un gain à appliquer des algos de compression divers et variés sur des tranches de décimales.
On doit pouvoir, avec un coût relativement limité, compresser avec un algo dynamique des bonnes parties. C'est juste un problème d'optim : trouver un bon découpage P1・P2・・・Pn des décimales de pi tel que comp(P1)・comp(P2)・・・comp(Pn)
Bon, c'est juste mon intuition, mais sur un échantillon de telle taille, tu as forcément des suites remarquables qui se compressent bien.
Et avec une bonne heuristique pour le découpage, plutôt qu'Huffman, tu peux même directement utiliser des algos coûteux.
Enfin, voila un problème très intéressant sur lequel je me pencherai si j'ai le temps.--
Je ne suis pas toujours de mon avis.-
[^]Re: Mensonge !
Posté par Kerro () le 07/01/2010 à 21:02. (lien). Évalué à 2.Cela suppose donc qu'il est possible de compresser efficacement une suite de nombre aléatoires.
Statistiquement, c'est non.
Même en enlevant le mot "efficacement" de ma phrase. Il me semble en effet que la limite éventuellement accessible est de produire des données compressées qui sont de la même taille. Mais pas moins.
En supposant bien entendu des données de taille raisonnablement énorme.-
[^]Re: Mensonge !
Posté par Axioplase ıɥs∀ (page perso, ) le 09/01/2010 à 12:14. (lien). Évalué à 1.Il n'y a pas d'algo efficace pour compresser toute suite de nombres aléatoires, mais si on se penche sur une suite précise, je crois que ça tient la route
D'une part on fait face, présentement, à une suite *finie* de nombres. Et donc, je pense qu'on peut développer un algo efficace pour cette suite (et pas une autre, pas même un bit de plus). Et d'autre part, l'algo qui a servi à générer cette suite est la preuve que la compression efficace est possible !
En revanche, la question est : « a-t-on un moyen plus rentable selon le ratio taille/temps de décompression ? »--
Je ne suis pas toujours de mon avis.
-
-
-
-
[^]Re: Mensonge !
Posté par steph1978 () le 09/01/2010 à 19:27. (lien). Évalué à 2.la preuve du contraire même: http://bellard.org/pi/pi2700e9/pidigits.html, "Statistics for decimal digits". C'est comparable pour chaque décimal, mais pas égale; pourtant, l'échantillon est le plus grand que l'on ait !
Par contre, ce n'est sûrement pas compressible.
-
[^]Re: Mensonge !
Posté par B. (Jabber id, page perso, ) le 10/01/2010 à 00:22. (lien). Évalué à 2.Bah évidemment que sur un nombre fini ce n'est pas exactement égale... m'enfin c'est pas loin donc ça ne marche pas.
-
-
-
-
[^]Re: Mensonge !
Posté par steph1978 () le 09/01/2010 à 19:38. (lien). Évalué à 2.pas 5 bits mais ln(10)/ln(2)~=3.321928095 bits.
un mode de stockage plutôt efficace est de stocker 2 décimales par octet: 1415926535 -> [14][15][92][65][35]; donc sur 4bit; cela permet de lire sans conversion.
cela dit, pour 2700 milliard, il a dû trouver qqch de plus efficace.
en tous cas, lorsqu'on trouve un moyen un peu efficace de le stocker, je ne suis pas persuadé que cela se compresse plus car si CT le cas, cela voudrait dire qu'il existe une formule pour décrire pi autrement que par toutes ses décimales; ou par son symbole bien sûr.
-
[^]Re: Mensonge !
Posté par Axioplase ıɥs∀ (page perso, ) le 13/01/2010 à 06:08. (lien). Évalué à 2.>> une formule pour décrire pi autrement que par toutes ses décimales; ou par son symbole bien sûr.
Et un algo qui décrit comment calculer π, c'est quoi selon toi ?
(Je sais que c'est pas ce que tu voulais dire, mais toujours est-il qu'il existe un nombre impressionnant de formules pour retrouver π)--
Je ne suis pas toujours de mon avis.
-
-
-
[^]Re: Mensonge !
Posté par thedidouille (page perso, ) le 06/01/2010 à 10:38. (lien). Évalué à 10.compression avec perte :
$ cat pi.txt | cut -c -4 -
3.14-
[^]Re: Mensonge !
Posté par gnuk (page perso, ) le 07/01/2010 à 00:28. (lien). Évalué à 4.Rooooh,
on parle de performances de oufs, avec des problèmes I/O disque, bande passante de malade, des chiffres faramineux, correction d'erreurs et tout le merdier, j'en passe et des meilleures (c'est quand même Fabrice Bellard bordel) ...
Et toi t'arrives, pas de stress, comme ça tranquille, genre l'homme le plus classe du monde, en passant 2.5To dans un pipe.
Bah moi je dis bravo, clap - clap, 20/20, vive la France :)-
[^]Re: Mensonge !
Posté par thedidouille (page perso, ) le 07/01/2010 à 10:06. (lien). Évalué à 1.T'as raison, j'aurais du rajouter un head -1 avant ou après le cut (après plutôt).
Tiens, c'est une bonne question de geek ça, si on place le head -1 après, ça change quelque chose?
parce que le cat doit parcourir tout le fichier sinon.-
[^]Re: Mensonge !
Posté par gnuk (page perso, ) le 07/01/2010 à 13:17. (lien). Évalué à 1.Dans un premier temps on pourrait se dire qu'il suffit de travailler sur le fichier directement avec cut :
cut -c -4 pi.txtsauf que cut travaille sur des lignes complètes. Dans le cas où Fabrice B. aurait sauté des lignes toutes les x décimales on se retrouverait avec une sortie du genre :
3.14
_des_chiffres_
_des_chiffres_
_des_chiffres_
[...]
_des_chiffres_
Si il a écrit les décimales sur une seule ligne, dans ce cas cut va quand même lire tout le fichier jusqu'à rencontré sa fin de ligne ou l'EOF, le résultat nous concernant est toujours le même, on parcours 2.5To de données. Peut être mis en évidence avec strace :strace -s 10000 cut -c -4 pi.txt
La commande head travaille aussi sur des lignes complètes, aucune amélioration.
On peut alors utiliser dd, od (le résultat serait a interpréter) ou un script vite fait, pour ne récupérer que les 4 premiers octets :
dd if=pi.txt bs=4 count=1 2>/dev/null;echo
ou
od -N4 -a pi.txt
ou encore
#!/usr/bin/env python
# ouverture du filedescriptor en supposant
# que le fichier ./pi.txt existe
src=open('pi.txt', 'r')
# on lit 4 octets et on les affiche
print(src.read(4))
# fermeture du filedescriptor
src.close
-
[^]Re: Mensonge !
Posté par thedidouille (page perso, ) le 07/01/2010 à 18:42. (lien). Évalué à 1.La commande head travaille aussi sur des lignes complètes, aucune amélioration.
Mmmmh, et si il est placé APRÈS :
[adrien@localhost ~]$ cat > pi.txt
3,14159265[adrien@localhost ~]$ # j'ai fait 2 ctrl D
[adrien@localhost ~]$ cat pi.txt
3,14159265[adrien@localhost ~]$ # pas de saut de ligne
[adrien@localhost ~]$ cat pi.txt | cut -c -4 -
3,14
[adrien@localhost ~]$ # là ça saut bien une ligne
Donc le head devrait être content!-
[^]Re: Mensonge !
Posté par gnuk (page perso, ) le 07/01/2010 à 19:37. (lien). Évalué à 3.Ma remarque faisait référence au pipe, mais ce qui est réellement le plus gênant est de parser 2.5To de données. En plus, dans ta ligne de commande on le fait plusieurs fois, une première fois avec cat, tout ça passe dans le pipe, et ensuite traité par cut.
cat pi.txt | cut -c -4 - ^ ^ | | | +---- données sortantes de pipe (stdout), toujours 2.5To | qui deviennent les données entrantes (stdin) pour cut | données sortantes (stdout) de cat 2.5To et données entrantes de pipe (stdin) la lecture du fichier est complète, jusqu'à atteindre EOFLa suppression du pipe ne règle pas réellement le problème (au lieu de parser deux fois 2.5To de données on les parse qu'une seule fois). Même aveccut -c -4 pi.txt | head -1cut va parser toutes les données et ensuite envoyé le peu de données (stdout provenant de cut) vers le pipe, et head recevra bien un minimum d'octet. Dans ce cas on a gagné de ne pas envoyé 2.5To dans le pipe, par contre on a toujours lu le fichier en entier à cause du fonctionnement interne de cut, c'est pour cette raison qu'il faut faire appel à d'autres commandes qui ne font que lire le strict minimum de données qui nous sont réellement utile. strace met en évidence le comportement interne de cut (head aurait un comportement similaire avec l'option -c) :##### ouverture du fichier open("pi.txt", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=10, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7840000 ##### lecture des données : ici toutes avec l'exemple de fichier pi.txt ##### les 2.5To se retrouveront ici! read(3, "3.14159265", 4096) = 10 ##### ##### fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb783f000 ##### traitement de la demande selon les paramètres passés en ligne de commande read(3, "", 4096) = 0 ##### écriture du résultat (ajout d'un saut de ligne) sur la sortie standard write(1, "3.14\n", 53.14À la base c'était juste pour rebondir sur ta "blague" :)-
[^]Re: Mensonge !
Posté par thedidouille (page perso, ) le 08/01/2010 à 09:25. (lien). Évalué à 3.tu as raison (et merci pour tes explications bien détaillées), mais le head peut quand même envoyer un SIGPIPE lorsqu'il est satisfait :
$ sopranocmd --dbus org.kde.NepomukStorage --model main list "" "" "" | tr -s '\n' 'SL' > big.txt
$ sopranocmd --dbus org.kde.NepomukStorage --model main list "" "" "" > big2.txt
$ time -p cat big.txt | cut -c -4 -
real 7.17
user 0.00
sys 0.05
$ time -p cat big.txt | cut -c -4 - | head -1
real 7.22
user 0.00
sys 0.06
Par contre, avec le big2.txt (qui contient plusieurs lignes) :
$ time -p cat big2.txt | cut -c -4 - | head -1
<htt
Command terminated by signal 13
real 0.04
user 0.00
sys 0.00
le head bufferise les entrées, mais ça ne change rien :
$ cat big2.txt | cut -c -4 - | strace -f -o strace-head.txt head -1
$ cat strace-head.txt | grep "read(0"
7133 read(0, "<htt\n<htt\n<htt\n<htt\n<htt\n<htt\n<h"..., 8192) = 4096
Remplacer le 4 du cut par 8192 (et un plus) pour le big.txt ne change rien (t'as raison donc).
On va arrêter là, dans la vraie vie, évidemment que je ne ferais pas ça! Mon idée d'origine était que le head enverrait un SIGPIPE dès qu'il était content.
Il est pas content après une ligne ce con (et moi non plus)!-
[^]Re: Mensonge !
Posté par thedidouille (page perso, ) le 08/01/2010 à 12:29. (lien). Évalué à 2.sinon, il y a une réponse simple, mais il faut pas être paresseux :
$ grep flush /usr/src/debug/coreutils-7.5/src/cut.c | wc -l
0
$ grep write /usr/src/debug/coreutils-7.5/src/cut.c | grep -v fwrite
Rewrite cut_fields and cut_bytes -- Jim Meyering. */
vraisemblablement du fwrite est utilisé, sans fflush. Pas de setbuf ou setvbuf.
-
-
-
-
-
-
-
-
-
[^]Re: Mensonge !
Posté par netsurfeur () le 05/01/2010 à 22:43. (lien). Évalué à 7.Ça se compresse très bien, la valeur compressée est égale à π à 10^-2.700.000.000.000 près.
-
[^]Re: Mensonge !
[+] Sharpshooter bat le reccord des décimales de PI
... en ajoutant un "2" à la suite des chiffres donnés par Fabrice Bellard.
Sharpshooter aurait déclaré "j'espère faire mieux la prochaine fois mais il me faudra beaucoup d'argent".
Envoyez vos sur mon compte paypas à sharpshooter@paypas.con.
Reprise des calculs
la reprise des calculs à un point de sauvegarde, ce qui permet d'éviter la perte de calcul en cas de coupure de courant
Donc si je comprend bien, il peux reprendre un calcul après que celui-ci ait été arrêté. Est-ce que cela veut aussi dire que pour le calcul des prochaines décimales de Pi, il suffira de reprendre là où le calcul en était, au lieu de tout recommencer comme on le fait jusqu'ici ?
C'est une impression, ou rien que cette "feature" offerte par la solution de Fabrice Bellard est plus impressionnante encore que le record lui-même ?
-
[^]Re: Reprise des calculs
Posté par Boa Treize (page perso, ) le 08/01/2010 à 15:22. (lien). Évalué à 2.Ça a l'air d'être le cas, à ceci près qu'il faudrait alors changer les disques durs et la RAM, parce que manifestement il les a bien remplis lors de son calcul.
-
[^]Re: Reprise des calculs
Posté par _kd () le 09/01/2010 à 12:29. (lien). Évalué à 1.Quand tu écris un programme qui prend plus de quelques jours de calcul, tu fais régulièrement des snapshots de l'état de ton programme pour ne pas avoir à recommencer du début en cas de problèmes. Il faut être un peu inconscient pour ne pas mettre en place un tel système.
-
[^]Re: Reprise des calculs
Posté par Laurent Cligny (page perso, ) le 09/01/2010 à 19:24. (lien). Évalué à 2.Dans ce cas pourquoi ais-je l'impression que les précédents records de décimales de Pi ont été obtenus après recalcul complet ? Pourquoi ne pas reprendre le calcul ou il en était, et ainsi progresser beaucoup plus rapidement ?
-
[^]Re: Reprise des calculs
Posté par Boa Treize (page perso, ) le 10/01/2010 à 00:37. (lien). Évalué à 3.Parce que les gens qui font ces calculs sont entre autres intéressés par l'algorithmie pour faire ces calculs, chaque record a son implémentation, adaptée aux machines sur lesquelles elle va être exécutée. Et bien sûr, le résultat intermédiaire dépend de l'algorithme, et la manière dont il est stocké dépend de l'implémentation.
-
-
-
[^]Re: Reprise des calculs
Posté par Axioplase ıɥs∀ (page perso, ) le 13/01/2010 à 06:14. (lien). Évalué à 2.Euh, c'est *uniquement* sauver transitivement la pile et les registre (transitivement, pour suivre les pointeurs vers le tas)…
Cette « feature », je crois, tu la retrouve dans tous tes .core après un segfault, dans les la migration de machines virtuelles…
Enfin, c'est une technique vieille comme le monde, et très utilisée, comme le dit un commentaire précédent.--
Je ne suis pas toujours de mon avis.



Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.