Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Gangnam Style et le compteur de YouTube : un easter egg pris un peu trop au sérieux

Rendez-vous à 9 223 372 036 854 775 808 vues

Gangnam Style et le compteur de YouTube : un easter egg pris un peu trop au sérieux

Le 08 décembre 2014 à 15h20

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.

 

Gangnam Style

Commentaires (77)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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

votre avatar

plus de 2 milliards de vue de cette chose, voila qui vérifie encore une fois une théorie d’Einstein

votre avatar

Ca a l air fiable alexa

votre avatar







kamomille a écrit :



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





On se demande surtout pourquoi la Finlande en particulier arrive en 5ème position sur les visites&nbsp;<img data-src=" />


votre avatar

fiasco non mais il y a un net décrochage. Le changement de nom qui nuit à la googleisation des contenus?

votre avatar







le duc rouge a écrit :



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&nbsp;en 32 bits&nbsp;du moteur de compte des vues ?





De ce que j’ai compris : vu qu’ils s’en sont rendu compte à temps, il ont implémenté une sorte d’easter-egg pour montrer ce que ça aurait pu faire s’ils avaient laissé leur compteur en l’état, comme il le fut pendant longtemps : en 32bits signé <img data-src=" />



Après, le fait d’avoir laissé le doute s’installer quelques jours, c’est un coup marketing basé sur du buzz, comme on en voit de plus en plus <img data-src=" />


votre avatar

Bon, rendez vous est pris quand la vidéo s’approchera des 2^63 vues <img data-src=" />



<img data-src=" />

votre avatar

&gt;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 !!! <img data-src=" />

votre avatar

le lien entre, je cite :

pour effet de&nbsp;« casser »&nbsp;le compteur de YouTube&nbsp; et Nolwenn Leroy a t-il un rapport ? <img data-src=" />

votre avatar

That’s why java suck.

votre avatar

Au hasard : ipredator ?



Ah mince, c’est la Suède ça…

votre avatar

Pour Nolwenn Leroy, un simple booleen suffit <img data-src=" />

votre avatar

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 <img data-src=" />

ca laisserais deja bien plus de marge

votre avatar

Un booléen signé ou non signé ? <img data-src=" />

votre avatar

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

votre avatar



ce qui donne une amplitude de 4 294 967 294, ce qui correspond à 2^32





Perdu, c’est 4 294 967 296.

votre avatar

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.

&nbsp;

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.

votre avatar







levhieu a écrit :



Une autre façon de voir les choses:

Tous les entiers étant des réels, ça vous ennuie si je fais: «#define int float» ?





Non aucun.

Du moment que tu restes cohérent sur comment les variables représentent les données et comment les fonctions que tu utilises, tu peux faire ce que tu veux. (À la limite tu n’as même pas besoin de conserver la cohérence, tant que tu sais ce que tu fais).







levhieu a écrit :



Et ben non, je ne suis toujours pas d’accord.

Le fait est que justement avec les 2 valeurs on ne cherche pas à faire de l’algèbre de Boole mais de la logique,<img data-src=" />





T’es au courant que l’algèbre de Boole a été écrite justement comme étant une approche algébrique de la logique Aristotélicienne ou tu fais exprès d’ignorer l’origine du truc?


votre avatar







Khalev a écrit :



[…]

T’es au courant que l’algèbre de Boole a été écrite justement comme étant une approche algébrique de la logique Aristotélicienne ou tu fais exprès d’ignorer l’origine du truc?





Non, j’ignorais, et après un petit tour sur Wikipedia, je découvre que Boole n’a pas inventé ce qu’on appelle aujourd’hui une algèbre de Boole. Du coup, il y a le même nom pour deux choses finalement différentes.

Je ne ralerai plus qu’à moitié alors.


votre avatar

VPN surement

votre avatar







Koxinga22 a écrit :



Passer en unsigned est la solution la plus efficiente car atteindre 4 milliards a très peu de chance de se produire. Monter le compteur sur 64 bits pour pouvoir gérer des milliard de milliard de vues est une aberration inutile et couteuse.

