djano a écrit 1147 commentaires

Les interruptions associées au système audio ne requièrent plus le verrou noyau (Giant Lock).

Est ce que le systeme audio dispose de son propre lock a grain fin maintenant?
Cela m'etonnerait car il me semble que Theo de Raadt refusait l'abandon du Giant Lock car cela rendrait le code moins sur et plus difficile a auditer.

Si tu as une experience differente, ne te gene pas pour la partager.

De quelle optimisation parles-tu?

for() {if()…} -> if(){for()…}{for()…}
un peu de déroulage de boucle, etc…

"-XX:LoopUnrollLimit=n Unroll loop bodies with server compiler intermediate representation node count less than this value. The limit used by the server compiler is a function of this value, not the actual value. The default value varies with the platform on which the JVM is running."

Encore une fois, la JVM fait beaucoup plus d'optimisations que tu ne le penses.

réutiliser les objets au lieu de les oublier et en créer d'autre. En gros, faire en sorte de ne jamais faire de new en rythme de croisière.

Ca, c'est a toi de le faire.
J'ai deja vu du code comme ca, et je me suis demande si les gains etaient vraiment au RDV au final.

A propos de l'inline des getters/setters je n'y crois pas du tout

Je m'en fout pas mal de ton avis.

Ah oui je me rappelle de toi, tu es le gars qui se plaint sans arret que les perfs de Java sont a chier, mais qui refuse d'en apprendre plus sur le fonctionnement du langage et de la JVM.
Je te laisse troller tout seul alors.
Amuses toi bien.

Generics != templates

J parlais des templates pour faire echo a ce que tu disais sur les perfs.

Les generics en java donnent syntaxiquement quelque chose d'equivalent des templates C++, mais cela n'a rien a voir niveau perf. GCC est capable de triturer un template a tel point que ne subsistent que les instructions reelement utiles et les perfs sont bluffantes.

Je me demandais si le compilateur de Rust pouvait sortir des perfs aussi bonnes qu'avec les templates de C++.

Je suis d'accord.

C'est pour ca que la depeche sur Rust m'a beaucoup interesse avec la possiblite d'utiliser de n'utiliser le GC que lorsque l'on en a vraiment besoin.

Il manque juste un systeme equivalent aux templates dans Rust pour etre aussi performant que le C++.

Pour avoir jouer avec un IA en Java,

Qu'est ce qu'un IA?

Il n'y même pas de sortie de test des boucles

De quelle optimisation parles-tu?

ni d'inline des getter/setter.

A propos de l'inline des getters/setters je n'y crois pas du tout: http://blog.xebia.fr/2013/05/27/comprendre-le-fonctionnement-de-la-jvm-article-1/

Une methode static est bien plus rapide qu'une méthode virtuel normal.

A propos des methodes statics, je te crois sans peine, c'est toujours le plus rapide a appeler quel que soit le langage.

 

As-tu au moins laisser la JVM "chauffer" et trouver les methodes a inliner?

Ne me fais pas dire ce que je n'ai pas dit!
Je n'ai pas dit de créer plus de classes qu'il n'y en a besoin.

Hormis la gravité, il est également possible d'appliquer des forces, soit linéaire,s soit angulaires.

s/linéaire,s/linéaires,/

Et que tes composants sont tout petits, tu n'as pas peur d'avoir trop découpé ?

En programmation, plus les classes sont petites et cohésives et plus c'est facile a maintenir.
La dessus, la JVM (newton adventures est en java) a été beaucoup travaillée pour optimiser ce genre de code. Je ne sais pas si un compilateur C/C++ est capable d'avoir des optimisations aussi poussées dans de tel cas.

Une distrib stable et a jour?
Perso j'utilise Linux Mint, pour la stabilite ca va, mais je pense qu'il ne faut pas aller trop loin en terme de configuration ou de besoin avances.

Peut etre que les autres lecteurs peuvent te conseiller d'autres distrib?

Faire planter le noyau en affichant du texte, GG quand même. C’est le genre de trucs qui me donne une (très) petit aperçu de la complexité d’un noyau…

Boarf n'importe quelle application avec des algorithmes sophistiques en son sein peut planter de maniere aleatoire sous forte charge (certes les consequences sont moins grandes que pour un noyau).

Vu que toute application a vocation a devenir un bloatware, ca arrive assez souvent. Je ne te parle meme pas des applications d'entreprise qui par definition sont des bloatware.

