Pipo2 a écrit 144 commentaires

A mon avis les problèmes sont liés.
J'ai trouvé le plan dans les forums : désactiver RenderAccel mais c'est pas cool, c'est ce qui fait l'intérêt des pilotes Nvidia fermés.

J'ai trouvé un moyen : revenir en noyau 2.6.8 (celui de la Mdk 10.1) et réinstaller le dernier pilote à peu près stable (pour moi en tout cas) 6629 qui ne compile pas avec la nouvelle interface des modules du 2.6.11.

C'est assez boulant.

Dîtes moi, cher ami, s'il s'agit là d'une provocation ou si tout cela est sincère.

En terme de stabilité, même en admettant que tu aies eu un mauvaise expérience de Linux, je pense que la réputation de Windows (XP ou pas) est assez parlante. Linux en revanche me semble tenir le cap sur les performances et la stabilité.

Ne pouvant pas parler de Windows moi-même par expérience, je ne m'exprimerai que sur la base des commentaire que j'ai pu lire à ce sujet.

Par contre je sais que je suis personnellement un caractériel par rapport au fonctionnement de mon outil de travail. Si un jour Linux plante plusieurs fois à la suite ou pire, Kmail ou Kword, il est clair qu'après avoir détruit mon poste de travail à coup de pompes, j'installe BSD. C'est arrivé il y a 5 ans avec Windows NT4 (d'où du tout Linux, maison et boulot depuis) mais pas encore avec Linux (distribution Mandroux pour précision).

Juste pour parler de QoS (comme c'est bien dit), il me semble qu'aucun OS Microsoft ne permet quoi que ce soit dans ce domaine. De plus ceci est quelque chose qui relève du système et non des applications. Comparer un service offert par une application (alors que ce n'est pas son rôle), mal offert apparemment, sur un certain OS à un service qui n'est pas du tout offert sur un autre OS, c'est gonflé. Par dessus le marché, comparer le fonctionnement d'une commande en ligne sur un certain OS à quelque chose d'hypothétique sur un OS qui ne propose quasiment rien en ligne, c'est balaise.

Bref j'estime que Windows a pas mal de progrès à faire pour pouvoir être comparé à Linux et je te félicite d'avoir pu planter une machine Linux au point de devoir rebooter (pilote vidéo propriétaire peut-être non ?) et d'être en avance sur ton temps en comparant un système stable et bourré de fonctionnalités (sans parler de l'ergonomie de KDE) à un système toujours pas capable de fonctionner sans interface graphique, inmaintenable à distance (sérieusement) et infoutu d'exécuter plus de dix applications par jour sans manger la poussière (estimation bureautique).

Alors essaye d'entrer dans KDE avec le splash dit "Par défaut" dans kcontrol pour voir.

> Sans compter que, par exemple, réécrire un tri par tas (heapsort) en Python au lieu d'utiliser les fonctions intégrées, c'est complètement idiot.

C'est idiot en production mais lorsqu'il s'agit de mesurer les performances à travail équivalent peut-être pas. On tente de se mettre dans une situation au pire pour laquelle aucune fonction intégré n'existe.

Ce qui est peut-être idiot, c'est de comparer des développements en langage compilé et des développements dans des langages interprétés par des interpréteurs eux-mêmes développés dans un langage compilé, peut-être le même. Non ?

Tu estimes qu'Ocaml est à la fois plus agréable à écrire, mieux conçu et plus performant. Si tu as raison, je crois que tu tiens la réponse à ta question.

Il faut quand même se méfier des raisonnement logiques. On doit aussi tenir compte des parcs installés, de l'importance des communautés d'utilisateurs, éventuellement de l'existence d'un plus ou moins grand nombre d'API et de bibliothèques (encore que le partage de bibliothèques développées en des langages différents mais compilés reste assez simple hors problème de prototypage si on ne dispose pas du .h adapté au langage utilisé, ordre, stockage et format des arguments passés et peut-être d'autres détails). Il y a de l'inertie dans ce domaine. Exemple, il paraît que le Cobol est mort depuis 20 ans.

C'est curieux dans la mesure où souvent les instruction shell sont mappées sur des appel à des fonctions développées en C (pour le TCL au moins c'est certain).
En gros, les développeurs des interpréteurs sont plus compétents que les développeurs des codes C testés sur ce site. Ce n'est plus une mesure des performances induites par les langages à ce niveau.

Pourquoi 1,96 ?

Non, ce type de site mesure la qualité d'un résultat (un programme) selon des critères de vitesse d'exécution et d'occupation mémoire et classée suivant le langage utilisé pour produire le code.

Le temps de conception, la durée du développement, sa difficulté (temps de débuggage) et la maintenance soulèvent des problèmes de productivité et de coût de production. Ces problèmes ne sont tout simplement pas traités par le site.

