Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
3533 connectés 

 


Sujet auquel vous répondez
Sujet : Les informaticiens aigris : anecdotes et conseils
rammstein

Vini a écrit :

J'ai ça sur une Smart TV achetée il y a quelques mois. Si la TV diffuse une image en 4K/HDR et que je veux changer la luminosité, j'ai besoin d'attendre 3 plombes que les super beaux menus se chargent sans compter ensuite la navigation dans les menus :sweat:


+1. Les TV intelligentes sont beaucoup plus longues à réagir que les TV basiques.
Sur ma Philips "haut de gamme" de 2010, le menu "Home" ne peut pas s’afficher pas dans les 5-10 premières secondes après allumage.
Sur ma SmartTV LG de 2016, si j'appuie sur un bouton dans les secondes suivant l'allumage, j'ai un beau message "SmartTV démarre" pour faire patienter. Il y a donc une magnifique évolution technologique entre les deux générations :D  
En même temps, quant je vois que les mises à jour de l'OS de ma TV prennent près de 600Mo (WebOS2), il doit y avoir du code à charger au démarrage et à chaque affichage :sweat:


Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion

jeffk a écrit :


 
C'est juste que l'open source ça avance pas et donc qu’aujourd’hui tu as une version qui date de ya 10 ans, donc fonctionne bien sur des SoC de 10 ans :o


 
Mais non voyons :o

jeffk
 
C'est juste que l'open source ça avance pas et donc qu’aujourd’hui tu as une version qui date de ya 10 ans, donc fonctionne bien sur des SoC de 10 ans :o