unification des unit files (plutôt que d'avoir 36 variantes du script d'init pour un même logiciel, un par distrib'…)

Avec le bémol que la distribution la plus populaire n’a pas adopté systemd.

Tu es en train de sous entendre que c'est la faute a systemd. Trop gros passera pas.
Ca fait quand meme beaucoup de simplifications sur toutes les autres distribs qui ont adoptees systemd ou meme a l'interieur d'une seule distrib.

 

Ensuite, tes commentaires lies au fait que systemd marche pas sur fedora version x ou y dans tel cas ou tel autre, ca ressemble plus a se plaindre de l'implementation que de systemd lui-meme.
Ca me fait penser a pulseaudio dont tout le monde se plaignait au debut, mais qui finalement semble se faire sa place petit a petit.

Certes, c'est chiant, mais ca va se stabiliser.
Enfin, j'ajouterais que se plaindre que Fedora n'est pas stable sur telle ou telle config me fait me poser la question sur ton choix de distrib. Peut etre devrait tu changer de distrib pour une plus stable?

Ne riez pas : le service de déontologie du barreau de Paris est un "service certifié ISO 9001 par Bureau Veritas Certification". »

ISO 9001 ca veut tout dire et rien dire.

Vu que tu peux faire valider n'importe quel processus par ISO 9001, ca dit juste que si tu valides un processus de merde, tu es capable de reproduire la meme merde de maniere repetee et consistante au gramme pres. C'est donc une merde de qualite!

Merci beaucoup pour les blog posts sur le processus de conversion du jeu vers Android.
C'est tres interessant.

C'est référencé et sourcé sur Wikipedia en anglais: 90-90 rule

indispenables => indispensables

Moi aussi j'ai ete surpris par ce message d'erreur, mais je pense que c'est plus une question de finition qu'autre chose, d'ailleurs le message entre parentheses est moins barbare: "(expected &'static str but found integral variable)". En fait il detecte bien que c'est un entier.

Le ramasse-miette suffit dans beaucoup de cas, mais il apporte d'autres problemes tels que: avec un ramasse miette "stop-the-world", il est impossible de faire du temps reel ou de garantir un temps de reponse.

Et c'est un probleme qui grossit avec la taille de la memoire. Java a ces ennuis. Le ramasse-miette G1 etait sense apporter des solutions a ces problemes, mais ces promesses tardent a se materialiser. Plus recemment, j'ai vu la JVM Azul qui permet un passage a l'echelle du ramasse miette sur plusieus dizaines voire centaines de Go de memoire. Le mecanisme utilise (invalidation de pages memoire et mise a jour des references lors d'acces memoire vers les page invalidees) etant un brin avant gardiste, linux ne sais pas bien le gerer et ils ont cree un patch noyau hyper invasif qui ne sera jamais integre upstream tel quel. Il y a bien sur un gros surcout memoire pour cette fonctionnalite.

Le probleme du ramasse-miette dans Java et lie au fait que n'importe quel thread puisse voir absolumment toute la memoire du processus. Comme indique dans la depeche, Rust contourne ce probleme en:
1- fournissant et encourageant l'utilisation par defaut d'autres mecanisme de gestion de la memoire que le seul ramasse-miette
2- faisant en sorte que chaque thread ne puisse voir qu'une portion de la memoire qui lui est dediee, et pas celle des autres threads. D'ou l'absence du "stop-the-world". J'imagine qu'un cas pathologique pourrait etre equivalent a un stop the world (programme mono thread, uniquement code avec le ramasse-miette), mais je pense que les mecanismes mis en place devraient empecher pas mal de programmes d'en arriver la.

Ah? J'avais pas vu. Merci de ta precision.

Oui c'est tres utile: j'utilise beaucoup "final" en Java pour reperer facilement les declarations, mais c'est pas toujours genial genial, notamment si la variable est mutable :)

Hier, Linphone s'est enrichi d'un framework Web, disponible sous la forme d'un plugin NPAPI […]

Ca tombe bien, Google Chrome prévoit de supprimer la compatibilité NPAPI en 2014: http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Tu te rendras compte qu'avoir une dépendance JNI peut être fatale en terme de portabilité.

Pareil pour toute dépendance vers une librairie native pour Python, etc.

Tu verras peut-être des applications qui ont été conçues avec des dépendances sur des briques logicielles spécifiques à un serveur d'application JEE et qui ne pourront pas tourner sur un autre serveur JEE.

Pareil pour toute appli Python WSGI qui dépend de fonctionnalités non specificiées d'un serveur précis.

Tu verras peut-être qu'une librairie devra peut-être être intégrée de diverses manières dans différents contextes. Tu verras peut-être des librairies qui ne sont pas compatibles avec ton classpath alors qu'ailleurs ça aurait été comme sur des roulettes.

La gestion des dépendances en Python est pas connue pour etre super facile non plus.

 

J'ai utilisé l'exemple de Python, mais j'aurais pu parler de Ruby, etc.

Merci pour ta réponse.
Je n'ai pas encore essaye le navigateur d'Android 4, alors je ne peux pas comparer.

mais je ne trouve pas du tout ça pratique pour une navigation un peu intensive.

Ah bon? Quels problemes rencontres-tu?
Quels navigateur utilises-tu pour de la navigation intensive?
Est-ce que tu parles bien de navigation intensive sur mobile?

malgré que

Aïe! C'est un usage incorrect.
Il faut dire "bien que".

"Malgré" s'emploi sans le "que": "Malgré le mauvais temps, …"