Lorsqu'on doit faire un choix, je trouve pratique de disposer d'une base de donnée en ligne comme celle là qui donne une idée grossière sur l'un des critère (important à mon avis) à prendre en compte : les performances attendues du futur produit en fonction du langage de programmation utilisé. Il est clair que d'autres critères sont à examiner qui, suivant les contraintes, peuvent se révéler prépondérants mais ils ne sont manifestement pas du ressort de Shootout et on ne peut pas le leur reprocher.

Il est également à noter que de nombreux facteurs d'efficacité sur un projet ne sont même pas conditionnés par le langage utilisé (doit-on sous-traiter, quel outil de gestion du projet, du workflow, quel IDE, quel gestionnaire de versions, combien de développeurs utiliser pour diviser les délais, quelle contrepartie est acceptable en gestion du projet, quelle tolérance d'erreur au résultat, ...). Un site comme celui-ci n'a pas vocation à faire les choix à notre place mais veut donner un éclairage sur l'un des aspects techniques importants. Je trouve qu'il ne le fait pas mal dans la mesure où l'affichage des résultat est très customisable.

Ca va

Je sais pas si les perf sont bonnes mais en tout cas le flash est génial !

Je suis bluffé. Comme quoi les STL ne sont peut être pas si bien écrites. Juste un truc, le sys 0m0.000s me surprends un peu. C'est possible ça ?

> Tu reviendras discuter avec moi quand t'auras mue (et des poils sur la bite aussi).

J'ai bien regardé, les poils du sexe ne se situent pas sur la verge.
Demande à ton grand frère petit nain.

Ha oui ? Je suis vert. Regarde :

[root@web1 root]# time ./pipo
2280707264
3.12user 0.30system 0:03.70elapsed 92%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+39338minor)pagefaults 0swaps

C'est quand même pas si énorme non ?

En fait, si tu es Java maniaque, c'est *<bidule> qui devraient te choquer il me semble.

C'est clair, le plan stream c'est plantant. Il vaut mieux se rabattre sur les fonctions C type printf.

Zut, il manque tous les truc entre inférieur, supérieur. Bon, je reéssai :

#include <iostream>
#include <list>

class test {
public:
test() {
std::list<int> lst;
for (int i = 0 ; i < 10000000 ; i++) {
lst.push_back(i);
}

unsigned long res = 0;
for (std::list<int>::iterator i = lst.begin() ; i != lst.end() ; i++) {
res += *i;
}
std::cout << res << std::endl;
}
};

main()
{
test *tt = new test();
}

> Encore des arguments à la con...
Là, il n'y avait aucun argument. Je répondais avec mauvaise foi à un type basique

> "ben mieux que toi manifestement mais vu la quantité de >mémoire inutilement utilisée par les applis Java, je pense que tu >peux y arriver."
> J'ai beaucoup moins de fuites mémoires en java qu'en c++ !
Je ne parle pas de fuite mémoire (assimilable à un bug) mais d'occupation mémoire normale.

> Ca a dut m'arriver 3 fois dans ma carrière.
Ta vie.

>> "non, mal. Il faut référencer la mémoire (maintenir une table des blocs alloués), tester (mais quand) les références sur cette mémoire, décider si on peut ou ne peut pas libérer ou si on peut réutiliser cette mémoire pour une allocation utltérieure, ... Si c'est dur."
> Beh tout ça, c du temps de perdu... c boulot n'a plus à etre fait..
Je ne te le fais pas dire, c'est la description du boulot que réalise le garbage collector.

> enfin, venant d'un mec qui croit que make, c le tiptop
Ok bon, "make c'est nul", là ça ira ?

> , je me dis que tu as pas du souvent coder en java.
Supposition osée.

Et voyans ça ; mets dans pipo.cpp :

#include
#include

class test {
public:
test() {
std::list lst;
for (int i = 0 ; i < 10000000 ; i++) {
lst.push_back(i);
}

unsigned long res = 0;
for (std::list::iterator i = lst.begin() ; i != lst.end() ; i++) {
res += *i;
}
std::cout << res << std::endl;
}
};

main()
{
test *tt = new test();
}


Puis tape : g++ -o pipo pipo.cpp
Et puis : ./pipo

Tu trouves ce codage vraiment différent de ta classe Java ?
Et côté perf alors ?

>> Ben oui, c'est pas comme si c'était notre métier.
> nan, mon boulot c'est d'automatiser des traitements de donnees, pas de me casser les couilles a savoir si une variable va encore etre utilisee.
'fin chais pas, a une epoque ou les compilos etaient trop mauvais, on devait surement trouver des gens pour dire ca aussi.

Ha ben oui, t'es automatiseur de traitements de données mais pas casseur de mes couilles. C'est ça ?