Non clairement pas mais c'est pourtant important la rétro compatibilité, sinon du matos encore viable fini à la poubelle car il n'est plus supporté
J'ai eu le cas avec mon iPad1, j'ai du le jeter car plus supporté et donc plus à jour et donc plus aucune apps installables alors qu'il fonctionnait encore parfaitement... Et impossible de le passer sous un andoid par exemple :'(. Avoue que c'est débile. Ce problème est typique sur les solutions proprio de toute façon, en opensource, même un vieux soc d'il y a 10 ans, tu sais l'utiliser actuellement.
jeffk

 

Ca fait le bonheur des constructeurs oui peut être. Mais c'est pas les constructeurs qui incitent les équipes de dev à coder avec les pieds.

 

C'est surtout les devs qui vont se dire "osef on prendra plus puissant pour compenser"

 

Moi je trouve - peut être à tort - que depuis quelques temps ça revient dans la bon sens. Pas forcement sur les TV, mais quand tu vois que les app mobiles sont benché, que les sites sont benché et donc plus ou moins bien classés selon ça, ça incite fortement à pas faire de la merde.

jeffk a écrit :


 
Bah le SoC, l’électronique, la puce (les puces) what ever qu'il y a dans la Télé.
 
J'ai un ST50 ça ram pas du tout, tu prends celle d'après sur Firefox OS tu te tire une balle.


 
Mwai, je ne vais pas défendre le hardware, mais quand tu codes pour une config light, tu adaptes ton code, tu vires ce qui ne sert à rien et au niveau interface, tu adaptes pour la rendre fluide...
 
Qui a besoin de transparence sur sa TV si c'est pour mettre 5 seconde pour afficher un menu ?


C'est aussi qu'a un moment, tu peut pas te te traîner éternellement du code pour assurer la rétro compatibilité.

duckxks a écrit :


C'est tout un écosystème pour le mal codé. Ca fait le bonheur des constructeurs de matos (PC / téléphone). Ha grace à cette nouveauté, ça rame beaucoup moins, tout le monde et content et on rempile du crados que la prochaine génération rendre à nouveau fluide  [:barthaliastoxik]  
 
Il n'y a qu'à voir un certain de nombre de pages web qui arrivent à mettre à toc le CPU.


 
Clairement, c'est aussi une non volonté d'optimiser pour vendre le nouveau modèle plus puissant.
Quand on voit ce que l'on peut faire tourner sur des config ridiculement faible une fois le code optimisé on comprend que l'iPhone 3 qui est déclaré obsolète pas Apple c'est juste marketing :/.

jeffk
 
Bah le SoC, l’électronique, la/les puce what ever qu'il y a dans la Télé.
 
J'ai un ST50 ça ram pas du tout, tu prends celle d'après sur Firefox OS tu te tire une balle.
 
edit : j'étais resté sur les TV :o
jeffk

duckxks a écrit :


C'est tout un écosystème pour le mal codé. Ca fait le bonheur des constructeurs de matos (PC / téléphone). Ha grace à cette nouveauté, ça rame beaucoup moins, tout le monde et content et on rempile du crados que la prochaine génération rendre à nouveau fluide  [:barthaliastoxik]  
 
Il n'y a qu'à voir un certain de nombre de pages web qui arrivent à mettre à toc le CPU.


 
D'où le fait que Google les références moins bien. On est là dessus au taff sur certains de nos sites. L'optimisation au ms près c'est lourdingue :D

jeffk a écrit :


 
Ou peut être le "CPU" à la rue ?


 
CPU ?

duckxks
C'est tout un écosystème pour le mal codé. Ca fait le bonheur des constructeurs de matos (PC / téléphone). Ha grace à cette nouveauté, ça rame beaucoup moins, tout le monde et content et on rempile du crados que la prochaine génération rendre à nouveau fluide  [:barthaliastoxik]  
 
Il n'y a qu'à voir un certain de nombre de pages web qui arrivent à mettre à toc le CPU.
jeffk
 
Ou peut être le "CPU" à la rue ?
C'est surtout un soucis de dev derrière :(.
 
Actuellement, avec le tout connecté, on torche le dev et on met sur le marché du matos avec du soft mal testé et non fini qui sera patché si suffisamment de clients gueulent. C'est exactement pareil avec Win10, cet OS est sorti alors qu'il n'était clairement pas prêt et durant la première année il à été patché dans tous les sens pour avoir un truc à peu prêt potable un an après... C'est pareil pour les jeux, on sort un jeu ultra bogué et il sera mis à jour au fur et à mesure pour le rendre jouable...
 
On ne laisse clairement plus assez de temps aux équipes de dev pour tester et retoucher le code. Résultat on bâcle le travail et on met sur le marché du matos qui ne devrait jamais avoir passé la case test. Payer des gens pour auditer du code c'est hors de prix, alors on radine et on laisse passer des énormités avec des bugs et des failles gigantesques :/.
nucl3arfl0

Sylver--- a écrit :

/my2cents (j'encadre des devs java toute la journée) (oui je sais, mais au moins c'est pas du windev :o)

 

- y'a quand même un très (très) gros paquet de dev pour qui c'est juste le taff, donc ils ne se formeront jamais tout seul, ne lisent pas de blogpost, ne suivent pas l'actu, ne testent pas de nouveaux langages... etc. Ils font leur taff et c'est tout. Alors que vous comparez à une époque où tous les devs étaient des passionés :o
- pour rejoindre les propos de je-sais-plus-qui au dessus, on ne fait pas d'optimisation car globalement cela coûte très cher (bench/test/rebench/retest, à ~700€/jr/pers...). Les devs devs, tu fais 2-3 benchs pour vérifier que ça parte pas en couille et tu ship pour les tests. Si les tests remontent des problèmes, là tu corriges, sinon ça passe :o Dans mon ancienne (grossse) boîte, tous les tomcats étaient redémarrés toutes les nuits, cela réduisait considérablement les problèmes de mémoire :D
- vu que la majorité des boîtes passent par de la presta (Orange typiquement pour leur box), un "ingé" dev leur coûte à la grosse louche 12-15k€/mois. Donc à ce prix là, faut faire tout le plus vite possible. Ils feraient leur dev en interne où ça coûterait 3x/moins... bah soient ils pourraient n'avoir que des seniors, soit y passer plus temps, plus de tests, plus de benchs, etc...

 

Voilà voilà :o


Et c'est pas prêt de s'arranger, car les framework force l'abstraction, les gens appliquent sans chercher à comprendre. Il y a plein de tutoriaux sur le net, plein d'exemple sur stackoverflow.com.
Les dev que j'ai encadré, au moindre problème, c'est Google -> SO, et hop copié collé.
Se posent même pas la question du code collé, ce qu'il fait, s'il est adapté, etc.
J'ai trouvé du copié collé avec des parties de code qui étaient vide ou qui n'avait aucun sens pour le projet. Et là t'as vraiment envie de mettre des coups de boule.
L'expertise en développement est mal reconnue en France, sous prétexte que le neveu du DG peut faire aussi bien durant son stage grâce aux tutoriels.
Maintenant la mentalité c'est que n'importe qui peut pisser du code.
Oui, mais quel code  [:spawn_cqn:4]

jeffk Bien choisir sa TV sinon  [:a03hegaz]

Vini a écrit :

J'ai ça sur une Smart TV achetée il y a quelques mois. Si la TV diffuse une image en 4K/HDR et que je veux changer la luminosité, j'ai besoin d'attendre 3 plombes que les super beaux menus se chargent sans compter ensuite la navigation dans les menus :sweat:


Tu peux pas test, pour vendre un smart tv il faut un menu en transparence sinon c'est pas joli pour le consommateur :o
De toute façon les smart tv c'est de la daube, une RPI sous Kodi et roulaiz !

Devil'sTiger En dehors de ca, simplement Java vs C++ et tu perds déjà un max de perf sous Java...
 
Un jour, en sortant de 2 ans de python, j'ai fait un projet C++, j'ai été étonné que le projet crash après 30 secondes, sachant que 1 secondes c'était quelques millions de valeurs... Le même projet en python ca aurait donné quelques centaines de milliers au mieux, et j'aurais vu des ralentissement dès les 5 premières secondes...
 
Sylver--- /my2cents (j'encadre des devs java toute la journée) (oui je sais, mais au moins c'est pas du windev :o)
 
- y'a quand même un très (très) gros paquet de dev pour qui c'est juste le taff, donc ils ne se formeront jamais tout seul, ne lisent pas de blogpost, ne suivent pas l'actu, ne testent pas de nouveaux langages... etc. Ils font leur taff et c'est tout. Alors que vous comparez à une époque où tous les devs étaient des passionés :o
- pour rejoindre les propos de je-sais-plus-qui au dessus, on ne fait pas d'optimisation car globalement cela coûte très cher (bench/test/rebench/retest, à ~700€/jr/pers...). Les devs devs, tu fais 2-3 benchs pour vérifier que ça parte pas en couille et tu ship pour les tests. Si les tests remontent des problèmes, là tu corriges, sinon ça passe :o Dans mon ancienne (grossse) boîte, tous les tomcats étaient redémarrés toutes les nuits, cela réduisait considérablement les problèmes de mémoire :D
- vu que la majorité des boîtes passent par de la presta (Orange typiquement pour leur box), un "ingé" dev leur coûte à la grosse louche 12-15k€/mois. Donc à ce prix là, faut faire tout le plus vite possible. Ils feraient leur dev en interne où ça coûterait 3x/moins... bah soient ils pourraient n'avoir que des seniors, soit y passer plus temps, plus de tests, plus de benchs, etc...
 
Voilà voilà :o
HumanRAGE

HumanRAGE a écrit :

en win2012R2 l'onglet "partage NFS" qui n'est dispo que sur le disque systeme, mais pas le disque RAID de data, ca parle a quelqu'un ? :D


https://social.technet.microsoft.co [...] server8gen
ok le disque de data est en ReFS, et c'est pas compatible NFS  [:dur]  [:dur]  [:dur]  [:dur]

nucl3arfl0 Non mais quand on voit les usines à gaz des ORMs et que les gens ne cherchent pas à comprendre comment ça marche, ça pisse des requêtes dans tous les sens, ça fait des transactions de débile qui lockent limite toutes les tables et s'étonnent ensuite que ça "rame".
Et pour couronner le tout, ah ben on va upgrader le serveur, alors que le bouzin c'est déjà une config de ouf.

 

Les mecs ils veulent un serveur SQL dédié pour leur application à la con tellement que c'est pissé avec les pieds et les lunettes de Gilbert Montagné.

 

Mais ça ne se pose pas de question sur comment bien utiliser le framework, voir optimiser certaines choses. Non, ça marche, c'est tout.  [:hank hullet-derire]

HumanRAGE en win2012R2 l'onglet "partage NFS" qui n'est dispo que sur le disque systeme, mais pas le disque RAID de data, ca parle a quelqu'un ? :D
antp

giorkal a écrit :


1) le dev et une grosse part des tests sont fait sur des machines bien plus puissantes . des PC xeons avec simulateurs.
et tout a la fin seulement on teste sur la box, mais c'est trop tard pour changer si c'est trop lent


