Reprise du message précédent :

Enfin faut surtout lire les infos à la source http://www.dslreports.com/news/128454

A noter que moi ça me fait ça rien que quand je passe de VLC à Mplayer+ffmpeg (avec ou sans filtres, mais c'est encore plus flagrant avec un petit termporal gradient+postprocessing). Ma télé donne d'ailleurs aussi un post-processing (et unblocking) de super bonne qualité.  

A mettre en contraste avec la scène d'intro dont ils parlent avant. En gros, si les contours sont bien délimités, y a pas de souci mais dès qu'il y a des nuances c'est la merde. Comme toujours dans les vidéos très compressées.
Le point le plus marquant est quand même le débit dégueulasse, c'est du foutage de gueule ; quitte à proposer de l'image ultra haute def, faut balancer sur un débit qui poutre. On sait bien que la VOD 4K sera pas réaliste pour l'ADSL, mais bon, ça fait style d'annoncer qu'on envoie de la 4K dans les tuyaux

Non mais il y a un gain par rapport à la VOD existante.

http://article.gmane.org/gmane.os.openbsd.misc/211963

t'as oublié la dernière ligne.

Oui alors OK, si on a 15 Mbps en descente et si on a Netflix Pour rappel, la plupart des décodeurs TV de box en France chope des flux en 6 à 12 Mbps (pour les chaînes HD) et y a des freezes ou artefacts réguliers chez pas mal de monde...
 
Faut pas se leurrer sur la 4K, le matos est hors de prix, le contenu existe pas (sauf en info pure, genre dev ou jeux et encore), le support physique n'existe pas et pour le dématérialisé, la plupart des gens n'ont pas assez de débit pour en profiter (nraynaud avec ses 16 Mbps il est "faster than 63% of FR" ). Mon point c'était surtout de montrer que c'était pas réaliste en 2014 de vouloir faire de la VOD 4K ; de la VOD en 15 Mbps pourquoi pas, mais ça filtre déjà la moitié des Français. Alors de la 4K en 15 Mbps... ça fait vraiment "on essaie de rentrer la 4K au chausse-pied "

 
OpenFacepalm

 
Vu que le dernier argument marketing miracle, la 3D, s'est lamentablement vautré, faut bien trouver un truc rapidement en attendant la coupe du monde de foot

C'est plutôt surprenant, vu que sur pas mal d'OS t'as tout ce qu'il faut pour faire des validations mémoire à coup de mmap/munmap plutôt que de juste jouer avec sbrk (c'est le principe antique de Electric-Fence d'ailleurs si je ne dis pas de bêtises).  
 
Quand aux mauvaises performances, c'est surprenant aussi vu que de nos jours, c'est plutôt au niveau des lib standard ou des OS qu'on préfère décider des paramètres de performance de l'allocateur (perfomance single-threadée vs multi-threadée, fragmentation vs pooling, allocation à des adresses à la con vs stabilité des pointeurs en 32/64 bits, etc.). Le "some platform" en question, c'est VMS ? Parce qu'à ma connaissance, même AIX sait faire des trucs moustachus sur ses segments mémoire.

je bosse avec des clients qui utilisent la notation hongroise, j'ai envie de me pendre

Tiens c'est la fête des poneys sur Reddit aujourd'hui?

Chais pas mais c'est pas vieux, ça a été ajouté en 2008: https://github.com/openssl/openssl/ [...] 523874e6e8

Les consoles à tout hasard

Edit : (c'est probablement pas des consoles qu'ils se soucient, mais niveau allocation coûteuses, elles sont pas mal placées)

Les consoles last-gen en x86-64 avec mémoire unifiée et DDR5?

c'est un problème algorithmique plus que de vitesse non ?

edit: je pense que j'ai tord, mais c'est plutôt qu'ils vont comparer le malloc de la plateforme avec le reste des opérations mémoire ou d'autres implémentation et toujours vouloir une piscine plus longue et un 4x4 plus grand que les Jones.

 
C'étaient pas celles qui étaient là en 2008, j'ai souvenir que l'allocateur par défaut sur PS3 était vraiment insuffisant, je serais pas surpris que ce soit encore le cas sur PS4 (vu que tu parles de DDR5).
Sur xbox one, c'est probablement moins un souci.

exactement

S'moins "les consoles modernes" que "la console à l'archi la plus merdique des 3-4 dernières générations (sinon plus)"

vous pensez quoi de l'indentation volontairement brutale pour marquer que j'ai coupé au milieu d'une expression ?
 
C'est moche, mais je me dit que c'est complètement explicite, le niveau d'indentation + le premier caractère de la ligne permettent de savoir qu'on est dans une expression sans avoir besoin de lire le détail.

 
Archi merdique ou pas, t'es pas obligé de faire un allocateur ultra générique qui traite une alloc de 4 octets de la même manière qu'une alloc de 200ko.

J'ai aussi tendance à faire ce genre de découpage, donc je valide  

Théoriquement le code est plus souvent lu qu'écrit. Dans ce genre de cas, se contenter de if-then-else prend peut être plus de place mais demande moins de réflexion au moment du debug.

+1

mais le line-count ? c'est comme l'uptime chez un linuxien

+1 pour le if/else
j'utilise jamais l'opérateur ternaire (même si MISRA l'autorise ), mais si jamais je devais le faire ça serait pas pour un truc aussi long de toute façon

Je ne trouve pas, l'opérateur ternaire permet d'indiquer clairement que le test ne sert qu'à assigner une valeur ou une autre à une variable donnée. Le if-then-else demande de lire ce qu'il y a dans la structure.

 
var visibility = !this.get('hideWhenOutOfView') || (bboxIntersect(viewBox, this.get('bbox')) && zoomLevel >= this.get('minVisibleZoomLevel'))
       
c'est pas équivalent ?
 
par contre quand l'expression est complexe ça vaut le coup d'exploser en sous variables

Déjà utiliser une ternaire pour une expression booléenne je trouve ça un peu curieux.
Grosso modo ici tu manipules 3 booléens :
-> le paramètre hideWhenOutOfView
-> le fait que l'objet soit dans le viewport ou non
-> le fait que l'objet soit affiché à ce niveau de zoom

Mais derrière ce booléen, t'as un concept important, celui d'être "out of view".
Du coup j'aurais probablement eu un truc genre

et pour la compréhension un truc du style :

edit: inversé l'ordre dans isOutOfView pour éviter des appels à bboxIntersect() après la remarque de nraynaux

oui, pas mal.
 
Parr contre attention, bboxIntersect() est relativement lent, donc il peut pas être spéculativement calculé.

 
Et ça cache qu'on peut faire :

à la place de ça :

Perso, entre l'opérateur ternaire et l'expression logique, les 2 faisant 3 km, je préfère l'opérateur ternaire
Le !(machin.IsBidule()) || youpi <= 15 && roger > testDeLaMort(13), c'est se coller des emmerdes tout seul.

j'utilise pas mal le ternaire, mais c'est un déformation professionnelle, je fais de l'électronique numérique à la base et le ternaire c'est un "multiplexeur".
 
d'ailleurs quand tu mets des constantes true/false dans une opération ternaire ou quand tu colles un '1' ou un '0' sur un multiplexeur c'est simplifiable en 'or' ou en 'and'
 
 
res = cond ? a : true   c'est pareil que:   res = !cond || a ;
res = cond ? a : false  c'est pareil que:   res = cond && a ;
res = cond ? true : a   c'est pareil que:   res = cond || a ;
res = cond ? false : a  c'est pareil que:   res = !cond && a ;
 
si je ne me plante pas  

C'est clair que le plus propre c'est de mettre ça dans une fonction bien nommée qui permettra de facilement changer les conditions plus tard si besoin.

oui c'est ce que j'ai dis, il vaut mieux découper en sous expressions comprehensibles

tiens, effectivement puisque vous répondez out-of the box, ça peut être intéressant,  voici la méthode complète :  

refreshVisibility: function (viewBox, zoomLevel) {
            var lodIndex = this.computeLodIndex(zoomLevel);
            var visibility = this.get('hideWhenOutOfView')
                || bboxIntersect(viewBox, this.get('bbox')) && zoomLevel >= this.get('minVisibleZoomLevel');
            if (this.get('currentLodIndex') === lodIndex && this.get('currentVisibility') === visibility)
                return;
            this.set('currentLodIndex', lodIndex);
            this.set('currentVisibility', visibility);
            this.installLodRepresentation(visibility ? lodIndex : NaN);
        }

(d'ailleurs si vous avez faire mieux avec ember, notamment si y'a un truc pour virer les gardes currentMachin, je suis preneur)

Je trouve le second carrément plus clair.

j'aime bien l'idée de alt d'utiliser hidden, mais ça fait trop de logique inversée à mon goût. Et pour séparer une fonction, il faut qu'elle porte son poids (ou être appelée plusieurs fois) là je pense qu'elle est trop légère.

de ce côté là, la solution d'alt est la plus sympa

Je ne suis pas d'accord avec ca. Notamment ca donne effectivement un peu plus de clarté à l'intention, mais ta fonction, de toute façon, elle va être inlinée, donc ca devrait rien changer au code produit.

 
Clairement elle est là pour rendre du code plus lisible. Si la condition n'était pas chères à évaluer, tu pourrais le faire dans une variable locale.