Plus récemment, ce même Mike Galbraith a proposé un patch sur la LKML le 19 octobre 2010 pour regrouper automatiquement les tâches par terminal (TTY). Suite aux critiques d'autres développeurs, il a écrit une deuxième, puis une troisième version de son patch. Linus en personne s'est réjoui qu'un si petit patch, non intrusif, soit capable d'améliorer autant l'interactivité. Le lendemain, un article paru sur Phoronix montre en vidéo le gain notable en utilisant un cas de test similaire à celui de Linus : lancer une compilation du noyau avec make -j64 (lance 64 tâches de compilation en parallèle) dans un terminal, tout en utilisant un bureau : navigateur web et lecture de vidéo en HD.
Le patch améliore l'interactivité en distribuant le temps de processeur plus équitablement du point de vue de l'utilisateur. Il utilise les cgroups (groupe de tâches) introduits dans le noyau 2.6.24 (janvier 2008) pour l'ordonnanceur CFS. CFS permet de définir le pourcentage de temps assigné à un cgroup. Cette fonctionnalité révolutionnaire a été un peu oubliée car la création des cgroup était manuelle. Le patch de Mike propose de créer automatiquement un cgroup par TTY, et permet donc de mettre en application simplement le travail sur CFS et les cgroups. Con Kolivas a néanmoins critiqué le patch sur son blog en expliquant qu'il introduit des régressions dans les cas d'utilisation « normaux ».
Proposé après la fenêtre de tir du noyau 2.6.37, l'avenir nous dira si ce patch va être intégré ou non dans le noyau 2.6.38. Plus généralement, ces différents projets devraient à terme améliorer la réactivité de nos environnements de bureaux sous Linux.
NdM : Merci à Poloh d'avoir proposé une dépêche sur le même sujet et insert_coincoin pour son journal en lien ci-dessous.
Aller plus loin
- [RFC/RFT PATCH] sched: automated per tty task groups (20 clics)
- Documentation sur les cgroups (17 clics)
- Article Phoronix démontrant le gain de réactivité à l'aide du patch (15 clics)
- Réaction de Linus au patch de Mike Galbraith (10 clics)
- Les critiques de Con Kolivas (7 clics)
- Journal DLFP traitant de ce patch (44 clics)
# Utiliser les tty
Posté par JGO . Évalué à 2.
2) Si la réponse à la 1) est oui, et sachant que les terminaux sont souvent en frame-buffer, leur mise à jour est typiquement plus lente que sur xterm. Ne va-t-on pas perdre en performances pour les processus donnant beaucoup de lignes d'affichages (typiquement le cas d'une compilation avec les autotools), à moins de rediriger la sortie (soit vers un fichier qui peut grossir de façon incontrôlée, soit vers /dev/null et perdre des informations) ?
[^] # Re: Utiliser les tty
Posté par Xaapyks . Évalué à 5.
[^] # Re: Utiliser les tty
Posté par O'neam Anne . Évalué à 3.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Utiliser les tty
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utiliser les tty
Posté par JGO . Évalué à 2.
Après http://www.youtube.com/watch?v=prxInRdaNfc
[^] # Re: Utiliser les tty
Posté par Ontologia (site web personnel) . Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 0.
Question qui fache: j'ai jamais observe ca sous windows pu mac, comment ils font eux?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par daimrod . Évalué à 3.
Oo
Tu n'as jamais vu des trainées toutes moches quand tu manipulais des fenêtres windows ?
Parce que c'est quand même pas rare d'avoir des bugs graphiques sous windows lorsqu'on bouge des fenêtres et que des softs un peu lourd, genre firefox et eclispe.
D'ailleurs, c'est un autre avantage des tiling wm, on ne touche pas aux fenêtres. :D
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 4.
Sur mac, avec une très très grosse charge, le contenu de la fenêtre peut être remplacé par du blanc, et ça lag pas mal.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par Samuel Thibault (site web personnel) . Évalué à 9.
bidule branché sur ton PC, qui a son propre écran et clavier).
La console virtuelle linux (aka VC, VT, "ctrl-alt-f1", ...), du point
de vue de la couche tty du noyau, c'est du pareil au même qu'un xterm.
Là où ça ne fonctionne pas, son patch, c'est que les utilisateurs
normaux n'utilisent pas de tty...
[^] # Re: Utiliser les tty
Posté par Kerro . Évalué à 10.
C'pas grave : les utilisateurs normaux n'ont pas Linux. :-)
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 6.
[^] # Re: Utiliser les tty
Posté par Sylvain Sauvage . Évalué à 7.
[^] # Re: Utiliser les tty
Posté par Florian.J . Évalué à 3.
Qu'il soit graphique ou non n'y change rien.
[^] # Re: Utiliser les tty
Posté par riba . Évalué à 5.
Il ne les reçoit pas, il les hérite de son père, qui , lui, les a créé et ouvert.
ils ne peut pas y couper,
?
pid = fork ();
if ( pid == 0 ) {
close(0),close(1),close(2);
execvp ( cmd[0], cmd );
} else ...
et oui, c'est utilisé en prod, et ça a certains avantages (certes, printf() échoue...).
[^] # Re: Utiliser les tty
Posté par fearan . Évalué à 6.
if ( pid == 0 ) {
close(0),close(1),close(2);
execvp ( cmd[0], cmd );
Ils les a reçu, il les ferme, mais il les a reçu.
execvp ne crée pas un processus, il le remplace.
ps: il se passe quoi si execvp échoue ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Utiliser les tty
Posté par Moonz . Évalué à 1.
if(fork()==0) {
close(0);close(1);close(2);
if(fork()==0) {
// et hop, un processus créé sans descripteurs
}
}
[^] # Re: Utiliser les tty
Posté par fearan . Évalué à 2.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Utiliser les tty
Posté par riba . Évalué à 3.
J'ai pas fait "close(0),close(1),close(2);" avant fork(), histoire que le process principal puisse encore s'exprimer :-) mais c'est bien sûr possible! (et si le fils fait fork() c'est le cas).
ps: il se passe quoi si execvp échoue ?
Le vrai code teste tout, y compris close(). Je ne vois pas l'intérêt de poster du vrai code ici, c'est trop chiant à lire.
[^] # Re: Utiliser les tty
Posté par JGO . Évalué à 2.
[^] # Re: Utiliser les tty
Posté par Moonz . Évalué à 5.
Si je ne m’abuse, c’est ce que fait crond par exemple.
[^] # Re: Utiliser les tty
Posté par Antoine . Évalué à 2.
(*) Voir une implémentation Python dans le module standard getpass :
http://code.python.org/hg/branches/py3k/file/tip/Lib/getpass(...)
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 2.
(en tout cas c'est le comportement de cron sur les différentes distributions que j'ai déjà utilisé)
[^] # Re: Utiliser les tty
Posté par fearan . Évalué à 0.
(tout comme ceux qui prétendent le coté hautement prédictif et uniforme de == en java)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 2.
Je crois que c'est assez bien spécifié comme dans n'importe quel langage. Si tu supposes plus que la spécification alors c'est un PEBKAC comme dans n'importe quel langage.
[^] # Re: Utiliser les tty
Posté par fearan . Évalué à -2.
Petit morceau de code très amusant :) :
Integer a = new Integer(126);
Integer b = new Integer(126);
System.out.println( a++ == b++ );
System.out.println( a++ == b++ );
System.out.println( a++ == b++ );
System.out.println( a++ == b++ );
qu'a t on comme résultat ?
Oui, utiliser == sur les Integer c'est mal, faut utiliser equals
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 10.
1- Quand tu fais un new tu obtiens *toujours* un objet différent
System.out.println(new Integer(12) == new Integer(12)); => false2- Quand tu fais System.out.println(a++ == b++) tu ne fais pas du *tout* ce que tu penses. Tu ne comprends donc pas le mécanisme d'autoboxing de Java
Integer a = new Integer(12); a++Ca donne en Francais.
Pars d'un Integer, convertis le en int, ajoute lui un, convertis en Integer
Soit en bytecode:
0 new java.lang.Integer [16]
3 dup
4 bipush 12
6 invokespecial java.lang.Integer(int) [18]
9 astore_1 [a]
10 aload_1 [a]
11 invokevirtual java.lang.Integer.intValue() : int [21]
14 iconst_1
15 iadd
16 invokestatic java.lang.Integer.valueOf(int) : java.lang.Integer [25]
19 astore_1 [a]
3- Les versions objet des types primitif en Java sont immutable.
4- Il en découle que a n'est évidement plus le même objet quand tu fais ton a++. Il s'agit d'un nouvel objet créer par le valueOf
5- Rien n'empeche le valueOf d'optimiser ce qu'il retourne comme il le veut. La spec dit:
The result is an Integer object that represents the integer value specified by the string.
6- Pour optimiser la consommation mémoire, valueOf() utilise un cache d'entier pour certaines valeurs:
private static class IntegerCache {
private IntegerCache(){}
static final Integer cache[] = new Integer[-(-128) + 127 + 1];
static {
for(int i = 0; i < cache.length; i++)
cache[i] = new Integer(i - 128);
}
}
Bref la spec est entièrement cohérente et chaque fonctionnalité est orthogonale. Certains ne comprennent pas les mécanismes de base comme l'autoboxing ou les specs de certaines méthodes, c'est leur problème. Faut arrêter de cracher sur les technos par ce qu'on est pas compétent dessus... Java comme n'importe quel autre langage à des spécifications. Soit on code à l'arrache de manière empirique; soit on lit les specs et on comprend comment ca marche.
PS: Fait attention la JVM optimise aussi les strings. "toto" n'est pas du tout la même chose de new String("toto"). L'un te garanti l'unicité de l'objet pas l'autre.
[^] # Re: Utiliser les tty
Posté par Antoine . Évalué à 8.
Y a des spécifications mieux fichues que d'autres. Ton explication laisse clairement penser que Java est une merde de complexité byzantine (ce qui permettrait aux "experts" de vendre assez cher leur compétence sur le marché).
[^] # Re: Utiliser les tty
Posté par LeMagicien Garcimore . Évalué à 8.
le résultat d'un new c'est une reference (~= un pointeur). Faire un == entre deux références ça compare la valeur de la reference (~= l'adresse de l'objet), pas sa valeur.
Je vois pas ce qu'il y a de complexité byzantine la dedans, c'est pas plus complique que C (est bien plus simple que C++). Toute manipulation d'objet se fait par référence. Période.
[^] # Re: Utiliser les tty
Posté par briaeros007 . Évalué à 4.
Et donc comment savoir lequel est utilisé ?
Au moins en C ou en C++ c'est clair quand tu utilise un pointeur ou quand tu utilise un objet en tant que tel.
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 1.
[^] # Re: Utiliser les tty
Posté par Sylvain Sauvage . Évalué à 4.
L’auto-encapsulage et l’auto-désencapsulage permettent juste de faire
Integer io = 12;
int ip = io + 1;
io = ip - 2;
au lieu de
Integer io = new Integer(12);
int ip = io.intValue() + 1;
io = new Integer(ip - 2);
Ils ne changent pas le type de ta variable ; ils ne changent pas le comportement.
[^] # Re: Utiliser les tty
Posté par fearan . Évalué à 2.
et que si on était pas passé par new, le premier aussi aurait renvoyé true aussi; par contre les deux autres, a moins de changer les paramètre de la jvm, renvoient false.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 6.
Après tu penses ce que tu veux, et si t'as envie de t'autopersuader libre à toi. Mais puisqu'on est dans les avis à 3 sous, le mien c'est que pour trouver ca compliqué t'as pas du lire beaucoup de specs et ni essayé de décortiquer beaucoup de bout de code.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 1.
Bon, évidemment, faire un truc tel que (a == b) serait équivalent à (a.equals(b)) poserait aussi le problème pour un "débutant" qu'on aurait pas forcément (a == b) équivalent à (b == a)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 3.
La au moins, c'est tres explcite et coherent avec la philosophie objet. == ca sert pour la tambouille technique interne, si tu veux utiliser la semantique objet, tu passes par des methodes.
Derniere chose:
package com.maboite.monprojet;
public class Integer{
// plein de truc super baleze parce qu'on a du faire une classe integer a nous
}
plus loin:
// collapse par tout ide decent
import com.maboite.monprojet;
// un 20aine d'autres import
// 400 lignes de code
public void maSuperMethod(Integer a, Integer b){
if(a == b){
// a ben merde, c'est quoi la? egalite de pointeur ou de valeur?
}
}
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 2.
Dans ce cas, je cite mon commentaire
je ne suis pas contre une méthode ou un opérateur permettant de récupérer la même chose que le (a == b) actuel
Et pour ton exemple plus bas, justement, j'aurais préféré que ce soit partout un == de valeur, pas de pointeur. Donc évidemment java ne peut pas évoluer dans ce sens (trop d'héritage existant, étant donné que c'est ce qui existe depuis le début)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 4.
On peux donc faire des choses telle que *a == *b, ou même a == b si il s'agit de références. Et même avec des string (foo non ?).
Je ne vois pas ce qui a poussé les ingénieurs qui ont créé java à ne pas utiliser la collection des méthodes «operatorBidule» comme en C++.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 2.
Probablement la lisibilite du code.
Ton a == b, en le lisant t'as aucune idee de ce qu'il va appeler . Un exemple?
public class Foo{
private Bar* bar;
private Bar* bar2;
// 500 lignes de code
private void FooBar(){
if(bar == bar2){
}
}
D'une part, tu ne sais pas ici ce que fait ==, a moins d'aller farfouiller les definitions. Ca c'est le probleme de la surcharge d'operateur, t'as un truc qui s'appelle ==, qui est en fait une methode, mais t'as pas la moindre idee de ce que la methode fait parce qu'elle a pas de nom.
Remplace == par a.egaliteDePointeurOuPasCaDepend(b) c'est strictement la meme chose.
D'autre part, supprimes la surcharge de == et paf, t'as pete tout ton code silencieusement. Bon courage pour corriger tout ca.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 3.
En plus, ton opérateur surchargé == pourrait ne plus marcher parce que tu l'auras supprimé, alors que quand tu supprimes ton equals() tout continue sans que ça pète silencieusement.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
== ca peut etre une egalite de pointeur ou de valeur, t'en sais rien.
Le probleme c'est pas le nombre de caracter ou quoi, c'est que le meme symbole represente deux chose pourtant opposees.
Quand a supprimer equals de ta classe, au moins t'es capable de retrouver simplement ou elle est appeller.
Pour == au mieux, tu peux faire une recherche texte sur ==, et ensuite fouiner dans les 2500 resultats.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par claudex . Évalué à 8.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 3.
C'est pareil pour les passages de paramètres dans les méthodes, le passage est par valeur, c'est pour ça que si tu passe un objet, tu peux modifier l'objet (s'il n'est pas immuable), mais pas le faire pointer vers un autre pour l'appelant.
[^] # Re: Utiliser les tty
Posté par briaeros007 . Évalué à 3.
a == b me compare quoi ?
(autoboxing toussa )
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 4.
http://java.sun.com/docs/books/jls/third_edition/html/expres(...)
on est dans le cas où un des opérandes est numérique (int b) et l'autre est convertible en numérique (Integer a), d'après
http://java.sun.com/docs/books/jls/third_edition/html/conver(...)
donc un unboxing est fait sur a (a.intValue()) puis, comme les deux sont des entiers, une comparaisons entre nombres entiers est effectuée.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 4.
Pour trouver equals, tu fais comment ? Tu cherches dans les 2500 résultat de ta recherche de equals ? Non parce que si ton ide est capable de te trouver tout tes type1.equals(typeX), il est aussi capable de te trouver tout tes (type1 == typeX)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 2.
Ok, donc au final, la critique est purement subjective et esthetique?
Parce que =*= ou .equals, ca change pas grand chose au final.
Non parce que si ton ide est capable de te trouver tout tes type1.equals(typeX), il est aussi capable de te trouver tout tes (type1 == typeX)
Concretement, quel ide permet de retrouver les references a == pour un certain type donne?
Des ides qui trouvent les references a Machin.equals, t;en as une palanquee par contre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Jean B . Évalué à 3.
Parce que =*= ou .equals, ca change pas grand chose au final.
Comme dit plus bas le problème n'est pas .equals plutôt que ==.
Si demain matin je peut faire 1.equals(1), moi ça me vas aucun soucis.
Encore mieux si je peut faire null.equals(42) pour virer 90% de ces putains de if (truc != null) je serait ravis.
Ce que je veux c'est qu'il n'y ai pas de confusion entre égalité et identité or actuellement en Java == compare l'un ou l'autre en fonction des des types de l'expression.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
Si c'un type scalaire, ca sera une valeur, sinon ca sera l'adresse pointee.
Qand a traiter null comme un objet, j'imagine que tu mesures les consequences que ca a?
C'est sur que les null checks, c'est pas sexy et alourdit inutilement le code. En pratique je m'en sort 75% du temps en retournant l'expression (tu compares generalement un trucque tu connais a un truc que tu connais pas, donc t'as tres souvent un qui est pas null)
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 10.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par pasBill pasGates . Évalué à 2.
Ensuite tu peux definir cet operator comme bon te semble...
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 2.
Bref comme equals mais qui fonctionnerais sur les types en java.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 5.
C'est assez facile à remarquer, bar et bar2 sont des pointeurs.
Il fallait faire *bar == *bar2 pour que le code ait un sens. Mais dans ce cas, tu vois que tu passes de pointeurs à des objets (la petite étoile), et je trouve que c'est compréhensible syntaxiquement parlant.
Au passage, si tu fais *bar == *bar2 sans avoir surchargé l'opérateur, ton code pète pas silencieusement du tout. GCC a tendance à t'envoyer 400 lignes (au moins) d'erreur.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par phoenix (site web personnel) . Évalué à 2.
[^] # Re: Utiliser les tty
Posté par briaeros007 . Évalué à 5.
Après que java ait longuement expliqué que les pointeurs étaient justement trop compliqué à manier c'est pour ca que java est né toussa ...
[^] # Re: Utiliser les tty
Posté par Jux (site web personnel) . Évalué à 3.
Autant sans pointeurs, on ne va pas très loin, même en Java. Autant l'arithmétique sur des pointeurs à la C, on peut tout à fait s'en passer*. Même chose pour la gestion de la mémoire.
D'ailleurs, le langage Go ( http://golang.org/ ), dont le but est de remplacer le C pour la prog système introduit justement un garbage collector et interdit l'arithmétique sur les pointeurs. Mais on a toujours des pointeurs.
* sauf peut-être pour certains trucs très très bas niveau
[^] # Re: Utiliser les tty
Posté par briaeros007 . Évalué à 2.
Et ca expliquerais pourquoi il n'y a pas de différence syntaxique sur les pointeurs, références etc...
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
Les scalaires sont des valeurs, tous le reste est en pointeur. Idem pour les parametres, tout est par valeur.
Ca simplifie les choses, t'as (moins) besoin de reflechir.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Sylvain Sauvage . Évalué à 2.
La seule chose que Java a faite, c’est d’utiliser le terme de « handle » pour les variables-objet pour ne pas utiliser « référence » ou « pointeur » qui sont deux choses différentes (entre elles), notamment à cause de C/C++.
Et certains ont compris que Java voulait éviter les pointeurs alors qu’ils ont juste voulu éviter le terme « pointeur »…
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
Les paralleles gc sont fait pour eviter ca, et tu peux tuner le gc comme bon te semble (latency vs throughput).
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 2.
Si c'est la première solution, alors effectivement, ce n'est pas très grave.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 1.
C'est pas pour dire, mais C# permet de s'affranchir du garbage collector. Ce qui me conforte dans mon opinion comme quoi C# > Java.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à 2.
Je dis juste qu'il est possible de se passer du GC en C#, contrairement au Java.
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par yellowiscool . Évalué à -1.
Plus d'informations ici : http://msdn.microsoft.com/fr-fr/library/t2yzs44b(v=VS.80).as(...)
Envoyé depuis mon lapin.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 3.
Si t'es sur une grosse babasse avec 4go de heap (ou plus, soyons fou) t'as beau l'appeler souvent, si ta heap est a moitie pleine en moyenne, tu vas passer ton temps a parcourir la moitie de la heap.
Sans compter la gueule du code avec des system.gc un peu partout au ptit bonheur la chance.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 2.
Normalement maintenant c'est la vm qui s'autoadapte en recherchant des pattern et de déclencher les optimisations qui vont bien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 0.
Certes, apres ca arrive sur des applis qui ont des besoins gargantuesques de ram, donc rien de tres etonnant non plus. Disons qu'il faut des mecs qui connaissent la JVM et savent ce qu'ils font.
il y a un fort couplage avec l'application.
Oui, les scripts de lancements de ton appli sont generalement fortement couples a ton appli, je comprends pas trop le point.
Normalement maintenant c'est la vm qui s'autoadapte en recherchant des pattern et de déclencher les optimisations qui vont bien.
Ben c'est pas magique non plus, la JVM ne peut pas deviner si tu veux du throughput ou une faible latence.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 2.
Oui, les scripts de lancements de ton appli sont generalement fortement couples a ton appli, je comprends pas trop le point.
Quand je parle de fort couplage c'est que tu dois te les retaper pour chaque installation et les vérifier pour chaque mise à jour, sachant que chaque test durent quelques heures. C'est un coût en temps phénoménal.
Normalement maintenant c'est la vm qui s'autoadapte en recherchant des pattern et de déclencher les optimisations qui vont bien.
Ben c'est pas magique non plus, la JVM ne peut pas deviner si tu veux du throughput ou une faible latence.
Je parlais de G1 (je crois) arrive à améliorer un peu les performances en détectant des motifs d'utilisation de la mémoire (si je ne me trompe pas il vois que tu utilise des objets avec une durée de vie courte il se reconfigure en conséquence).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 2.
Lancer un full gc a la fin de chaque requete ne va pas t'aider, au contraire, ca ne fait que deplacerle pb au client suivant, surtout que ton gc ne va pas commencer quand tu lui dit de commencer, mais va scheduler un gc pour "plus tard".
Non, la solution est de tuner ton gc pour la latence (ie, beaucoup de pauses mais tres courtes) ou d'allouer achement moins (mais vraiment achement moins) si tu peux te le permettre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
T'as joue un peux avec les -XX:ParNewGen et son pote, le concurrent GC?
Sans faire de miracle, ca reduit potentiellement la latence a un niveau plus qu'acceptable.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 4.
Et si tu utilises une update récente de Java 6 (de mémoire c'est arrivé en u14) tu as G1 qui est enfin un gc bien pensé et adapté aux contraintes des applis, au multicore et aux grosses heap: http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf
D'ailleurs OpenDS en est très content il me semble et a participé à améliorer G1 depuis l'u14. G1 est prévu pour être le gc par défaut dans Java 7.
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 2.
[^] # Re: Utiliser les tty
Posté par barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 1.
L'opérateur == fonctionne même si n'importe lequel de ses opérandes sont null, alors qu'un a.equals(a) est un appel de méthode qui ne peut fonctionner que si a n'est pas null.
De plus, en terme d'optimisation no sait qu'un == est toujours très rapide, alors que le equals peut être très lent suivant les cas. (mais il faut bien avoir conscience de la différence sémentique entre les deux!)
Et par rapport à la discussion sur les auto-boxing et unboxing, je trouve que c'est le pire truc qui ai été introduit dans java, en ce qui me concerne je configure le compilateur d'eclipse pour les considérer comme des erreurs, pour être sur de ne pas utiliser ces saletés par erreur.
J'ai déjà vu des horreurs où le programmeur utilisait indistinctement int ou Integer pour ses variables, et donc ça passait son temps à faire sous le manteau des intValue() et des valueOf() dont la plupart auraient pu être évités en ne travaillant qu'avec des int, et en terminant éventuellement par un Integer.valueOf() si on a besoin d'un objet.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par wismerhill . Évalué à 2.
Ça ne peut fonctionner qu'en utilisant une méthode statique:
Statique.equals(a,null)
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
A part rendre les choses moins explicite et plus dure a lire?
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 3.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 0.
Et ca casse la convention que ce genre d'operateur est associatif.
Si a != b alors b != a.
Si !a.equals(b) alors !b.equals(a) peut te peter a la gueule.
Pour les surcharges d'operateurs, idem.
a * b est egal a b * a (note l'absence de == :P)
Pour du calcul matriciel c'est pas le cas.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 1.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 0.
Oui :) desole :)
juste parce qu'il est commutatif dans ton langage.
Ben oui, dans mon langage. Je me fout qu'il le soit pas en pakistanais oriental du sud.
Il y a d'autre opérateurs qui ne le sont pas. Si tu préviens le développeur quand tu lui apprends le langage, ça ne pose pas de problèmes (sauf si c'est un lapin nain de deux jours)
Deux choses.
La premiere, c'est la coherence de l'ensemble. T'es libre d'ajouter des exceptions un peu partout, mais ca aide pas a tout comprendre.
La deuxieme, c'est ton "si tu previens le dev".
Oui, donc en clair, si tu brieffes le mec pendant 3 jours avant qu'il ait le droit de lire du code (oui, parce que ya ca, et pis un autre truc, et pis ci, et pis ca, ca s'additione ces machins), ca marche. Et encore, ca c'est si t'as quelqu'un pour brieffer le gars.
C'est tres precisement ce que Java cherche a eviter. Le langage est dead simple. Tout est tres coherent, tres costaud, tres tres peu d'exceptions aux regles voire aucunes.
Parce que les mecs qui l'utilisent le font pas pour economiser 4 caracteres ou parce que c'est cool, mais parce qu'ils sont la pour ecrire une application qui resoud un probleme metier, pas technique. Que cette application va etre la pour longtemps, qu'elle implique probablement quelques equipes de beaucoup de personnes, potentiellement reparties au 4 coins du globes et que si t'ouvres la portes aux ambiguites, elles vont rentrer, s'installer, taper dans le frigo et squatter tes chaussons.
Si les gains ne commencent pas le vol des mes chaussons "tete d'homer simpson", ca vaut pas le coup et c'est s'emmerder pour rien.
La plupart des devs java, la grosse difficulte, n'est pas technique en soit (bon, un peu quand meme), c'est surtout d'assembler des pieces ensembles proprement, pas avec 2 bouts de ficelles et une vis en travers. Eviter que quand tu corriges un truc d'un cote, ca pete autre de l'autre cote.
Ce qui est tres important, c'est l'architecture. Les devs peuvent pisser du code, tant qu'ils restent dans les clous que l'architecte a definit, ca s'assemblera bien.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Antoine . Évalué à 5.
Et moi je persiste à penser qu'un langage qui a de multiples types standard pour représenter un même concept, avec des sémantiques totalement divergentes et du coup trompeuses, est mal foutu à la base.
Quant à décortiquer du code, oui, mais dans un langage propre ;)
[^] # Re: Utiliser les tty
Posté par Jean B . Évalué à 4.
Cependant je ne peux m'empêcher d'être _un tout petit peu_ de son avis, au sens ou àhma si rapidement Java avais permis la surcharge d'opérateur tout aurait été bien plus simple.
C'est d'ailleurs ça qui me gène le plus dans Java, ce mélange d'objet de premières classes et de types "primitifs" cachés sous le tapis à coup d'autoboxing.
Qui arriverait à vendre l'autoboxing comme une fonctionnalité plutôt qu'une mauvaise rustine visant à ne pas casser la compatibilité ?
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 1.
Personne. Mais c'est pas incompatible avec ne pas raconter de conneries.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 2.
Integer a = new Integer(0);
Integer b = new Integer(42);
Integer c = new Integer(a.intValue() + b.intValue());
On pourrait se demander pourquoi ils n'ont pas ajouter des add/substract etc
Auquel cas on aurait Integer c = a.add(c);
Mon petit doigt me dit que c'est pour des raisons de clarte d'api.
Bref, ca ne change strictement rien a la facon dont les Number etaient manipules avant java5.
Comme les for(Object value : iterable) d'ailleurs.
Fait un
Integer a = null
int b = a + 1;
Ou un
List strings = null;
for(String string : strings){
System.out.println("brezilien");
}
Les deux vont te jeter un beau NPE.
Quand a la surcharge d'operateur, c'est un truc qui est a l'oppose de la philosophie Java (et de n'importe quel langage objet un tant soit peu coherent d'ailleurs).
Java est un langage entreprise.
Ca sert a faire des systemes couillu, crees par des equipes independantes qui ne communiquent pas forcement beaucoup, qui sont la colonne vertebrale d'une boite, qui vont generalement etre ecrit, deploye en prod et rester la pendant 10, 20, 30 ans.
On a un systeme au taff en prod depuis plus de 10 ans. Et il pourrait bien faire 10 ans de plus si le management avait pas decide de l'outsourcer.
Une des raisons de son adoption massive, c'est que le langage est tres simple, et tres explicite.
Tu files une methode Java a n'importe quel mec qui a deja tape du code, il comprendra instantanement ce que le code fait, et sans aucune ambiguite.
Tu peux pas clairement pas dire la meme chose de n'importe quel autre langage complexe, genre c++ ou pire, perl.
Je considere ca comme un prerequis fondamental pour faire du code de qualite. Un code de qualite se lit comme un livre, si faut passer son temps a sauter partout dans le code pour savoir si + n'a pas ete surcharge pour tel objet, mais pas pour tel autre, c'est pas vivable.
Dans une boite ou le systeme est critique et ou les devs peuvent etre parti depuis tres longtemps, ou une ssii ou le mec qui a commence le projet se retrouver parachute expert python 15 jours apres et part ailleurs, c'est tres important, ca permet de passer la patate chaude plus facilement.
Si un petit malin s'amuse a surcharger les operateurs, bon courage pour facilement comprendre ce que fait le code. Et t'ouvres la porte a de potentiels gros problemes de perf ou autres pour les gens qui utilisent tes classes.
Note que de toutes facons, surcharge des operateurs ou pas, ca changera pas grand chose, vu que tous les types de bases sont immutable en Java.
Et meme s'ils ne l'etaient pas, ce sont des objets, et les objets ne s'ajoutent pas entre eux.
Et si tu regardes les implems, les objets ne s'ajoutent pas entre eux, ca n'a aucun sens.
Tu vas me dire qu'on peut ajouter des strings en java, je te repondrais que non, c'est du pur sucre syntaxique la encore.
"toto" + "titi" sera compile en
new StringBuilder("toto").append("titi").toString().
Et c'est pour ca que concatener des chaines dans une boucle, c'est mal, m'voyeeez? Surtout avant java 5 ou il n'y avait que StringBuffer qui est synchronizee, c'est moins grave maintenant.
Et c'est aussi pour ca que passer par des StringBuilder pour concatener 3 chaines, c'est mal, m'voyeez?: ca rend le code moins lisible pour 0 gains.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 6.
Je sais que ce n'est pas très gênant dans certaines applications, mais quand tu as des calculs à faire, par endroit, ça serait bien (je fais parfois de l'Ada au boulot, on a une bibliothèque mathématique validée, qui n'utilise pas la surcharge qui est possible en Ada. Rien de plus pénible que de voir qu'un calcul matriciel v' = A*B*v par exemple prendre 3 lignes de pleins de caractères. Bon évidement, quand on écrit
tmp_v = mult_m_v(matrice => B; vect => v);
v' = mult_m_v(matrice => A; vect => tmp_v);
on maîtrise ce qui est fait en premier. Mais on est quand même capable d'écrire (quitte à mettre dans les règles de codage qu'on doit absolument associer par parenthèse ce que l'on veut))
v' = A*(B*v);
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
Non, c'est sur.
Apres, la difference se fait sur la relecture du code.
Le code est lu par des humains, et les humains ont un fonctionnement un peu particulier.
Quelqu'un qui lit + va automatiquement comprendre ca comme l'operateur mathematique, a savoir 1 + 1.
Meme si l'humain est capable de comprendre que vecteur1 x vecteur2 est le produit vectoriel de 2 vecteur, ca fait une gymnastique mentale supplementaire et parfaitement comprendre le context, ce qui n'est pas desirable pour un relecteur externe.
Appelle ca vecteur1.produitVectoriel(vecteur2), ca devient tout de suite beaucoup plus clair pour tout le monde.
Et on sait exactement ce qu'il se passe si le premier membre est null (pas dans l'autre cas).
Le dev peut affreusement nommer ses methodes (et il le fait souvent), certes, mais le langage n'y peut rien. La ou le langage peut, c'est limite la casse et t'empecher d'introduire une ambiguite dans ton code en disant "les operateurs, c'est pour les maths, point".
Quand à dire que la surcharge c'est pas joli en objet, je dirais que dès le moment où tu peux faire a+b quand ce sont des int, je ne vois pas ce qui gênerait à l'autoriser pour d'autres objets.
Le probleme est que tu assumes que + se mappe forcement semantiquement a add.
Prend une liste par exemple, elle definit add.
mais liste1 + liste2 est semantiquement TRES different de list1.add(list2). Ce que tu veux dans ce cas, c'est un addAll.
C'est juste une mauvaise idee.
L'autoboxing marche pour Number parce que d'une part sun^W oracle controle le langage et le framework, d'autre part, ya effectivement une correspondance one to one entre Integer et int, et donc une correspondance one to one entre + pour Integer et l'operateur + mathematique. Dans ce cas ca marches tres bien.
Pour tous les autres objets, la correspondance n'est clairement pas la, sa presence va dependre de tellement de parametre qu'utiliser + revient sensiblement a la meme chose que d'appeler une methode zorglub: ca t'avances pas des masses sur ce que fait la methode.
Quitte à restreindre l'utilisation à un sous-ensemble d'objets bien identifiés (genre Object->Mathematic ou un truc du genre) avec un ensemble de méthodes identifiées (Type1+ Type2 serait automatiquement un appel Type1.add(Type2) s'il existe, une erreur si ça n'existe pas)
C'est ce que fait java avec l'autoboxing, et le resultat est pas joli joli. Ca marche dans les cas simples, le reste du temps, c'est chiant a utiliser: on pense avoir un truc simple, mais en fait il est complique.
Ton exemple avec les matrices est parfait.
Ta surcharge d'operateur * sur les matrices casse la lecture naturelle du code et rends ton code plus fragile. La validite du code tient a une paire de parentheses.
Force a ecrire temp = b.multiply(v); v = a.multiply(temp), ton code y gagne en clarete (plus besoin d'evaluer la priorite des operateurs patati patata) et c'est beaucoup plus explicite.
Tu sais que t'appelles telle implementation de la multiplication et dans quel ordre.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par 2PetitsVerres . Évalué à 3.
Sauf si le relecteur externe c'est le gars qui a mis au point les lois de contrôle et que lui, justement, il sait mieux lire a x b que a.produitVectoriel(b). Mais bon, le mieux pour coder les parties mathématiques d'un algo, c'est quelqu'un qui est capable de comprendre ce que le concepteur dit, dans sa langue, qui est les maths.
Le dev peut affreusement nommer ses methodes (et il le fait souvent), certes, mais le langage n'y peut rien. La ou le langage peut, c'est limite la casse et t'empecher d'introduire une ambiguite dans ton code en disant "les operateurs, c'est pour les maths, point".
Ben en même temps, un produit vectoriel, ce sont des maths, une comparaison de valeurs, ce sont des maths.
Pour tous les autres objets, la correspondance n'est clairement pas la, sa presence va dependre de tellement de parametre qu'utiliser + revient sensiblement a la meme chose que d'appeler une methode zorglub: ca t'avances pas des masses sur ce que fait la methode.
Ta méthode + sur ton objet, elle a une spécification. Elle parle aussi de l'addition. Le dev qui est capable de faire une méthode add, equals cohérente, il est capable de faire une surcharge cohérente. Le type qui appelle sa méthode zorglub, il fera pas mieux avec la surcharge, c'est sûr.
Ton exemple avec les matrices est parfait.
Ta surcharge d'operateur * sur les matrices casse la lecture naturelle du code et rends ton code plus fragile. La validite du code tient a une paire de parentheses.
Force a ecrire temp = b.multiply(v); v = a.multiply(temp), ton code y gagne en clarete (plus besoin d'evaluer la priorite des operateurs patati patata) et c'est beaucoup plus explicite.
Tu sais que t'appelles telle implementation de la multiplication et dans quel ordre.
Ouais ben c'est là qu'on est pas d'accord et qu'on arrivera pas à se mettre d'accord (c'est pas grave en même temps). Je trouve A*(B*c) au moins 42 fois plus lisible que la version avec une variable temporaire. Pour savoir quelle implémentation tu appelles, ben c'est facile. Si t'as plusieurs implémentations de la même multiplication matrice vecteur dans ton projet, soit tu as du code inutile, soit tu as un cas général (=a utiliser dans la surcharge) et un cas particulier à utiliser dans certaines circonstances, et c'est précisé dans ta spécification.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à -1.
Et si c'est un autre dev, pas forcement rompu a cette partie du code, qui tente de corriger une anomalie ou qui recupere la maintenance d'un projet?
La surcharge et ce genre de conneries, ca marche tres bien si t'es tout seul dans ton coin sur ton petit projet, mais c'est clairement pas la cible de java.
Sans compter qu'il me semble que le symbole pour les produit vectoriel, un X rigolo, pas une etoile?
Reste toujours que le * ne donne aucune information sur ce qu'a voulu faire le mec qui a ecrit le code.
Ton * est totalement indefinit pour les objets, ca dit juste que c'est une multiplication, charge a l'implementeur de definir la multiplication.
Appelle ca zorglub, ca fait un bofossou, charge a l'implementeur de definir le bofossou, c'est pas tellement different.
Bon ok, je pousse un peu, ca va souvent etre comprehensible, mais t'es jamais vraiment sur. Et dans certains cas, ca va etre clairement super ambigue. Genre le cas de la list, le + peut etre parfaitement raisonnablement interprete de 2 facons completement opposees.
Quand je lit list.add(list) ou list.addAll(list), je sais tres exactement ce que le mec qui a ecrit le code a voulu faire.
Quand je lit list + list, j'en sais trop rien. Je suis pas dans sa tete, donc je ne sais meme pas si le probleme se trouve dans + ou dans l'expression, parce que je ne sais meme pas ce que le mec a voulu ecrire en premier lieu.
Il aurait pu ecrire list zorglub list je serais pas plus avance.
En general, ca passe, mais quand ca passe pas, on fait quoi? On s'encule? Si c'est un bug cho cho cho en prod, avec des mecs en cravate derriere toi qui te fouttent et te promettent un monde de douleur si c'est pas regle d'ici une heure, tu vas probablement te dire que cet abruti qui a ecrit ce bug, il aurait mieux fait d'ecrire 5 caracteres de plus. Ou de se casser une jambe.
Tout ca pour quoi?
Pour ne pas avoir a ecrire equals?
Perso je prend les 5 characteres en plus, les coups de fouet, c'est quand ca s'arrete que ca fait du bien, et si je peux eviter d'ajouter des petits problemes aux grands, je le fait tres volontiers.
Ben en même temps, un produit vectoriel, ce sont des maths, une comparaison de valeurs, ce sont des maths.
Ouch! Ca fait mal au coeur de lire ca.
Je ne m'aventurerais pas sur la partie produit vectoriel. Un peu quand meme. C'est une operation faite par un objet sur un autre objet. Pas une operation mathematique. En tout cas, pas dans le paradigme objet. Ca va dependre fortement de ton modele.
Tu peux vouloir une exception quand c'est pas defini, passer ca sous silence, bref, c'est tout sauf clairement definit. Et par clairement, j'entends 0 doutes, nada, pas "bah, il doit vouloir dire ca".
La comparaison de valeur, dans une logique objet, c'est tout sauf des maths. L'identite des objets change du tout au tout en fonction du domaine et du modele implemente. Ca n'a rien d'une operation mathematique, les valeurs peuvent etre identiques et pourtant ne pas etre egale.
Mon gateau, c'est mon gateau, ton gateau c'est ton gateau, ils sont differents, et pourtant ya strictement la meme chose dedans (des pepite de chocolat :) ). Pour le fabriquant, il s'en tamponne, c'est tous les memes, fout moi ca dans une boite et envoie tout ca au supermarche.
J'appelle pas ca des maths perso.
Ta méthode + sur ton objet, elle a une spécification. Elle parle aussi de l'addition. Le dev qui est capable de faire une méthode add, equals cohérente, il est capable de faire une surcharge cohérente. Le type qui appelle sa méthode zorglub, il fera pas mieux avec la surcharge, c'est sûr.
Evidemment que + est specifie, sa specification etant indefinie. C'est un gros fourre tout qui sert a mettre un peu tout et n'importe quoi.
Add transporte une semantique bien plus forte. Tu dis ce que tu veux faire en ecrivant ca. Si apres coup on se rend compte que le nom est mal choisi, ben on peut le changer, mais c'est pas trop le sujet ici.
+ c'est grosso modo un alias pour dire "va voir dans la doc, pardon le code, comment + est defini et ce qu'il veut dire". J'ai voulu utiliser un zorglub et si tu veux etre sur a 100% de ce que j'ai voulu faire, ben va falloir venir me demander.
Je trouve A*(B*c) au moins 42 fois plus lisible que la version avec une variable temporaire.
J'avoue que le temp est pas joli joli. C'est un moindre mal on va dire.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par nicolas . Évalué à 6.
Reste toujours que le * ne donne aucune information sur ce qu'a voulu faire le mec qui a ecrit le code. »
Je regarde si le résultat est un scalaire, si c’est un vecteur ou s’il applique le même opérateur à des matrices ou seulement à des vecteurs. Ça permet de savoir l’opérateur qui a été choisi d’assigner au signe « * ». Bien sûr l’opérateur n’a pas la même signification en fonction des opérandes, ce n’est pas un problème en soit. En cas de méfiance envers celui qui a écrit le code il faudra aller lire la doc. voir le source. De toute façon il y a toujours ambiguïté sur les opérateurs matriciels, il faut les définir si le contexte n’aide pas, une fois ceci fait, on ne s’amuse pas à les redéfinir à toutes les lignes parce que ça n’aide pas la lecture (on l’écrit même pas, l’écriture ABC pour A, B, C des matrices n×n n’a jamais choqué aucun mathématicien…). Pourquoi en serait-il autrement dans un code informatique ?
« Quand je lit list.add(list) ou list.addAll(list), je sais tres exactement ce que le mec qui a ecrit le code a voulu faire. »
Pas moi. Typiquement le cas foireux ; le texte n’apporte pas plus d’information qu’un « + ».
— add c’est pour ajouter des éléments à la fin d’une liste ?
— addAll c’est pour faire une réduction, c’est-à-dire la somme des éléments de mes listes ?
— Ou alors add fait l’addition élément par élément ;
— à moins que ce soit le addAll, le All étant là pour bien préciser qu’on travaille sur tous les éléments.
— Plus fou : c’est pour ajouter une dimension à une liste pour en faire un tableau 2d ?
Bref : tu sais ce que le mec qui a écrit le code a voulu faire. Espère juste que ça ne sera jamais moi, car je risque de ne pas attacher la même signification à ces méthodes. Loupé : pour savoir ce que fait la méthode il faut aller lire sa doc. comme pour la surcharge du « + ».
« Quand je lit list + list, j'en sais trop rien. »
Pas moi, je regarde les opérandes, si je manipule des nombres ce sera l’addition élément par élément mathématique, sinon la concaténation. Mais ce n’est que ma convention. En tout cas tu n’en sais ni plus ni moins que dans le cas précédent.
« Pour ne pas avoir a ecrire equals? »
Et pour ne pas avoir à le lire, perso., quelqu’un qui ne fait pas de Java, j’ai halluciné sur l’histoire des Integer simplement parce que je code pour du calcul et que j’ai été formé pour du C.
« C'est une operation faite par un objet sur un autre objet. Pas une operation mathematique. »
Oui je suis d’accord, alors donnons aux signes mathématiques la sémantique qu’ils ont toujours eu : la mathématique, pas la signification informatique, par exemple == de deux entiers compare par valeur, ; les histoires de références, et donc d’adresse en mémoire, ne concernent que l’informatique bas-niveau : méthodes adaptées pour.
Je dirai que tout ceci n’est qu’une histoire de convention, et que tu dis que la tienne vaut mieux, c’est totalement faux. Pour quelqu’un qui n’a pas de formation poussée à Java mais qui connaît un peu les maths je t’ai montré que c’est tout le contraire. Le coup du « add(All) » me semble même très dangereux, car tu fais l’hypothèse que le mec qui a écrit ça a suivi ta convention, par contre quand c’est un « + » tu n’acceptes pas que le mec ait pu suivre ta convention : ton raisonnement est biaisé car au final ton argument est identique dans un cas comme dans l’autre. Il faut absolument vérifier que la méthode fasse ce qu’on lui demande.
Le Java interdit de redéfinir + & co, très bien, du coup on va définir des méthodes qui vont bien, mais ça ne fait que déplacer le problème sans le résoudre, car les noms des méthodes suffisent rarement à décrire ce qu’elle font : sinon pourquoi on les documenterait ?
PS : c’est quoi le problème avec les parenthèse ? De toute manière la multiplication matricielle est associative.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par phoenix (site web personnel) . Évalué à 1.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par Enzo Bricolo 🛠⚙🛠 . Évalué à 2.
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
"La première sécurité est la liberté"
[^] # Re: Utiliser les tty
Posté par Jean B . Évalué à 3.
Ou pas, dans les langages que je connais qui permettent la surcharge d'opérateur, la philosophie est toujours que a + b est un sucre syntaxique pour a.add(b) ( ou a.__add__(b) ou encore a.+(b)). Je ne vois vraiment pas pourquoi ce serait anti-objet, c'est juste du sucre syntaxique tout comme l'autoboxing sauf que c'est plus puissant et moins déroutant.
Tu vas me dire qu'on peut ajouter des strings en java, je te repondrais que non, c'est du pur sucre syntaxique la encore.
Non je n'allais pas te le dire par contre ça correspond parfaitement à mon argument.
Si le compilateur Java traduit:
"toto" + "titi"en
new StringBuilder("toto").append("titi").toString()pourquoi ne pourrait-il pas traduire
"toto" == "titi"en
"toto".equals("titi")C'est nettement plus simple. Quite à devoir implémenter une interface Comparable tout comme on implémente Iterable pour profiter du "foreach".
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à -1.
Parce que c'est pas la meme chose.
On va quand meme pas peter la semantique du langage juste parce que vous etes pas capable de comprendre la difference pointeur/valeur ou parce que vous etes trop flemmard pour taper .equals en lieu et place de ==?
Tant qu'on y est, addAll sur List c'est chiant, pourquoi ne pas compiler List.add(List) en List.addAll(List)?
C'est du meme niveau que ce que tu proposes...
C'est nettement plus simple. Quite à devoir implémenter une interface Comparable tout comme on implémente Iterable pour profiter du "foreach".
Oui, c'est sur que si tu supprimes l'egalite de pointeur, tout devient plus simple...
C'est pas complique quand meme.
Il y a l'egalite de valeur. Ca c'est une notion semantique, purement business logic. Tout le monde veut ca.
Il y a l'egalite de pointeur. Celle la, elle est la pour des raisons techniques. Tout le monde veut ca aussi.
Les deux sont fondamentalement different et ignorer la difference entre les deux resultera immanquablement dans d'enormes bugs, quel que soit le langage.
Conclusion:
Il faut donc un moyen de differencier les deux.
Java a choisi de ne s'occuper que de la partie technique, parce que c'est pas au langage de s'occuper de la semantique du code.
Parce qu'ils sont pas trop rat non plus, et que ca ferait chier tout le monde sinon, ils ont introduit hashCode et equals, mais libre au dev' d'implementer l'egalite comme il veut.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Jean B . Évalué à 2.
Oui, c'est sur que si tu supprimes l'egalite de pointeur, tout devient plus simple...
Mais qui a parlé de la supprimer ? Ce que tu appelle égalité de pointeurs ( pointeurs un concept qui n'existe tout simplement pas en Java au passage ) moi j'appelle ça l'identité aka les deux référence désignent le même objet.
Or c'est là àhma toute ambiguïté du == de Java:
1 == 1 => égalité
new Integer(1) == new Integer(2) => identité
Donc == a deux usages selon le contexte.
Moi ce que je désire c'est la séparation de ces deux opérateur == pour l'égalité === (par exemple) pour l'identité. Ou alors que 1 == 1 compare là aussi l'identité.
Mais je comprend très bien les impératif de compatibilité c'est pour ça que dans mon premier commentaire je disais que c'était dommage que cette situation n'ai pas été réglé plus tôt, maintenant il est bien trop tard.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 0.
?!?!?!
Ca doit etre pour ca que Sun a cree la NullPointerException...
Je vais arreter la.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Jean B . Évalué à 2.
D'ailleurs explique moi comment récupérer la valeur (aka adresse) d'un "pointeur" en Java ?
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 1.
Pas trop non.
> D'ailleurs explique moi comment récupérer la valeur (aka adresse) d'un "pointeur" en Java ?
Le rapport? Que le langage ne te donne pas l'addresse ne veut pas dire que ca n'est pas un pointeur....
Ce que je trouve genial c'est que dans une discussion ou tu critique que == s'applique aussi bien aux valeur qu'aux pointeurs, tu vienne dire que la notion de pointeur n'existe pas en java...
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par Jean B . Évalué à 0.
Oui et je persiste et signe, certes les pointeurs existent mais ils sont totalement caché et inaccessible pour le développeur, j'irais presque jusqu'à dire que c'est purement une problématique de l'implémentation actuelle de la JVM.
D'ailleurs quelques extraits de [http://en.wikipedia.org/wiki/Pointer_%28computing%29]:
another language that does not support pointers at all (for example Java / JavaScript)
Many languages, [...] like Java, replace pointers with a more opaque type of reference, typically referred to as simply a reference, which can only be used to refer to objects and not manipulated as numbers
PS: je te préfère dans ton personnage de cykl
[^] # Re: Utiliser les tty
Posté par fearan . Évalué à 3.
Tu auras remarqué que j'ai précisé que c'était equals qui fallait utiliser.
Ce que je critique c'est que ce genre de trucs, si c'est dans la spec, c'est absolument pas dans la doc, ou du moins c'est généralement omis. Tu admettras que c'est absolument pas intuitif comme comportement; et qu'un novice, risque d'utiliser == pour les tests, voir que ça marche et à la mise en production y a tout qui plante.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 2.
Mais marrant d'attaquer Java sur la documentation. On peut lui reprocher beaucoup de chose (mais généralement on lui reproche les mauvaise choses), mais c'est juste le langage le mieux documenté avec lequel j'ai bossé. Tu peux bosser sereinement, ca fait ce que ca dit et ca dit ce que ca fait. En général je préfère bosser avec d'autres langages, mais je regrette toujours la qualité de la doc de Java.
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à 0.
C'est reparti. C'est toujours plus marrant de se tripoter pour savoir si a == b est plus beau que a.equals(b). Et puis discuter de choses triviales, finalement pas si importantes que ca, et qui ne changerons pas ; ca évite de se poser les vrais questions de savoir en quoi la techno nous aide ou pas à construire des choses qui fonctionnent, qui sont fiables, qui sont pérennes, qui sont maintenable, à quel coût en fonction du projet, des besoins et de son équipe. Mes deux cents, c'est que l'ingénierie logicielle c'est pas se tripoter pour savoir si on à le kiki tout dur en voyant son code... Et que le bon outil pour la tâche se défini selon beaucoup plus de critères que le simple nombre de caractères à taper en faisant un + plutôt qu'un .add().
PS: Vous pouvez discutez aussi longtemps que vous voulez. Le langage existe depuis 15 ans et vise la backward compatibilité absolue. Vous perdez totalement votre temps. Cherchez plutôt ce qu'il peut vous apporter; et si vous ne trouvez pas, oubliez le.
[^] # Re: Utiliser les tty
Posté par Littleboy . Évalué à 10.
Par rapport a tes autres commentaires, celui-la a un temps beaucoup plus polemique et agressif (ca ressemble beaucoup a du pff du coup). C'est dommage, le reste des tes commentaires est plutot bon generalement.
[^] # Re: Utiliser les tty
Posté par ckyl . Évalué à -1.
Mais je n'espère plus vraiment voir une discussion plus évoluée que "C'est joli/C'est pas joli" ou "J'aime/J'aime pas" par des gens qui ont utilisé la chose plus de 10 TP. On peut refaire le monde autour d'un comptoir; ou simplement discuter des différentes solutions, qui existent vraiment, en essayant d'analyser en quoi chacune est plus ou moins adapté selon le contexte.
Ca me semble plus intéressant que de parler dans le vide de savoir si equals() c'est plus moche que ==. Par ce que même si tout le monde tombe d'accord, ca ne changera strictement rien.
[^] # Re: Utiliser les tty
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Utiliser les tty
Posté par pasScott pasForstall . Évalué à 2.
Le premier truc qu'apprend un debutant, c'est la difference entre int et Integer.
Le deuxieme, c'est de ne jamais utiliser == sur des objets.
Java a des problemes d'architecture, mais la c'est du pinaillage.
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Utiliser les tty
Posté par riba . Évalué à 2.
Un write() après le execvp permet de gérer ce cas. en face, un process dédié le gère. un select() sur inotify on CLOSE aussi, et plus robuste (si le write échoue, tu n'est pas prévenu, alors le les close sont fait par le noyau).
Le cas d'erreur le plus problématique, c'est quand fork échoue (limite du nombre de process atteint ou autre), tout les codes de traitement d'erreur doivent avoir été déjà lancés, et tous prêts à gérer ce cas, sans devoir lancer d'autres process bien sur.
[^] # Re: Utiliser les tty
Posté par Florian.J . Évalué à 1.
Donc pour un programme qui fait beaucoup de sorties sur stdout il y a une vrai différence niveau performance.
[^] # Re: Utiliser les tty
Posté par apostle . Évalué à 3.
Essaie de comparer en démarrant ton noyau avec "vga=norma"l, les TTY seront 1000 fois plus réactifs. Il me semble d'ailleurs que les distrib' d'aujourd'hui blacklistent les pilotes des framebuffers, j'ai bon ? Moi je ne sais pas, j'utilise un vrai système mais un peu vieillissant, Slackware.
[^] # Re: Utiliser les tty
Posté par Jimmy . Évalué à 1.
D'autant plus qu'un vrai TTY n'avait pas d'écran ...
http://en.wikipedia.org/wiki/Teletypewriter
Les terminaux vidéo auxquels tu penses, affectueusement surnommés "minitels", ne sont déjà plus des "vrais" Télétypes : http://en.wikipedia.org/wiki/VT220
# Testé et approuvé
Posté par Xowap (site web personnel) . Évalué à 8.
À savoir que ça n'est pas une bête de courses, et qu'en temps normal elle lit du 1080p mais pas à l'aise. Bah là j'ai pu faire un make -j64 du kernel et regarder ma vidéo en même temps, en gardant une interface réactive.
À noter quand même que j'ai dû faire la compilation en ramfs, l'I/O du disque était saturée sinon...
Donc voilà, regarder du 1080p avec une charge de 66 sur le PC, ça fait plaisir. Et le changement est net, à partir du moment où on désactive l'option le PC devient totalement inutilisable.
Après l'intérêt avec un usage normal, j'ai pas encore trouvé. J'ai pas constaté de ralentissement, mais pas forcément d'améliorations non plus.
[^] # Re: Testé et approuvé
Posté par Victor STINNER (site web personnel) . Évalué à 10.
Tiens, ça me rappelle un sketch de Coluche...
(...)
- Le nouvel Omo c'est celui qui lave la tache qui est cachée dans le nœud du torchon.
- Vous avez vu ça à la télévision ???
- Y a le torchon, C'est deux gonzesse qui font la publicité, complètement abruties. Y en a une, elle sait même pas qu'il y a un nouvel Omo.
- Heu... l'autre, elle dit : "Ben dis donc ? T'en as fait une grosse tache sur ton torchon."
- Elle est triste la gonzesse, elle a vu la grosse tache. Et l'autre elle est toute gaite.
- Elle dit : "Ah! Ouaf, ouaf!"
- Elle est toute gaite, alors elle dit :
- "Bon ça fait rien avec mon nouvel Omo !"'
- Alors l'autre elle sait même pas que ça existe le nouvel Omo.
- Quoi! , Y a un nouvel Omo
- Alors l'autre :"Ben oui hé con."
- Et alors elle dit : "Regarde bien le nouvel Omo. Tu vois la grosse tache sur le torchon ???
- Je fais un noeud. Tac... et plus la tache!
- Et l'autre elle est sciée.
- Le nouvel Omo, ça lave la tache qui est cachée dans le nœud du torchon. - Mais il est bien le torchon après. Il est propre. Il est aussi propre qu'avec l'ancien Omo sans faire le nœud.
- C'est plus long, faut faire les nœuds.
- D'ailleurs, celui qui a 5 kilos de linge, il fait les nœuds le lundi, il fait la lessive le mardi et puis après il a toute la semaine pour défaire les nœuds.
- Parce que les nœuds qui ont été dans l'eau, bonjour hein.
(...)
[^] # Re: Testé et approuvé
Posté par insert_coincoin . Évalué à 9.
C'est un 2.6.35-22 sur mon ubuntu 10.04 (2.6.33.qqchose normalement).
Nautilus est plus rapide. Pas forcément à la première ouverture de dossier, mais après c'est flagrant; pour les aperçus de photos (genre dossier avec 300 photos), ça va aussi plus vite !
Firefox est vachement plus rapide : chargement, scroll, pas au démarrage par contre j'ai l'impression.
Les pdf s'ouvrent aussi rapidement qu'une prostituée du quartier rouge.
Ma femme est revenue hier.
Mon patron vient de m'appeler pour me dire qu'il m'embauchait.
J'ai eu une augmentation dans la foulée.
Par contre, j'ai une interrogation : j'utilise jackd assez souvent; ce patch va-t'il influer sur les priorités ?
[^] # Re: Testé et approuvé
Posté par bubar🦥 (Mastodon) . Évalué à 7.
(peut être pour madame aussi ? :p )
[^] # Re: Testé et approuvé
Posté par Maclag . Évalué à 10.
Je constate que tu passes ton temps à mâter des photos et faire mumuse avec de la musique.
Tu es re-viré, mon vieux!
[^] # Re: Testé et approuvé
Posté par insert_coincoin . Évalué à 10.
[^] # Re: Testé et approuvé
Posté par Prae . Évalué à 4.
Ouch!!!! c'est quoi ce truc sale et laid ?!!
# Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Victor STINNER (site web personnel) . Évalué à 5.
D'ailleurs, peut-on émuler le patch noyau avec des commandes shell ? Les cgroups peuvent être configuré avec un système de fichier virtuel.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . Évalué à 3.
systemd est parfaitement capable de faire ça il me semble.
D'ailleurs j'ai vu des discussions sur l'intérêt de ce patch si l'espace utilisateur ne peut pas faire tout plus finement...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par daimrod . Évalué à 4.
En fait ce que dit Linus dans son mail, c'est que grâce à cette optimisation, l'ordonnancement par groupe (group scheduling) n'est plus qu'un gadget et va donc pouvoir être déployé de manière plus importante.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par bubar🦥 (Mastodon) . Évalué à 6.
(l'ajout de qu' laisser une interprétation autre, et contradictoire)
Non ?
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par daimrod . Évalué à 2.
anéfé, « n'est plus un gadget » est bien ce que je voulais dire.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Gabin . Évalué à 4.
En quoi, le regroupement par des process par tty crée une logique qui améliorerait la réactivité?
Et sur la video, il ne semble pas avoir lancé Firefox/nautilus/totem/gcc via différent terminaux.
Je pige pas le truc, j'aurais préfère une annonce plus pédagogique sans le côté sensace et paillette faisant passer par ailleurs l'expérience Linux d'avant/actuel comme horrible.
à les lire, le multi-tâche n'existera qu'à partir de la 2.6.38. :)
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . Évalué à 7.
Donc le make -j 64 est dans un groupe distinct du reste de l'interface, et voilà...
Le scheduleur, je suppose, va faire attention à ce que chaque groupe ait un bout "suffisant" de CPU pour son travail, alors que si tout le monde est dans un groupe, ben à cause du make -j 64, y'aura 64 + n processus voulant le processeur, et le scheduleur ne sait pas qui "favoriser" et donne autant que possible à chaque processus, tout simplement...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Il y a eu 3 versions de cette dépêche, j'ai écrit celle qui a été publiée. J'ai tenté de virer les superlatifs pour me concentrer sur l'aspect technique. Mais j'avoue ne pas avoir compris ce qui fait que le patch améliore la réactivité. Si quelqu'un a une bonne explication, je suis très intéressé.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Dup (site web personnel) . Évalué à 10.
Sans les cgroups autogroupon a pour un make -j64 et un firefox un VLC, en simplifiant 66 process en tout.
Chaque tâche aura 1/66ème du temps processeur (à priorité égale)
Avec les cgroups, il y a 2 groupes de process qui sont créés: un pour le make -j64 et un pour les applications graphique (firefox/vlc).
Chaque cgroups a droit à 50% du proc, donc en somme le make -j64 n'utilisera pas plus de 50% de cpu ce qui laisse assez à vlc/firefox de quoi tourner correcrtement avec 1/2 du temps processeur comparé au 1/66ème présenté ci-dessus.
Bon quand je dis n'utilisera pas plus de 50% c'est à relativisé si du temps CPU est dispo il est pris par le cgroups en ayant besoin.
En somme ca améliore l'expérience desktop mais la compilation sera plus longue.
Bon il est possible jme trompe mais c'est ce que j'ai compris du fonctionnement du patch.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par riba . Évalué à 10.
non non c'est bien ça.
En somme ca améliore l'expérience desktop mais la compilation sera plus longue.
La compilation finira exactement en même temps avec et sans patch. Le temps total de CPU reste le même (et le nombre de contexte switch aussi), mais firefox/vlc/... (des application qui ne demandent pas beaucoup de CPU) s'intercaleront plus au début au sein des 64 processus de compilation, par rapport au mode d'avant.
Bon en fait c'est chiant à expliquer :-(, dessin:
C=compilation
A=autre application légère (potentiellement interactive)
avant: (A a une chance sur 65 de passer a chaque coup)
CCCCCCCCCACCCCCCCCCACCCCC
^ A fini
après: (A a une chance sur 2 de passer a chaque coup)
CACACCCCCCCCCCCCCCCCCCCCC
^ A fini
A a pris 2 slices de CPU (pour faire son petit truc interactif qui prends pas de ressource), comme avant, mais a fini beaucoup plus tot!
La compilation a finit bien sur exactement au même moment.
Le rôle du scheduler est "juste" de choisir C ou A a chaque HRtimer/syscall/...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par insert_coincoin . Évalué à 4.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Albert_ . Évalué à 6.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
D'ailleurs, il regroupe tout par tty mais pourquoi ne pas le faire par l'arbre des fork() ? en gros init, va créer n process, tous ayant 1/n temps cpu en moyenne, et chacun des 1/n sera divisé par le nombre de process créé ensuite, etc... Évidemment si le temps n'est pas utilisé il est redistribué.
"La première sécurité est la liberté"
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . Évalué à 5.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le noyau pourrait faire le boulot à chaque fork() en allouant une fraction identique de cpu à chaque père et leur fils.
init: 100%
a et b: 50%
aa ab a: 16.6% chacun b 50%
etc...
"La première sécurité est la liberté"
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . Évalué à 2.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . Évalué à 2.
Je vois mal un mplayer sur un film HD, un jeu, un compilateur ou autre tenir avec moins de 5% du CPU (l'init a quand même une cinquantaine d'enfants chez moi).
La séparation en groupe est suffisante, sans allouer de manière fixe des portions de CPU ce qui serait un énorme retour en arrière...
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Pinaraf . Évalué à 2.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par ckyl . Évalué à 5.
Tu définis des cpu.shares dans pour chaque cgroup. Pour tout les cgroups du même niveau tu additionnes leur cpu.shares. Chaque groupe obtient la portion de sont cpu.shares / sommes(cpu.shares). Et tu itères le processus en descendant de la hiérarchie.
Tu peux donc dire des choses comme "L'ensemble de mes machines virtuelles n'utiliseras pas plus de 50% CPU si il y a contention sur l'accès au CPU et ma machine virtuelle X n'utilisera pas plus de 50% du temps CPU alloué aux machines virtuelles". Ce qui donnera donc 25% CPU au max donc si il y a contention entre un autre cgroup du niveau supérieur et un autre cgroup de machine virtuelle. Si il n'y a que des machines virtuelles qui veulent du CPU alors ma machine virtuelle donnée va récupérer 50% du CPU (50% de 100%). Mais aussi 50% si tu n'as que cette machine virtuelle mais qu'un autre cgroup du niveau supérieur veut du CPU.
C'est puissant mais bordélique selon ce que tu veux faire, par ce que ca devient rapidement facile de perdre l'idée globale de ce que ca fait en partie. Il n'y a pas moyen de faire quelque chose quand il n'y pas de contention. Donc si ton système est idle, la tache bouffera tout le CPU.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par Yannick Le Saint (site web personnel) . Évalué à 8.
En somme, si on ne compile pas des kernels à longueur de journée, on s'en fiche complètement donc ?
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par pasScott pasForstall . Évalué à -1.
Ca fleure bon le benchmark biaise (invonlontairement, certes).
If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par fearan . Évalué à 6.
Ensuite utiliser un IDE sous linux, à part pour du dev JBoss et quelques cas particulier, c'est un poil redondant avec le système :D
Emacs ou gvim sont nettement plus adapté. Kate pour les débutant.
PS: c'est vendredi !!!
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
(une explication non, une question, oui :p forcément!)
Serait ce une différence de politique par défaut ? Ou celui qui voudrait un autre fonctionnement par défaut devra se le configurer ?
Après tout, sur un serveur, ça n'impactera pas. (à moins de jouer à frozen bubble dessus). Et pour des configurations "plus en avant", après tout, ils peuvent se coltiner la doc, eux, non ?
Mais une question quant même, donc : n'est ce pas contradictoire avec cgroup ? puisque cet outil est générique (pouvant être utilisé aussi bien en fonction de / pour des serveurs web ou des serveurs de sessions ou une station de compil / calcul ou même pour un laptop, voir un téléphone). Alors ce patch, qui impose une politique par défaut (bon, pas intrusive), n'est il finalement pas en contradiction avec le fait que cgroup soit "neutre et pour tous" ?
Est ce que ce qu'a commencé de faire redhat n'est pas "mieux" sur le long terme ? (ie proposer une intégration, des outils de plus haut niveau, etc etc), et plus "fidèle" à ce qu'est cgroup ?
??
[^] # Re: Gain sur un environnement de bureau n'utilisant pas de terminaux ?
Posté par neologix . Évalué à 5.
Pourquoi ?
Parce qu'aujourd'hui la solution proposée est basée sur les ttys, mais demain on aura sûrement de meilleurs heuristiques pour la création de cgroups.
De façon plus générale, la tendance générale est d'implémenter les mécanismes dans le noyau, mais de laisser la politique au mode utilisateur, tout simplement parce qu'il est beaucoup plus simple et moins risqué d'avoir du code en mode utilisateur qu'en mode noyau.
Penser par exemple à udev, CPU governor, routage multicast, etc. Bien évidemment, pour des raisons de performances, on peut laisser une politique minimale dans le noyau, par exemple pour le module bonding, netfilter, etc.
# Une alternaive
Posté par tgylzh . Évalué à 10.
http://www.webupd8.org/2010/11/alternative-to-200-lines-kern(...)
[^] # Re: Une alternaive
Posté par JGO . Évalué à 2.
[^] # Re: Une alternaive
Posté par bubar🦥 (Mastodon) . Évalué à 1.
....
Très bon :) Simple, en shell, bien bourrin :)
Enfin, bon, conseil quant même de lire le readme de cgroup avant...Si vous voulez pas "(be) totally in the dark ", comme avec le patch.
Il est con le Lennart... :)) Très bon :))
[^] # Re: Une alternaïve
Posté par bubar🦥 (Mastodon) . Évalué à 1.
D'ailleurs là l'ordi re-compile un noyau, et pendant ce temps : mouler sur dflp et shell. J'ai pas de ralentissements, aucun, pas de blocage ou de manque de réactivité.
Mais bon, ce n'est qu'une impression.
??
# Meego/Android
Posté par gUI (Mastodon) . Évalué à 5.
Garder la fluidité de l'interface tout en ayant des applications en fond, c'est important dans ce cade.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Meego/Android
Posté par yostral . Évalué à 5.
Un noyau compilé avec ce patch sur mon tel Android et la différence est flagrante ! L'interface garde vraiment plus de fluidité en permanence. C'est très agréable.
[^] # Re: Meego/Android
Posté par bubar🦥 (Mastodon) . Évalué à 4.
? :)))
[^] # Re: Meego/Android
Posté par bilboa . Évalué à 2.
[^] # Re: Meego/Android
Posté par yostral . Évalué à 0.
Si tu le dis... tu dois sûrement être mieux placé que moi pour le savoir.
@tankey :
Je n'ai pas de tuto, je n'ai pas les compétences pour.
Mais plusieurs développeurs noyau sur XDA ont intégré ce patch dans leurs dernières versions. Pour le moment j'utilise une version d'IntersectRaven. Si tu veux en savoir plus, tu peux voir directement avec lui, il est super ouvert et vraiment sympa.
[^] # Re: Meego/Android
Posté par JGO . Évalué à 2.
[^] # Re: Meego/Android
Posté par yostral . Évalué à 2.
Oui IntersectRaven, tout comme certains autres dev noyau Android (Wildmonk, Pershoot ...) optimisent pas mal de choses. Mais, sur chacun de leurs noyaux, avant et après ce patch uniquement, une différence se fait sentir.
Ça ne doit pas fonctionner sur tout, car visiblement, d'après les nombreux retours des différents fils de discussion là-dessus sur XDA, avec certains lanceurs (déjà très fluides à la base), avec certaines appli, ça n'a pas l'air de changer grand chose. Pourquoi, comment, je n'en sais foutre rien. Mais perso avec ADW launcher j'ai vu une sacrée différence !
# Cgroups
Posté par bubar🦥 (Mastodon) . Évalué à 1.
:))
Enfin... la doc aujourd'hui est limpide.
Android utilise les Cgroups par défaut.
Mais surtout Fedora, dans sa dernière version, inclue des utilitaires spécifiques ( voir http://fedoraproject.org/wiki/Features/ControlGroups et les outils installés de base :) )
Merci pour cette superbe dépêche, et au passage je ne savais que Mr Kolivas continuait de patcher :) deux bonnes nouvelles dans une seule dépêche :))
ps : maintenant, il ne manque plus que la délégation temporaire de priorité sur une application. Exemple : le pointeur reconfigure à chaud, et très temporairement, la priorité et le nice sur l'application sur laquelle il se trouve. Ainsi, même avec des proco chargés à fond, un "clique - lance appli" reste toujours très réactif.
De toutes façons les entrées standards locales clavier / souris devraient toujours avoir la haute main (prio, rtprio, nice). C'est pas croyable que l'entrée clavier rame parceque le système est chargé. Le gars là, en local, c'est à lui d'avoir la main :p
Linux c'est pas Solaris (mouhahaha... qui a déjà vu un solaris ramer à mort pour se logguer root parceque le sysadmin avait oublié de configurer root dans...bref :p)
[^] # Re: Cgroups
Posté par ckyl . Évalué à 4.
:))
> Enfin... la doc aujourd'hui est limpide.
Rassure moi c'est de l'ironie ?
C'est super comme concept, ca permet des trucs géniaux. Mais pour avoir implémenté un truc basé sur les cgroups y'a 3/6 mois c'est juste l'horreur. Tu passes une semaine au lieu d'une heure tellement la doc est pourrie, les fonctionnalités pas documentées, et la libcgroup jeune. Et ca devient encore plus drôle quand tu essayes de faire un soft qui s'auto-configure pour se limiter tout seul sans rien demander à l'utilisateur comme config système.
Je crois que je dois pas être le seul à le penser, quand on voit le code cgroup dans libvirt et comment il explose (ou explosait ? ) dans tout les sens.
[^] # Re: Cgroups
Posté par bubar🦥 (Mastodon) . Évalué à 1.
non c'était pas de l'ironie :(
m'enfin c'est sur la doc de cgroup (et son évolution, depuis un readme de 100 lignes au début, à aujourd'hui). Non pas sur la doc des outils redhat pour cela (que je n'ai même pas encore regardé, à peine un peu les outils, zéro sur la doc)
Et puis c'est pour du simple, pas question de faire un soft qui en tiendrait compte (d'ailleurs je ne vois pas l'intérêt de ça ? il me semblait qu'un des intérêts de cgroups était justement d'avoir ces conf possible point du vue système, sans que le dev de telle appli soit obligé de s'en pré-occuper).
Tout à fait la cible de ce patch auto_cgroup : bourrin avec un usage basique. Pas une configuration très fine de cgroup.
[^] # Re: Cgroups
Posté par bubar🦥 (Mastodon) . Évalué à 2.
[^] # Re: Cgroups
Posté par Pinaraf . Évalué à 3.
[^] # Re: Cgroups
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Cela impactera le système ensuite, où bien c'est vraiment juste pour le démarrage ? Sinon c'est plus systemd qu'il faut le nommer, mais system3d :)
[^] # Re: Cgroups
Posté par Pinaraf . Évalué à 8.
Sur ma debian j'ai activé systemd, et maintenant la vie me sourit j'ai plein de cgroups :)
La commande systemd-cgls liste les cgroups utilisés sous forme d'arborescence.
En voici un court extrait :
├ 2 [kthreadd]
├ 3 [ksoftirqd/0]
├ 6 [migration/0]
(blabla noyau)
├ 16896 [kworker/u:2]
├ user
│ ├ root
│ │ └ 5c
│ │ ├ 3586 su
│ │ ├ 3588 bash
│ └ moi
│ └ 2c
│ ├ 2193 -:0
│ ├ 2716 /bin/sh /usr/bin/startkde
│ ├ 2747 /usr/bin/ssh-agent /usr/bin/ck-launch-session /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
│ ├ 2750 /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde
(blabla mes processus)
└ systemd-1
├ 1 /bin/systemd
├ nfs-common.service
│ └ 15777 /sbin/rpc.statd
├ portmap.service
│ └ 15724 /sbin/portmap
├ kdm.service
│ ├ 1889 /usr/bin/kdm -config /var/run/kdm/kdmrc
│ ├ 1907 /usr/bin/X :0 vt7 -br -nolisten tcp -auth /var/run/xauth/A:0-QsrSzb
│ ├ 2697 dbus-launch --autolaunch 9d930b78559f3c00ceac5bb1478de8d9 --binary-syntax --close-stderr
│ └ 2698 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
(blabla les services système)
Les cgroups permettent/permettront de faire tout ce qu'on a dit de trop cool, mais par contre, j'avoue ne pas savoir les utiliser (même pas eu le temps de lire la doc).
Sur son blog, Lennart parle notamment des options OOMScoreAdjust, CPUSchedulingPolicy... dans les fichiers de configuration des services pour systemd. Ce qui apporte, il me semble, une flexibilité considérable.
Bien sûr, les plus malins diront "un double fork, et mon processus détaché sort du contrôle de systemd".... C'est pour ça que les cgroups sont utilisés : les enfants, même détachés, restent dans le cgroup.
[^] # Re: Cgroups
Posté par Antoine . Évalué à 2.
Comme sous Windows, chouette :)
[^] # Re: Cgroups
Posté par Pinaraf . Évalué à 3.
Par exemple tu peux imaginer rendre SSH super prioritaire, avoir un utilisateur guest le moins prioritaire possible, ton utilisateur à toi être plus prioritaire que certains services à la con...
Bref, tu peux configurer et choisir.
[^] # Re: Cgroups
Posté par ckyl . Évalué à 4.
Tu as des applis qui peuvent vouloir se limiter ou limiter leur processus fils automatiquement. Typiquement imagine un job scheduler. Le processus du scheduler est dans son cgroup et il créé un sous cgroup pour chaque job. Ca te permet de limiter la consommation CPU, mémoire, réseau ou d'attacher le job à un core donné. En cela les cgroups sont géniaux.
Bon dans le cas d'un job scheduler, tu peux te dire que tu peux faire la conf système et reposer sur des acquis. Mais quand tu veux faire un soft un peu plus généraliste ca devient un peu la guerre, entre l'interface via filesytem (c'est beaucoup plus pratique pour construire des applis stables et faire de la gestion d'erreur c'est bien connu...), le fait que c'est intégré différemment partout et souvent fait pour une bonne grosse conf statique root only, que la libcg est jeune, que tout est documenté plus ou moins à l'arrache de la doc noyaux jusqu'au outils de la libcg .
La techno est puissante, mais pour le moment ca reste jeune et bien linuxien dans l'esprit donc chiant à utiliser. Mais j'espère que c'est devenu mieux entre temps.
# Spoile !
Posté par barmic . Évalué à 4.
----------> []
(oui merci j'ai vu qu'ils fait parti des modérateurs de la dépêche)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Spoile !
Posté par Pinaraf . Évalué à 6.
Est-il nécessaire d'altérer le noyau pour cela ?
Lennart Pottering a prouvé qu'un équivalent est faisable très facilement avec quelques lignes dans le .bashrc : cela ne suffit-il pas à diminier l'intérêt de ce patch par rapport à une solution configurable plus finement ?
[^] # Re: Spoile !
Posté par Albert_ . Évalué à 1.
Par contre le patch de 200 lignes va probablement grossir ou du moins devenir plus versatile pour gerer autre chose que les tty mais ca c'est juste un sentiment.
[^] # Re: Spoile !
Posté par koxinga . Évalué à 5.
Pour l'utilisateur final, cela ne change rien du tout ! (enfin de toute façon, l'utilisateur il n'ouvre pas des terminaux pour lancer des applis hein !)
[^] # Re: Spoile !
Posté par ZeroHeure . Évalué à 2.
Because it's something we want to do it for all users, and for all shells, and make sure it gets done automatically. Including for users that have old distributions etc, and make it easy to do in one place.
And then you do it for all the other heuristics we can see easily in the kernel. And then you do it magically without users even having to _notice_.
cf http://lkml.org/lkml/2010/11/16/351
[J'extrait ces infos d'un commentaire ajouté par l'auteur à l'article cité plus haut sur http://www.webupd8.org/2010/11/alternative-to-200-lines-kern(...)]
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Spoile !
Posté par liberforce (site web personnel) . Évalué à 7.
Et je suis plutôt d'accord avec lui sur ce coup là.
[^] # Re: Spoile !
Posté par JGO . Évalué à 4.
[^] # Re: Spoile !
Posté par patrick_g (site web personnel) . Évalué à 6.
Quand on veut lancer une appli dans son cgroup à part pour ne pas qu'elle lague il suffirait de faire un clic droit "lancer dans un groupe séparé".
A mon avis ce serait la meilleure solution.
[^] # Re: Spoile !
Posté par daimrod . Évalué à 2.
Et pourquoi dans l'intégrer dans les DE et pas dans la couche en dessus, X ou Wayland ?
Parce que sinon cela signifie que tous les gestionnaires devront l'implémenter non ?
Genre moi avec xmonad, je devrais attendre que ça soit intégré ? Ou j'aurais encore un moyen pour l'activer et l'utiliser ?
[^] # Re: Spoile !
Posté par barmic . Évalué à 2.
newgroup make -j2000000
D'ailleurs peut être que ça existe déjà.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Spoile !
Posté par Pinaraf . Évalué à 7.
Tu dois pour l'utiliser
1) configurer un ensemble de groupes (en les nommant, par exemple un groupe "compilation barbare", un groupe "service ultra prioritaire"...) : fichiers de configuration /etc/cgrules.conf et /etc/cgconfig.conf
2) cgexec -g cpu,memory:compilation_barbare make -j 2000000
Bien sûr, tu peux imaginer créer à la volée des groupes, à l'aide de cgcreate.
[^] # Re: Spoile !
Posté par barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pas forcément cohérent Linus là
Posté par reno . Évalué à 3.
Mais la, ce changement du scheduler, apparemment Con Kolivas avait fait quelque-chose de similaire dans BFS et avait trouvé que cela induisait des regressions: apparemment certaines applications ont des bugs exposés par le changement du scheduler.
Si ces mêmes bugs sont rapportés sur le patch pour le Linux 'officiel' je pense que le patch ne sera jamais appliqué..
# Apprentissage
Posté par Shuba . Évalué à 4.
Ici, c'est le tty d'origine qui est utilisé pour déterminer les groupes. Est-ce qu'un système d'apprentissage ne serait pas envisageable? Par exemple, chaque nouveau process apparaît dans son propre groupe, donc bénéficie souvent d'opportunités pour prendre du temps CPU. En comptabilisant le pourcentage d'opportunités où il prend finalement ce temps CPU, on pourrait alors créer des groupes regroupant les process selon ces pourcentages.
Est-ce que ça semblerait bien, ou est-ce que ça serait plutôt une gène pour le système?
# Tiens linuxfr est vivant ?
Posté par tyoup . Évalué à -2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.