à mon boulot vers 2010-2011 je testais mon soft client/serveur (fait en C#/.NET) sur un PIII 650 MHz, et la DB SQL Server était sur un autre PC identique, chacun avec 512 Mo de RAM, les perfs étaient encore correctes ; quand le client demandait si comme serveur dédié son Xeon tout neuf avec des gigas de RAM allait suffire je pouvais sans risque lui dire que oui [:ddr555]
Une des autres machines de test quelques années plus tard était un vieux Laptop sous Vista.
Et pour vérifier que le truc restait utilisable lorsqu'il était accédé via internet ou un réseau un peu lent, j'avais testé en me connectant à notre propre serveur avec un vieux laptop XP et un modem 56k sur la ligne du fax, ça marchait encore pas trop mal [:dawa] (là encore, pourtant écrit en C#/.NET,)

DrDooM

Slyde a écrit :

On est de toute façon globalement pas develos sur ce topic.

 

(moi de formation si [:tinostar]²²)


 [:hoo:1]

nucl3arfl0 Très occasionnellement sur des outils internes pour le SI, mais sinon non terminé (j'étais en R&D).
Vais passer RSI, ça sera plus intéressant, ça va me faire du bien de changer un peu.
Et puis marre de me coltiner des quiches. Là j'aurai mon autonomie, bon restera les lusers..
caudacien

Slyde a écrit :

On est de toute façon globalement pas develos sur ce topic.
 
(moi de formation si [:tinostar]²²)


D'ou ta passion pour le debug de matériel russe exploités par du code kazakh :D

nucl3arfl0 a écrit :

Bah si mais je vais changer de poste.


Toujours pour faire du dev?

nucl3arfl0 Bah si mais je vais changer de poste.
Slyde On est de toute façon globalement pas develos sur ce topic.
 
(moi de formation si [:tinostar]²²)
docmaboul Oui, oui. N'empêche que ta remarque était un peu pourrie. Et ta réponse aussi du coup.
 
Pour votre débat, je suis dubitatif. Disons que j'ai un peu de mal avec l'idée qu'il faille nécessairement aborder la programmation avec un seul langage et qu'il y en aurait un qui serait supérieur aux autres à cette fin. Je trouve très bien d'étudier un langage proche de la machine et de l'OS, qui permette de bien comprendre comment les choses sont faites à ce niveau, surtout si ça s'articule avec des principes et notions qu'on aborde dans d'autres cours. Ca n'empêche pas d'étudier un autre langage beaucoup plus fonctionnel et débarrassé de ce genre de considérations, avec lequel on va pouvoir être plus productif.
DDT

docmaboul a écrit :


 
Parce que malloc, c'est généralement du runtime de ton compilateur et son implémentation dépend de celui-ci. Ta phrase revenait à dire: "je sais exactement quelle taille fait un long". Ca dépend surtout de ton compilateur et de ta plateforme. Tu prends VC par exemple, malloc est juste un wrapper de l'appel système HeapAlloc. En OpenSource, tu as une dizaine d'implémentations différentes. Du coup, je me demandais ce que tu mettais derrière tout ça. Je m'attendais à quelque chose d'un peu plus évolué que "malloc demande de la mémoire au système". C'est sûr que vu sous cet angle, c'est pas très compliqué et toujours pareil :o  
 
/ [:mike hoksbiger]


Remets ma remarque dans le contexte.
Bien sûr que l'implémentation exacte utilisé par ta plateforme et ta libc varie, mais ça change pas grand chose au concept qui dépend de deux choses:
1. Le noyau et ses appels systèmes pour demander plus de mémoire.
2. La stratégie d'allocation.
 
Et je critiquais la pertinence du conseil "il faut commencer en C et savoir comment malloc fonctionne" car le point 1. tu le vois en cours de systèmes d'exploitation et çe ne fait pas de toi un bon ou un mauvais programmeur, et le point 2. c'est un problème d'algo qui n'a rien de spécifique à malloc.

gamer-fou 4) https://www.youtube.com/watch?v=XoD [...] e=youtu.be
caudacien Dev fait à la va super vite. On s'en fout que ca soit optimisé, du moment que ca soit vaguement utilisable et qu'on peut vendre ca vite :D
 
Puis on laisse 2/3 gus qui ont lu un bouquin "j'apprend à coder en java en 2 mois en bossant 1H par jour tous les soirs" gérer la maintenance/mise à jour [:spamafote]
giorkal

XaTriX a écrit :


Putain mais les box tvs des fai sont des merdes ambulantes, comment on peut faire ça :fou: Et surtout y'a personne qui teste et qui dit "euh mais ça pue la" ?  
 
XaT


quelques pistes possibles  
0) la bureaucratie lourde et crasse ...  
 
1) le dev et une grosse part des tests sont fait sur des machines bien plus puissantes . des PC xeons avec simulateurs.
et tout a la fin seulement on teste sur la box, mais c'est trop tard pour changer si c'est trop lent  
 