>>> (inutile parce qu'une machine est capable de le faire,
>>mal
> ben mieux que la plupart des humains en tout cas, vu les fuites memoires qu'on rencontre un peu partout.

ben mieux que toi manifestement mais vu la quantité de mémoire inutilement utilisée par les applis Java, je pense que tu peux y arriver.

>>> c'est donc une tache mecanique toute conne),
>>Pas tant que ça apparemment
> ben si, c'est con : une machine arrive a le faire. Si c'est plus reference, tu liberes, c'est pas trop dur quand meme.

non, mal. Il faut référencer la mémoire (maintenir une table des blocs alloués), tester (mais quand) les références sur cette mémoire, décider si on peut ou ne peut pas libérer ou si on peut réutiliser cette mémoire pour une allocation utltérieure, ... Si c'est dur.

>>> Sur le debat : java c'est trop lent, j'ai envie de dire : trop lent pour faire quoi?
>>En l'occurence pour une application interactive sur poste de bureau (pas un Craig II)
> c'est marrant ce que tu dis, j'ai developpe deux applis desktop qui tournent parfaitement en java/swt.

Salut Dieu.

>>> Prenez eclipse (sous windows j'entends, la version linux est malheureusement trop lente a mon gout).
>>Hé ben voilà !
> he ben voila quoi? tu preferes voir le verre a moitie vide ou a moitie plein? en l'occurence, il est a moitie plein sous windows...

Windows ? Connais pas. Tout à l'heure j'étais sur Linuxfr mais j'ai dû glisser.

>>> A l'inverse, on peut aussi trouver des grosse merde lente en c++, tout comme on va trouver des bouses immonde en java et des foudres de guerre en c++.
>>while (1);
>>effectivement
> et sinon, t'as des arguments ou t'as eu la gaule en voyant un troll sur java et t'as fait une tache dans ton calecon?

Ha ok ! Un philosophe doublé d'un dialecticien. C'est intéressant mais là je ne poursuivrai pas car je suis cloué par le choc d'un argument aussi léché.

Le makefile c'est un art et un pur bonheur à écrire.
Quant à la différence Linux/OSX, tu rigoles !

Tout à fait, alors je répète : Hors troll anti Java, ...

> en 2005 on a autre chose a faire que de se farcir une gestion douloureuse et inutile de la memoire
Ben oui, c'est pas comme si c'était notre métier.

> (inutile parce qu'une machine est capable de le faire,
mal

> c'est donc une tache mecanique toute conne),
Pas tant que ça apparemment

> le temps perdu a l'execution est largement compense par le temps (et les cheveux, c'est que passe 30 piges, ca devient chauve un developpeur) economise par les developpeurs.
Ha ben oui, qu'est-ce qu'ils font chier, les utilisateurs à vouloir des applis qui tournent !

> Sur le debat : java c'est trop lent, j'ai envie de dire : trop lent pour faire quoi?
En l'occurence pour une application interactive sur poste de bureau (pas un Craig II)

> Prenez eclipse (sous windows j'entends, la version linux est malheureusement trop lente a mon gout).
Hé ben voilà !

> Qui pourrait dire au premier abord que c'est une appli java?
Toi apparemment.

> A l'inverse, on peut aussi trouver des grosse merde lente en c++, tout comme on va trouver des bouses immonde en java et des foudres de guerre en c++.
while (1);
effectivement

Hors troll anti Java, l'utilisation d'OOo sur un PIII 700 reste assez fastidieuse quand même (en tout cas avec Linux/KDE). Bon j'ai pas un PC de gamer mais bon c'est que de la bureautique quoi !
J'ai la foi mais elle est parfois mise à rude épreuve.

> Par contre, j'ai entendu dire que l'assembleur battait C#, C++ et Java à plat de coutures ;)
Non. Développer en assembleur, en tout cas en 80x86, est super fastidieux, long et bugogène. Le code obtenu est généralement plus optimisé que lorsqu'il est généré par un bête compilateur mais le rapport durée de développement/performances gagnées est monstrueux.

Le C++ est compilé pour produire un code machine de la même nature et au même titre que la compilation assembleur. Certaines petites portions de programme peuvent être développées en ASM en ligne dans le code C++ ce qui permet de profiter à la fois du confort de codage du C++ et des performances de l'assembleur sur les points cruciaux.

En revanche la production de code en pur C++ avec les STL est aussi rapide et, aux désallocation "delete" près, presqu'aussi sûr que la production de code Java. L'utilisation (à mon avis très naze mais je peux me tromper) de la bibliothèque gc permet en plus de ne pas avoir à libérer les ressources manuellement.

Sans aucun autre avantage que la qualité de sa syntaxe (que je reconnais assez sympa), Java impose une couche supplémentaire merdique ; la JVM qui interprète le byte code et dont la justification est super discutable. Pour enfoncer le clou par rapport à la portabilité supposée des applis Java, je pense qu'un code C ou C++ compilable par gcc peut être porté sur un nombre de systèmes assez important non ?

Le confort du développeur ne correspond pas forcément (et carrément pas dans ce cas) au confort de l'utilisateur.
Qu'est-ce qu'on veut ? Faire une application sans se fouler en développement et en débuggage ou une suite office utilisable sur un PC normal ?