Les jeunes de nos jours, ils remplissent la RAM et tuent le CPU en codant comme des gorets.





A moitié d’accord…&nbsp;

Autant il est vrai que la gestion des ressources est souvent négligée, autant il faut parfois savoir ne pas être pingre. Ici, tu proposes un passage à 4 milliards (enfin, en supposant que ça eût été un réel problème de compteur) donc tu proposes seulement une marge de x2 par rapport à un volume déjà identifié. &nbsp;

C’est peu, très peu. &nbsp;

Ca aurait toutes les chances d’être passé, et donc de nécessiter une intervention manuelle ultérieure. Dans une telle situation, le coût est probablement supérieur (d’autant que les plateformes sont 64 bits, donc utiliser du 64 bit n’est pas tellement couteux)

&nbsp;

Mais c’est vrai que dans pas mal de situations, on abuse de marges de sécurité exagérées.&nbsp;


votre avatar

moi je préfère celle là:

cliquer pour voir la vidéo

votre avatar

Which search keywords send traffic to this site?

4.&nbsp;&nbsp;so you start&nbsp; (étonnant que çà passe avant lidd)

5.&nbsp;&nbsp;lidd&nbsp;

&nbsp;<img data-src=" />

votre avatar







V_E_B a écrit :



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.











Faith a écrit :



A moitié d’accord… 

Autant il est vrai que la gestion des ressources est souvent négligée, autant il faut parfois savoir ne pas être pingre. Ici, tu proposes un passage à 4 milliards (enfin, en supposant que ça eût été un réel problème de compteur) donc tu proposes seulement une marge de x2 par rapport à un volume déjà identifié.  

C’est peu, très peu.  

Ca aurait toutes les chances d’être passé, et donc de nécessiter une intervention manuelle ultérieure. Dans une telle situation, le coût est probablement supérieur (d’autant que les plateformes sont 64 bits, donc utiliser du 64 bit n’est pas tellement couteux)

 

Mais c’est vrai que dans pas mal de situations, on abuse de marges de sécurité exagérées.





Tout cela est vrai (nous sommes en train de pinailler :) mais c’est tellement bon) Je suis juste dubitatif sur le fait qu’une vidéo puisse faire tant de vues. Déjà, 2M c’est énorme. Après c’est vrai que la vidéo ne va pas être retirée et qu’elle continuera à faire des vues au fil du temps mais tout de même, elle se démode aussi en parallèle.



Perso, j’aurais revu mon algo pour compter les “vues récentes” ou autre critère tenant compte du temps. Est ce pertinent de montrer qu’une vidéo à fait 5 millions de vues il y a 3 ans mais plus rien depuis ?



Après, le coup du système 64 bits, je me le suis dit aussi, ca “ne coute pas beaucoup plus”. Et j’en ai profité pour réviser les tailles des types dans .Net, c’est affolant, le plus petit short prend 2 octets ! Le int de base qu’on utilise 500 fois par appli : 4 octets, je ne parlerais même pas du double, ce glouton, que j’utilise souvent (le reflexe du float buggué en C).


votre avatar

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.

votre avatar







Koxinga22 a écrit :



Heu une doc sur le C pour commenter Java ? Pas tout à fait pertinent.

Sinon, je suis pas trop d’accord en raison du principe de parcimonie. Atteindre 2 Milliard était une anomalie qui ne s’est vu que sur une seule vidéo. Passer en unsigned est la solution la plus efficiente car atteindre 4 milliards a très peu de chance de se produire. Monter le compteur sur 64 bits pour pouvoir gérer des milliard de milliard de vues est une aberration inutile et couteuse.

Les jeunes de nos jours, ils remplissent la RAM et tuent le CPU en codant comme des gorets.







Youtube héberge 300 nouvelles heures de video débiles supplémentaire par minute, et a déjà unicasté 2 milliards de fois la même video de 5 minutes (qui doit bien faire 30Mo).



Mais vous avez raison, 32 bits supplémentaire pour ce compteur, c’est 32 de trop <img data-src=" />


