Avec Gangnam Style, PSY a été le premier à franchir la barre du milliard de vues, avant d'enchainer avec deux milliards. Depuis, le clip a dépassé les 2 147 483 647 de vues, ce qui aurait eu pour effet de « casser » le compteur de YouTube. Mais Google peut parfois être facétieux, et une simple annonce d'Easter Egg peut parfois devenir rapidement un buzz mondial.
32 bits, 64 bits, quelle importance ?
Le 21 décembre 2012, Gangnam Style établissait un record impressionnant : la vidéo du clip était la toute première vidéo à dépasser le milliard de vues sur YouTube, coiffant ainsi sur le poteau Justin Bieber. Au mois de mai de cette année, PSY remettait le couvert avec 2 milliards de vues. Depuis, les choses se sont calmées, mais un nouveau cap symbolique a été récemment dépassé : 2 147 483 647 de vues, ce qui correspond à la limite d'un entier signé sur 32 bits. Pour rappel, un tel nombre peut varier de - 2 147 483 648 à + 2 147 483 647, ce qui donne une amplitude de 4 294 967 294, ce qui correspond à 2^32 (d'où le 32 bits).
Pour l'occasion, Google s'est fendu d'un billet sur Google+ où il expliquait n'avoir « jamais pensé qu'une vidéo serait regardée un nombre de fois supérieur à un entier de 32 bits (2 147 483 647), mais c'était avant que nous rencontrions PSY. "Gangnam Style" a été vu si souvent que nous avons dû passer à un entier de 64 bits (9 223 372 036 854 775 808 vues au maximum) ! ».
Et si on sortait la calculatrice pour s'amuser avec ce soi-disant compteur cassé
La plateforme de streaming ajoute qu'il suffit de « passer la souris sur le compteur de la vidéo de PSY pour voir un peu de magie de mathématiques ». Certains ont alors cru y voir un « compteur cassé », mais ce n'était pas le cas. En effet, il ne s'agissait que d'un « easter egg ». Google a depuis précisé à nos confrères de CNet et de Variety que ce changement vers un entier signé de 64 bits a été réalisé « il y a des mois » de cela, lorsque ses équipes se sont rendu compte que la limite approchait.
On peut d'ailleurs remarquer que lorsque l'on passe la souris sur le compteur, celui-ci s'affole pour finalement afficher un nombre négatif : - 2 130 866 844 dans notre cas. Mais si l'on retranche ce dernier au plus grand entier signé sur 32 bits (2 147 483 647), on obtient 16 616 803. Et, ce n'est évidemment pas un hasard : si on ajoute 16 616 803 à 2 147 483 647, on retombe sur le nombre de vues réel de la vidéo (du moins lorsque nous avons réalisé ces calculs).
Une façon pour Google de donner le résultat qui aurait pu être affiché si son compteur avait réellement été « cassé ». L'histoire ne dit par contre pas si cela a permis au nombre de vues de Nolwenn Leroy d'exploser.
Commentaires (77)
#1
Il suffisait déjà de passer en non signé sur 32 bits pour avoir de la marge… ou alors il faudra m’expliquer comment on peut voir une vidéo un nombre négatif de fois :-) Au moins là ils ont de la marge (et ils pourront toujours passer en non signé 64 bits plus tard !!!)
#2
Si Google commence à faire des poissons d’avril en décembre…
" />
#3
Java has no unsigned integers
#4
Oppa !
" />
bon maintenant on fait pareil avec “What does the fox says ?”
#5
Je sens comme une petite moquerie à l’égard de notre Nolwenn Leroy nationale…
" />
#6
cela a permis au nombre de vues de Nolwenn Leroy d’exploser.
#7
#8
Passer de signé à non signé ne fait gagné qu’un facteur 2, alors que de passer directement au 64bits donne un facteur 2^32. De plus, certains langages ne supporte pas les entiers non signés (ex: Java).
Sinon la plage des entiers signés c’est : -2 147 483 648 à 2 147 483 647
Et non -2 147 483 647 à 2 147 483 647 comme dit dans l’article
#9
#10
Html5 pour ma part :)
#11
Va vraiment falloir arrêter avec cette vidéo de merde sinon je ressors les Waaaaazaaaaaaa !
" />
Merde… le coup est parti tout seul…
#12
#13
Notre Seb est amoureux de la Nolwen pour lui faire de la pub comme ça?
" />
#14
Je crois
" />
#15
Je ne suis pas sûr d’avoir saisi le second degré … il s’agit d’un clin d’oeil de geek ou une réelle limitation technologique liée au code source en 32 bits du moteur de compte des vues ?
#16
En parlant de compteur de pages vues, Alexa c’est fiable comme truc??
Si oui, peut-on dire que NextInpact V6 est un fiasco?
http://www.alexa.com/siteinfo/nextinpact.com
#17
plus de 2 milliards de vue de cette chose, voila qui vérifie encore une fois une théorie d’Einstein
#18
Ca a l air fiable alexa
#19
#20
fiasco non mais il y a un net décrochage. Le changement de nom qui nuit à la googleisation des contenus?
#21
#22
Bon, rendez vous est pris quand la vidéo s’approchera des 2^63 vues
" />
" />
#23
>L’histoire ne dit par contre pas si cela a permis au nombre de vues de Nolwenn Leroy d’exploser.
" />
Ca devrait être interdit de balancer ce genre de lien !
Ca peut faire saigner des oreilles quand même !!!
#24
le lien entre, je cite :
" />
pour effet de « casser » le compteur de YouTube et Nolwenn Leroy a t-il un rapport ?
#25
That’s why java suck.
#26
Au hasard : ipredator ?
Ah mince, c’est la Suède ça…
#27
Pour Nolwenn Leroy, un simple booleen suffit
" />
#28
l’idiotie a la base, c’est d’utiliser un signed int pour le compteur, apres tout, comment pourait il etre negatif?
" />
parce que j’ai beau essayer de de-regarder certaines choses, jusqu’a present, a par tun bon coup sur la tete pour une amnesie, ou alzheimer, je vois pas trop comment
ca laisserais deja bien plus de marge
#29
Un booléen signé ou non signé ?
" />
#30
Youtube est codé en Java et Java n’a pas de non signé int (unsigned int). Allo quoi? désolé c’est parti tout seul
There are no unsigned types in Java
#31
ce qui donne une amplitude de 4 294 967 294, ce qui correspond à 2^32
Perdu, c’est 4 294 967 296.
#32
Ce n’est pas à cause de Java, les coding standards de Google recommandent de ne pas utiliser d’entiers non signés en raison des risques de bugs qu’ils entrainent :
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types
De plus passer en non signé n’aurait rajouté qu’un seul bit supplémentaire, et il est fort probable qu’une vidéo dépasse 4 milliard de vue dans un avenir plus ou moins proche. Donc logique de passer directement au 64 bits.
#33
J’ai lu cette news y a 1 semaines sur le monde. NXI au coeur de l’information !!!
#34
Bien vu je ne savais pas merci !
#35
#36
je l’avais lu sur un autre site, mais pas qu’il y avait un easter egg.
Et puis franchement, c’est pas une infos capitale qui se doit de sortir tout de suite, y a des choses beaucoup plus importante et qui influent pas mal sur nos finances (et le moral) qu’un easter egg sur YT. Les sujets importants étant en plus traités de facon plutot profonde par PCI
#37
#38
9 223 372 036 854 775 808 vues on va enfin pouvoir reprendre le visionnage
" />
#39
Les fantasmes de Sébastien Gavois ne nous regardent pas !
#40
Java, ça craint.
#41
Quelqu’un peut me filer un lien sur votre source comme quoi youtube est fait en Java ?
Merci d’avance .
#42
#43
Ça m’énerve quand on parle de booléen pour un type à 2 valeurs, alors qu’il existe des algèbres de Boole infinies…
#44
#45
Et ben non, je ne suis toujours pas d’accord.
" />
" />) c’est comme si un gars venait et appelait son vélo une voiture parce que c’est aussi un véhicule.
" /> again) utilisait le type LOGICAL pour des variables logiques.
Le fait est que justement avec les 2 valeurs on ne cherche pas à faire de l’algèbre de Boole mais de la logique,
donc ce n’est pas le bon terme qui a été choisi.
Pour reprendre la comparaison automobile (
Dans ce domaine, le fortran (
Et pourtant, quelle horreur de langage …
Une autre façon de voir les choses:
Tous les entiers étant des réels, ça vous ennuie si je fais: «#define int float» ?
#46
https://www.youtube.com/watch?v=tu3Z7pUERKU
#47
Excellent le coup de Leroy
" />
#48
C’est pertinent dans le sens que Google aurait pu utilliser Java pour Youtube* entre autre pour éviter le problème qu’ils mentionnent dans leur guidelines. Si Google se méfie des unsigned int, ce n’est pas un défaut de Java dans ce contexte que de ne pas en proposer.
Quand à ne pas passer en 64 bit et aux question de performance… il est désormais prouvé que des vidéos peuvent atteindre un cap “qui ne sera manifestement jamais atteint”. Passer en 64 bit est tout à fait logique pour la pérénité (plus le temps passe, plus les vidéo populaires seront vues, et les vues ne descendent jamais) et dans la manière de faire de Google (avec des serveurs peu cher et très redondants).
Ce n’est pas de l’incompétence ou de la fainéantise des devs, c’est juste un comportement rationnel dans le contexte actuel. L’optimisation n’a de sens que si on a déjà des problèmes de perf, sinon c’est juste du temps de dev perdu. Le temps de dev coûte bien plus cher que la barrette de ram, et présente plus de risques de régression ou de nouveau bug.
Je précise que je parle pour un logiciel d’entreprise, pas à destination des particuliers. Dans ce second cas, il est beaucoup moins acceptable de pousser l’utilisateur à l’upgrade, dont le coût en proportion de l’achat du logiciel est bien plus élevé que pour une compagnie.
* apparemment pas le cas, d’après Wikipédia. Ça serait du Python + javascript.
#49
#50
#51
VPN surement
#52
#53
moi je préfère celle là:
cliquer pour voir la vidéo
#54
Which search keywords send traffic to this site?
" />
4. so you start (étonnant que çà passe avant lidd)
5. lidd
#55
#56
Généralement, la taille du int s’adapte à celle du processeur cible, même en C. En 32 bits, il fera 4 octets, en 64, 8. Quand au double, il a toujours fait 64 bits, pour autant que je sache.
Après, (corrigez moi si je me trompe) à moins de devoir être sauvegarder en binaire, ça n’a pas d’incidence d’utiliser des types de données de taille inférieure à celle de ton processeur. Un proco 32 bits, gère les données 32 bits par 32 bits, donc utiliser un short comme compteur de boucle for ne sert à rien.
#57
#58
#59
#60
Ce serait peut-être bien de faire un peu de lecture sur les compléments à 2 pour l’encodage des négatifs…
Ca évitera de sortir des valeurs mystiques de “16 616 803”
#61
Tu as essayé au hasard
" /> 
" />
https://www.google.fr/#q=le+monde+psy+gangnam+style
premier lien :p
#62
“Si tu sais, partage !”
#63
#64
#65
Arf mon lien ne fonctionne pas correctement … (effacez les trucs après “fr-fr”).
#66
Perso j’utilise https://startpage.com/ et j’ai 1 an d’abo chez vpntunnel.
#67
#68
ça rigole bien chez google…
#69
Quand je vois du code de “vieux”, je me dis que les jeunes n’ont rien inventé
" />
" />
Les mauvais codeurs ont toujours existé, il ne faut pas se leurrer. Maintenant, il ne faut pas confondre “mauvais code” et “code adapté à un paradigme différent “. Du code Java sur cluster Beowulf, ça ne s’optimise pas pareil que de l’assembleur sur 486.
Je dois actuellement reprendre du code d’un type qui a jugé bon “d’optimiser” son appli. Le code n’est pas intrinsèquement mauvais, ça ferait effectivement gagner des perf… si ça tournait sur des serveurs dix fois moins puissant que ceux cibles (qui n’ont jamais changé). Les perfs n’ont jamais été un problème en premier lieu. Mais en attendant, il a juste passé du temps à rendre son code parfaitement illisible. Il y a des baffes qui se perdent
#70
Orienter ses développements sur les optimisations avant tout le reste est une mauvaise pratique. On peut rarement optimiser sans rendre la maintenance du code plus difficile (hormis les cas où les problèmes de performance sont dus à du très mauvais code, bien sûr).
Pour le cas en question, si on regarde les guidelines de Google postées plus haut, ils préconisent d’éviter d’utiliser les types non-signés, car les opérations qui mêlent types signés et non-signés peuvent provoquer des erreurs à l’exécution. On peut éviter ça de deux manières :
Si on me demande, je préfère de loin la 2e solution. J’ai du code à maintenir, et mes utilisateurs ce qu’il faut en RAM, puissance et stockage.
#71
#72
Exactement
" />
#73
en fait moi betement je suis allé sur lemonde.fr et j’ai cherché comme toi :
Le résultat n’est pas le meme…
#74
#75
#76
C’est quand mieux comme explication. On est sur NXI, pas dans un colloque de développeur…
#77