2) on ne teste que sur les toutes dernieres box qui ont (peut etre) des  processeurs plus puissants  
 
3) on a testé la reactivté sur la 1ere livraison quand la box est sortie . C'etait ok . Mais depuis on a rajouté des trucs et des trucs mais on n'a jamais reverifié la reactivité des premieres box.

XaTriX a écrit :

Je dirais plutôt que c'est la moins pire :o
 
XaT


+ 1
 
D'ailleurs, j'ai dégager ma box. Ma shield TV fait bien mieux le taf, Molotov même si imparfait sera bien suffisant pour mon utilisation de la TV.

XaTriX Je dirais plutôt que c'est la moins pire :o
 
XaT
MsieurDams Je vais faire mon fanboï de base mais la freebox revolution reste toujours dans les plus réactives de toutes. Par contre la 4K sous androidTV  [:pouahbeurk]
XaTriX

HumanRAGE a écrit :

c'est devenu impossible de micromanager ton code et son execution, ca revient a travailler contre la machine...
 
il faut maintenant optimiser la lisibilité du code en le balisant pour que le compilo streamline bien les instructions, afin que les processeurs puissent déployer tout leurs trucs et astuces pour optimiser leur fonctionnement.
 
pour des manips gourmandes en calcul, on peut toujours optimiser aux ptits oignons et detecter le cpu soi meme pour les parties critiques, mais l'immense majorité du code va rester objets et bibliotheques, et donc une enorme perte de ressources lors des communications entre ces threads, process, modules et autres objets.
 