votre avatar







batoche a écrit :



Youtube héberge 300 nouvelles heures de video débiles supplémentaire par minute, et a déjà unicasté 2 milliards de fois la même video de 5 minutes (qui doit bien faire 30Mo).



Mais vous avez raison, 32 bits supplémentaire pour ce compteur, c’est 32 de trop <img data-src=" />





Hi hi ! Amusant de remettre en perspective :)

Attention à ne pas confondre taille sur le disque dur et taille du bus de données du proc’


votre avatar

<img data-src=" />

votre avatar

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”

votre avatar

Tu as essayé au hasard&nbsp;

google.fr Googlepremier lien :p&nbsp;<img data-src=" />&nbsp;<img data-src=" />&nbsp;

votre avatar

&nbsp; “Si tu sais, partage !”

votre avatar







le podoclaste a écrit :



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.





Ça dépend des processeurs. Sur un micro-contrôleur Infineon, un collègue utilise systématiquement des octets partout où il peut pour économiser de la mémoire (à 6 Ko tout mouillé, c’est un réflexe compréhensible). Sauf que c’est un micro 16 bits, et chaque fois qu’il utilise un octet, l’assembleur généré montre que:




  1. Le compilo, par défaut, alloue un mot de 16 bits (adieu gain mémoire)

  2. A chaque accès, c’est masque avec 0x00ff garanti (on sort les rames, surtout sur les boucles et les index de tableaux)



    Une fois le “problème” corrigé, l’appli perd 10% de son volume. Ce qui n’est pas rien. Mais comme quelqu’un l’a dit plus haut, les jeunes codent comme des gorets, de nos jours.


votre avatar

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 !!!)

votre avatar

Si Google commence à faire des poissons d’avril en décembre… <img data-src=" />

votre avatar

Java has no unsigned integers

votre avatar

Oppa !



bon maintenant on fait pareil avec “What does the fox says ?” <img data-src=" />

votre avatar

Je sens comme une petite moquerie à l’égard de notre Nolwenn Leroy nationale… <img data-src=" />

votre avatar



cela a permis&nbsp;au nombre de vues de Nolwenn Leroy&nbsp;d’exploser.

<img data-src=" />&nbsp;La pub dans les articles.&nbsp;<img data-src=" />

votre avatar







CUlater a écrit :



<img data-src=" />&nbsp;La pub dans les articles.&nbsp;<img data-src=" />





Le pire, c’est que j’ai cliqué ……<img data-src=" />


votre avatar

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 :&nbsp;-2 147 483 648 à 2 147 483 647



&nbsp;Et non&nbsp;-2 147 483 647 à 2 147 483 647&nbsp;comme dit dans l’article

votre avatar

<img data-src=" /> j’espère que t’avais le son coupé au moins !

votre avatar

Html5 pour ma part :)

votre avatar

Va vraiment falloir arrêter avec cette vidéo de merde sinon je ressors les Waaaaazaaaaaaa !



Merde… le coup est parti tout seul… <img data-src=" />

votre avatar







AxelDG a écrit :



Va vraiment falloir arrêter avec cette vidéo de merde sinon je ressors les Waaaaazaaaaaaa !



Merde… le coup est parti tout seul… <img data-src=" />





pourquoi pas René la Taupe aussi ? (non je fais pas de lien, je suis gentil)


votre avatar

Notre Seb est amoureux de la Nolwen pour lui faire de la pub comme ça? <img data-src=" />

votre avatar

Je crois <img data-src=" />

votre avatar

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&nbsp;en 32 bits&nbsp;du moteur de compte des vues ?

votre avatar

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.

votre avatar

J’ai lu cette news y a 1 semaines sur le monde. NXI au coeur de l’information !!!

votre avatar

Bien vu je ne savais pas merci !

votre avatar







coolraoul a écrit :



J’ai lu cette news y a 1 semaines sur le monde. NXI au coeur de l’information !!!







Ben moi je viens de lire cette news sur Next Inpact … comme quoi … <img data-src=" />


votre avatar

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

