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). Fabrice a écrit le programme ayant permis le calcul des décimales. Il utilise l'algorithme de Chudnovsky pour calculer les chiffres en base binaire, avant de les convertir en base décimale. Le programme permet de vérifier les décimales calculées, palliant ainsi les erreurs liées au matériel et la reprise des calculs à un point de sauvegarde, ce qui permet d'éviter la perte de calcul en cas de coupure de courant !
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.
Aller plus loin
- Site dédié à ce record (884 clics)
- Quelques décimales de Pi (457 clics)
- Communiqué de presse du record (118 clics)
- Article Slashdot à l'origine de la dépêche (49 clics)
- Fichier pdf détaillé (pour matheux) (363 clics)
# Et après ?
Posté par domiLeChauve . Évalué à 5.
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é (site web personnel) . Évalué à 10.
[^] # Re: Et après ?
Posté par Nonolapéro . Évalué à 7.
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 monde_de_merde . Évalué à 10.
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 . Évalué à 10.
Échapper aux flics ? ^^
[^] # Re: Et après ?
Posté par Grunt . Évalué à 10.
À faire le tour d'un cercle de 31,831 mètres de diamètre le plus rapidement possible.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Et après ?
Posté par KiKouN . Évalué à 10.
[^] # Re: Et après ?
Posté par bubar🦥 (Mastodon) . Évalué à 6.
okok je connais le chemin
[^] # Re: Et après ?
Posté par Anonyme . Évalué à 10.
[^] # Re: Et après ?
Posté par zerkman (site web personnel) . Évalué à 4.
[^] # Re: Et après ?
Posté par Laurent Cligny (site web personnel) . Évalué à 8.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 3.
10 puissance 80 c'est énorme aussi... égalité sur la taille.
[^] # Re: Et après ?
Posté par fabien . Évalué à 3.
[^] # Re: Et après ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Et après ?
Posté par fabien . Évalué à 2.
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 BAud (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à 7.
[^] # Re: Et après ?
Posté par koxinga . Évalué à 0.
Et quelle est la différence selon toi ?
[^] # Re: Et après ?
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et après ?
Posté par Grunt . Évalué à 4.
Tu confonds avec:
lim (e(x) - sqrt(x)) [quand x tend vers l'infini],
qui existe bel et bien et vaut +∞
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Et après ?
Posté par fabien . Évalué à 1.
[^] # Re: Et après ?
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Et après ?
Posté par campagnard . Évalué à 4.
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 2PetitsVerres . Évalué à 4.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et après ?
Posté par koxinga . Évalué à 1.
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 . Évalué à 10.
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 ?
Posté par Grunt . Évalué à 2.
Géométrique?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Et après ?
Posté par Gui13 (site web personnel) . Évalué à 2.
[^] # Re: Et après ?
Posté par Miod in the middle . Évalué à 3.
[^] # Re: Et après ?
Posté par pini . Évalué à 5.
Personne n'est choqué par ce genre de pratique douteuse ?
[^] # Re: Et après ?
Posté par Anonyme . Évalué à 4.
Les variable global et la façon de coder général est(sont)… HORRIBLE !
[^] # Re: Et après ?
Posté par Hobgoblins Master (Mastodon) . Évalué à 6.
[^] # Re: Et après ?
Posté par ckyl . Évalué à 5.
Ce sont les objets en "automatic storage duration" qui ne sont pas initialisés.
[^] # Re: Et après ?
Posté par lasher . Évalué à 5.
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 . Évalué à 6.
C'est une philosophie une certaine recherche d'une esthétique moche ...
[^] # Re: Et après ?
Posté par steph1978 . Évalué à 2.
[^] # Re: Et après ?
Posté par Miod in the middle . Évalué à 4.
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 Anonyme . Évalué à 3.
Rah, il a raison. C'est une honte ! :)
[^] # Re: Et après ?
Posté par THE_ALF_ . Évalué à 7.
[^] # Re: Et après ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Et après ?
Posté par steph1978 . Évalué à 2.
[^] # Re: Et après ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
https://bugs.freedesktop.org/show_bug.cgi?id=21475
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Et après ?
Posté par Nonolapéro . Évalué à 1.
Ya un fil sur le forum bépo > http://forum.bepo.fr/viewtopic.php?id=124
[^] # Re: Et après ?
Posté par Selso (site web personnel) . Évalué à 0.
[^] # Re: Et après ?
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et après ?
Posté par François B. . Évalué à 7.
http://www.wikihow.com/Calculate-Pi-by-Throwing-Frozen-Hot-D(...)
[^] # Re: Et après ?
Posté par Rémi Hérilier . Évalué à 1.
[^] # Re: Et après ?
Posté par Bilbo . Évalué à 10.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
Peut-être parce qu'on apprend ces temps-ci que polluer et gaspiller l'énergie c'est mal ?
[^] # Re: Et après ?
Posté par bubar🦥 (Mastodon) . É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 (site web personnel) . Évalué à 3.
On peut donc calculer que la clim de 3k€ aurait besoin de 25k€ de panneaux solaires, difficile à faire passer la pilule.
"La première sécurité est la liberté"
[^] # Re: Et après ?
Posté par Prosper . Évalué à 0.
De puissance oui, pas de consommation...( 3 à 4x moins généralement )
[^] # Re: Et après ?
Posté par claudex . Évalué à -1.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et après ?
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et après ?
Posté par Prosper . Évalué à 6.
[^] # Re: Et après ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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.
"La première sécurité est la liberté"
[^] # Re: Et après ?
Posté par khivapia . Évalué à 4.
É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 ナイコ (site web personnel) . Évalué à 3.
Donc l'énergie consommée par une clim est essentiellement dédiée à compenser des pertes mécaniques :) !
[^] # Re: Et après ?
Posté par claudex . Évalué à 3.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et après ?
Posté par ナイコ (site web personnel) . Évalué à 2.
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 . Évalué à 2.
[^] # Re: Et après ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, il te faut 11 ans pour rentabiliser tes panneaux solaires à 0.1€/Kw chez EDF.
"La première sécurité est la liberté"
[^] # Re: Et après ?
Posté par Thomas Douillard . Évalué à 2.
Ç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 (site web personnel) . Évalué à 2.
Même si l'électricité augmente, cela ne sera pas rentable avant 10 ans.
"La première sécurité est la liberté"
[^] # Re: Et après ?
Posté par Bilbo . Évalué à 8.
[^] # Re: Et après ?
Posté par nomorepost . Évalué à 3.
[^] # Re: Et après ?
Posté par khivapia . Évalué à 10.
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 ?
Posté par kowalsky . Évalué à 10.
Une question me taraude, pourquoi avoir décidé de s'arreter à 2700 M ?Parce que Fedora 10 etait passé en "fin de support" ![^] # Re: Et après ?
Posté par ZeroHeure . Évalué à 1.
tu peux expliquer ? je n'ai pas compris...
tu veux dire lent par rapport à quoi ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Et après ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Et après ?
Posté par steph1978 . Évalué à 2.
Quant à la place restante - je n'avais pas fait le calcul - mais je crois qu'il y a des calculs intermédiaires - genre conversion de base - non ?
[^] # Re: Et après ?
Posté par Benjamin Henrion (site web personnel) . Évalué à 10.
A la Quadrature Du Net de vendre plus de posters avec des décimales de PI.
[^] # Re: Et après ?
Posté par hervé Couvelard . Évalué à 4.
[^] # Re: Et après ?
Posté par tibboH . Évalué à 2.
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 2PetitsVerres . Évalué à 4.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et après ?
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
…en base π.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Et après ?
Posté par Mikaël Cordon . Évalué à 2.
Mais bon, 131 jours pour crypter un mail… :D
[^] # Re: Et après ?
Posté par Crazy Diver . Évalué à 3.
Désolé :-)
[^] # Re: Et après ?
Posté par steph1978 . Évalué à 2.
[^] # Re: Et après ?
Posté par Thomas Douillard . Évalué à 2.
D'ailleurs il y a des gens qui battent des records en quelques jours de calculs à peine ...
# Comme quoi ...
Posté par Xavier Bestel (site web personnel) . Évalué à 10.
Sinon, il est quand même fort ce Fabrice. Chapeau.
[^] # Re: Comme quoi ...
Posté par steph1978 . Évalué à 2.
d'autre part, si j'ai bien compris, certaine partie du calcul sont multi-threadées; c'est bien une forme de parallélisation.
# Bof
Posté par 2PetitsVerres . Évalué à 9.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Bof
Posté par Snarky . Évalué à 4.
[^] # Re: Bof
Posté par barmic . Évalué à 7.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pour la seconde fois
Posté par Xavier Teyssier (site web personnel) . Évalué à 8.
Plus d'info à partir de là : http://fr.wikipedia.org/wiki/Fabrice_Bellard
[^] # Re: Pour la seconde fois
Posté par nomorepost . Évalué à 10.
Il faut craindre qu'il aille de mal en PI.
# et ...
Posté par bubar🦥 (Mastodon) . Évalué à 9.
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 (site web personnel) . Évalué à 5.
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 . Évalué à -3.
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 (site web personnel) . Évalué à 7.
[^] # Re: et ...
Posté par arnaudus . Évalué à 3.
[^] # Re: et ...
Posté par claudex . Évalué à 8.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: et ...
Posté par bubar🦥 (Mastodon) . Évalué à 0.
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 . Évalué à 5.
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 (site web personnel) . Évalué à 7.
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 claudex . Évalué à 3.
wget -O pi.txt http://ladressedes2000milliardspremièresdécimales
cat /dev/random>> pi.txt
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: et ...
Posté par Anonyme . Évalué à 3.
[^] # Re: et ...
Posté par nomorepost . Évalué à -2.
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 (site web personnel) . Évalué à 3.
http://bellard.org/tcc/tccboot.html
[^] # Re: et ...
Posté par Samuel Thibault (site web personnel) . Évalué à 10.
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 ...
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Merci de tes précisions, qui m'ont éclairées aussi.
# 2000/96 ~ 20
Posté par J Avd . Évalué à 1.
[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é...
"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 monde_de_merde . Évalué à 5.
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
Posté par grid . Évalué à 9.
[^] # Re: meuh
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 10.
[^] # Re: meuh
Posté par Prae . Évalué à 1.
# Fabrice Bellard..
Posté par alzorglub . Évalué à 9.
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 . Évalué à 1.
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 . Évalué à 2.
Faudrait lui demander
J'avais aussi oublié le fameux lzexe !
Je me sens vieux :(
# Phôte
Posté par Valerian (site web personnel) . Évalué à 1.
:o
[^] # Re: Phôte
Posté par patrick_g (site web personnel) . Évalué à 3.
# Ordinateur de bureau
Posté par Spacio . Évalué à 10.
Mais saluons l'exploit tout de même.
[^] # Re: Ordinateur de bureau
Posté par Guillaume Denry (site web personnel) . Évalué à 2.
De nos jours, 4Gio -sur les machines vendues actuellement- c'est plutôt courant.
[^] # Re: Ordinateur de bureau
Posté par Bilbo . Évalué à 2.
* 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
Posté par shbrol . Évalué à 9.
[^] # Re: Ordinateur de bureau
Posté par Zenitram (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 5.
[^] # Re: Ordinateur de bureau
Posté par campagnard . Évalué à 4.
[^] # Re: Ordinateur de bureau
Posté par Chaddaï Fouché . Évalué à 4.
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. . Évalué à 6.
[^] # Re: Ordinateur de bureau
Posté par houra . Évalué à 3.
Sedullus dux et princeps Lemovicum occiditur
# question con ???
Posté par bibitte . Évalué à 6.
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 ???
Posté par Elfir3 . Évalué à 1.
d'un autre côté, chuck norris à dit : "il n'y a que les cons qui ne posent pas de questions"...
[^] # Re: question con ???
Posté par Dr BG . Évalué à 4.
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 bibitte . Évalué à 2.
"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 bibitte . Évalué à 4.
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 ???
Posté par nonas . Évalué à 1.
[^] # Re: question con ???
Posté par Elfir3 . Évalué à 3.
Du moins c'est ce que je comprends en lisant l'article wikipedia pointé ci-dessus...
[^] # Re: question con ???
Posté par patapon . Évalué à -2.
Désolé.
[^] # Re: question con ???
Posté par steph1978 . Évalué à 2.
Sur cette page, http://bellard.org/pi/pi2700e9/pidigits.html, il donne un extrait, c'est du décimal.
# et la calculette?
Posté par vladislav askiparek . Évalué à 2.
[^] # Re: et la calculette?
Posté par Prae . Évalué à 3.
# Mensonge !
Posté par Snarky . Évalué à 1.
Le petit fichier de... 2,5 To environ... Mais il a le droit de le compresser ;)
[^] # Re: Mensonge !
Posté par olosta . Évalué à 2.
[^] # Re: Mensonge !
Posté par kd . Évalué à 10.
[^] # Re: Mensonge !
Posté par Snarky . Évalué à 2.
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.
[^] # Re: Mensonge !
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Les décimales de pi sont plutôt aléatoires et donc difficiles à compresser.
[^] # Re: Mensonge !
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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.
[^] # Re: Mensonge !
Posté par Dr BG . Évalué à 3.
[^] # Re: Mensonge !
Posté par 2PetitsVerres . Évalué à 2.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Mensonge !
Posté par Dr BG . Évalué à 4.
[^] # Re: Mensonge !
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Mensonge !
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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.
[^] # Re: Mensonge !
Posté par Kerro . Évalué à 2.
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∀ (site web personnel) . Évalué à 1.
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 ? »
[^] # Re: Mensonge !
Posté par steph1978 . Évalué à 2.
Par contre, ce n'est sûrement pas compressible.
[^] # Re: Mensonge !
Posté par Dr BG . Évalué à 2.
[^] # Re: Mensonge !
Posté par steph1978 . Évalué à 2.
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∀ (site web personnel) . Évalué à 2.
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 π)
[^] # Re: Mensonge !
Posté par thedidouille . Évalué à 10.
$ cat pi.txt | cut -c -4 -
3.14
[^] # Re: Mensonge !
Posté par gnuk . Évalué à 4.
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 . Évalué à 1.
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 . Évalué à 1.
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.txtLa 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;echoou
od -N4 -a pi.txtou 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 . Évalué à 1.
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 . Évalué à 3.
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 . Évalué à 3.
$ 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 . Évalué à 2.
$ 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 . Évalué à 7.
[^] # Re: Mensonge !
Posté par Gniarf . Évalué à 3.
# Erreur de titre
Posté par Kerro . Évalué à 7.
Je me souviens de son nom depuis que j'ai utilisé un logiciel nommé LZEXE.EXE qui date de... certains ici n'étaient pas nés.
# et ...
Posté par Guy . Évalué à 10.
Ce logiciel est aujourd'hui utilisé par la plupart des players (libre)
de medias ...
Guy
# Sharpshooter bat le reccord des décimales de PI
Posté par Sharpshooter . Évalué à -3.
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
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 2.
[^] # Re: Reprise des calculs
Posté par kd . Évalué à 1.
[^] # Re: Reprise des calculs
Posté par Laurent Cligny (site web personnel) . Évalué à 2.
[^] # Re: Reprise des calculs
Posté par Boa Treize (site web personnel) . Évalué à 3.
[^] # Re: Reprise des calculs
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.