c'est comme ca qu'on en arrive aujourd'hui a avoir une reactivité honteuse sur une teloche ou un decodeur tv, alors que le proc' embarqué est genre 100 fois plus puissant qu'un 68k des années 80 et que l'interface est bidon au dernier degré... ca devrait etre instantané comme un menu de jeu SuperNes :pfff:
 
 
/vieuxcon [:littlebill]


Putain mais les box tvs des fai sont des merdes ambulantes, comment on peut faire ça :fou: Et surtout y'a personne qui teste et qui dit "euh mais ça pue la" ?  
 
XaT

nucl3arfl0 Voilà, j'allais le dire.
C'est lent surtout parce que c'est codé avec les pieds, faut pas déconner non plus.
MsieurDams

 

Samsung plutôt. Plus codé avec le cul tu meurs.

rammstein

Vini a écrit :

J'ai ça sur une Smart TV achetée il y a quelques mois. Si la TV diffuse une image en 4K/HDR et que je veux changer la luminosité, j'ai besoin d'attendre 3 plombes que les super beaux menus se chargent sans compter ensuite la navigation dans les menus :sweat:


+1. Les TV intelligentes sont beaucoup plus longues à réagir que les TV basiques.
Sur ma Philips "haut de gamme" de 2010, le menu "Home" ne peut pas s’afficher pas dans les 5-10 premières secondes après allumage.
Sur ma SmartTV LG de 2016, si j'appuie sur un bouton dans les secondes suivant l'allumage, j'ai un beau message "SmartTV démarre" pour faire patienter. Il y a donc une magnifique évolution technologique entre les deux générations :D  
En même temps, quant je vois que les mises à jour de l'OS de ma TV prennent près de 600Mo (WebOS2), il doit y avoir du code à charger au démarrage et à chaque affichage :sweat:

Vini


Même pas :D Mais je pense que ça doit être commun à plusieurs marques. Faire de beaux menus avec des animations ça coûte, alors si en plus la TV est en train de faire du traitement d'image  [:chevreuil_npa:3]

docmaboul

DDT a écrit :

Qu'est-ce que tu veux savoir?
L'interface de malloc/calloc/realloc en C est pas super compliquée. Tu demandes de la mémoire et tu reçois un pointeur si ça marche, null sinon.
 
Niveau implémentation, malloc va tenter de faire grossir le tas du processus (appel système brk) pour allouer l'espace demandé.
Si c'est pas possible tu peux demander au noyau des nouvelles pages mémoire avec mmap.
La partie compliquée de malloc c'est l'algorithme de gestion des zones occupées/libres de manière compacte en évitant trop de fragmentation.
C'est un problème similaire au sac à dos donc c'est NP-complet si je dis pas de bêtises. :D  
 
Ensuite mmap c'est quelques milliers de ligne de C quand même, ça commence à être un peu complexe.
Mais la gestion des caches et de la mémoire, que ce soit côté hardware ou du noyau, c'est pas super compliqué, juste très chiant.
Edit: Mais tu sais tout ça apparemment. :o Pourquoi tu demandes?
 
Perso ça m'intéresse pas du tout, ce qui m'intéresse c'est surtout les bonnes pratiques avec du matériel récent et les langages que j'utilise.
Par exemple l'allocation (plus ou moins) explicite sur la pile est un concept qui est revenu au goût du jour à cause des latences mémoires qui deviennent relativement de plus en plus coûteuses en terme de cycles CPU, d'où l'explosion de la taille des caches et la multiplication des niveaux (on est au L4) comparée à il y a 20 ans.
Et pour comprendre tout ça, malloc et l'arithmétique sur les pointeurs me font une belle jambe. :o


 
Parce que malloc, c'est généralement du runtime de ton compilateur et son implémentation dépend de celui-ci. Ta phrase revenait à dire: "je sais exactement quelle taille fait un long". Ca dépend surtout de ton compilateur et de ta plateforme. Tu prends VC par exemple, malloc est juste un wrapper de l'appel système HeapAlloc. En OpenSource, tu as une dizaine d'implémentations différentes. Du coup, je me demandais ce que tu mettais derrière tout ça. Je m'attendais à quelque chose d'un peu plus évolué que "malloc demande de la mémoire au système". C'est sûr que vu sous cet angle, c'est pas très compliqué et toujours pareil :o  
 
/ [:mike hoksbiger]


Copyright © 1997-2025 Groupe LDLC (Signaler un contenu illicite / Données personnelles)