votre avatar







coolraoul a écrit :



J’ai lu cette news y a 1 semaines sur le monde. NXI au coeur de l’information !!!





J’ai cherché l’article en question sur lemonde.fr , pas trouvé.



J’ai lu un article ailleurs, mais c’était plutôt du genre un article de 20minutes 3secondes.


votre avatar

9 223 372 036 854 775 808 vues on va enfin pouvoir reprendre le visionnage <img data-src=" />

votre avatar

Les fantasmes de Sébastien Gavois ne nous regardent pas !

votre avatar

Java, ça craint.&nbsp;

votre avatar

Quelqu’un peut me filer un lien sur votre source comme quoi youtube est fait en Java ?



Merci d’avance .

votre avatar







Resman a écrit :



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.





Heu une doc sur le C pour commenter Java ? Pas tout à fait pertinent.

Sinon, je suis pas trop d’accord en raison du principe de parcimonie. Atteindre 2 Milliard était une anomalie qui ne s’est vu que sur une seule vidéo. Passer en unsigned est la solution la plus efficiente car atteindre 4 milliards a très peu de chance de se produire. Monter le compteur sur 64 bits pour pouvoir gérer des milliard de milliard de vues est une aberration inutile et couteuse.

Les jeunes de nos jours, ils remplissent la RAM et tuent le CPU en codant comme des gorets.


votre avatar

Ça m’énerve quand on parle de booléen pour un type à 2 valeurs, alors qu’il existe des algèbres de Boole infinies…

votre avatar







levhieu a écrit :



Ça m’énerve quand on parle de booléen pour un type à 2 valeurs, alors qu’il existe des algèbres de Boole infinies…





<img data-src=" />

Pourquoi ça t’énerve, ce n’est pas faux pourtant. L’algèbre de Boole est définie pour un ensemble ayant au moins 2 éléments.

Le fait qu’en informatique et en électronique on n’utilise que la version à 2 éléments est dû au fait que les PCs sont conçus pour s’articuler autour de 2 valeurs. Donc en informatique “classique” comme c’est le cas pour Youtube justement un Booléen = 2 valeurs possibles.



C’est comme si un gars parlait de sa clio et parlait de ses pneus comme étant forcément 4. Toi tu arrives et tu dis :

“ça m’énerve que tu parles de de tes pneus comme en en ayant 4, alors que d’autres véhicules en ont jusqu’à 120!”

Sauf qu’en l’occurence on parle d’une Clio à 4 pneus là. Du moment que ce critère là est clair pour tout le monde ça sert à rien de s’énerver pour ça…


votre avatar

Et ben non, je ne suis toujours pas d’accord.

Le fait est que justement avec les 2 valeurs on ne cherche pas à faire de l’algèbre de Boole mais de la logique,<img data-src=" />

donc ce n’est pas le bon terme qui a été choisi.

Pour reprendre la comparaison automobile (<img data-src=" />) c’est comme si un gars venait et appelait son vélo une voiture parce que c’est aussi un véhicule.



Dans ce domaine, le fortran (<img data-src=" /> again) utilisait le type LOGICAL pour des variables logiques.

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» ?

&nbsp;

votre avatar
votre avatar

Excellent le coup de Leroy

&nbsp;

<img data-src=" />

&nbsp;

votre avatar







coolraoul a écrit :



Tu as essayé au hasard 

google.fr Googlepremier lien :p <img data-src=" /> <img data-src=" />







As-tu essayé au hasard :



Adresse Web :

https://duckduckgo.com/?q=le+monde+psy+gangnam+style&kl=fr-fr



(qui au passage ne te nique pas ta vie privée … <img data-src=" />)


votre avatar

Arf mon lien ne fonctionne pas correctement … (effacez les trucs après “fr-fr”).

votre avatar

Perso j’utilise&nbsphttps://startpage.com/ et j’ai 1 an d’abo chez vpntunnel.

votre avatar







coolraoul a écrit :



Perso j’utilise&#160https://startpage.com/ et j’ai 1 an d’abo chez vpntunnel.







<img data-src=" />


votre avatar

ça rigole bien chez google…

votre avatar

Quand je vois du code de “vieux”, je me dis que les jeunes n’ont rien inventé <img data-src=" />

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&nbsp; <img data-src=" />

votre avatar

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 :




  • autoriser le mélange, mais faire attention à chaque utilisation, et donc alourdir le code par des tests (sans garantie qu’ils n’en soient pas oubliés).

  • interdire l’usage de type non-signé, même si ça à l’air d’être du gaspillage d’octets dans certains cas.



    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.

votre avatar







jb07 a écrit :



Ça dépend des processeurs. Sur un micro-contrôleur Infineon, un collègue utilise systématiquement des octets partout où il peut pour économiser de la mémoire (à 6 Ko tout mouillé, c’est un réflexe compréhensible). Sauf que c’est un micro 16 bits, et chaque fois qu’il utilise un octet, l’assembleur généré montre que:




  1. Le compilo, par défaut, alloue un mot de 16 bits (adieu gain mémoire)

  2. A chaque accès, c’est masque avec 0x00ff garanti (on sort les rames, surtout sur les boucles et les index de tableaux)



    Une fois le “problème” corrigé, l’appli perd 10% de son volume. Ce qui n’est pas rien. Mais comme quelqu’un l’a dit plus haut, les jeunes codent comme des gorets, de nos jours.





    &nbsp;Ben ça rejoint ce que j’ai dit : ça vaut pas le coup d’utiliser un type de taille inférieur au nombre de bit du proco (et même encore pire, puisqu’il y a l’utilisation du masque) &nbsp;<img data-src=" />


votre avatar

Exactement <img data-src=" />

votre avatar

<img data-src=" />

en fait moi betement je suis allé sur lemonde.fr et j’ai cherché comme toi :

Le résultat n’est pas le meme…

votre avatar







le podoclaste a écrit :



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.







En pratique non. En pratique rien ne garantit la taille de l’int. C’est un choix fait par le compilateur.

La norme C te garantit que char &lt;= short &lt;= int &lt;= long &lt;= long long

Et que long est &gt;= à la taille des pointeurs.



(On zappe au passage que rien n’empeche de faire un processeurs avec des pointeurs 32bits qui sait faire du calcul en 64bits nativement et vice versa)



En pratique en i686, et x86_64, PPC (et arm je suppose) char=1B, short = 2B, int = 4B, long=taille du pointer, long long = 8B.



Pour ton deuxième point c’est faux aussi. Si ton type de base est 4B, tu as quand même normalement des instruction pour charger/sauvegarde 1B, 2B, en mémoire. Tu fais potentiellement les calculs en 4B dans tes registres, mais ca ne change pas la place mémoire que ca prend. C’est le cas des Intel aujourd’hui.



Faire un short pour un compteur de boucle ne sert en pratique pas à grand chose, parce qu’il est en général dans ta stack et n’a qu’un impact mineur sur la taille globale.

Stocker des gros tableaux/structure de data pile à la bonne taille, ca peux par contre faire une grosse différence !


votre avatar







lossendae a écrit :



&nbsp; “Si tu sais, partage !”





fr.wikipedia.org WikipediaC’est juste la méthode “universelle” (à part quelques architectures exotiques) d’encoder un négatif en binaire.

Et du coup, la valeur négative de Google marche.


votre avatar

C’est quand mieux comme explication. On est sur NXI, pas dans un colloque de développeur…

votre avatar







lossendae a écrit :



C’est quand mieux comme explication. On est sur NXI, pas dans un colloque de développeur…





C’était surtout visé à l’auteur de l’article plus qu’aux lecteurs !

C’est une drole d’idée de se lancer dans des calculs bizarres quand on ne sait pas comment marche un négatif en binaire :)


Gangnam Style et le compteur de YouTube : un easter egg pris un peu trop au sérieux

  • 32 bits, 64 bits, quelle importance ? 

  •  Et si on sortait la calculatrice pour s'amuser avec ce soi-disant compteur cassé

Fermer