Tout monde ne joue pas avec son PC. Par exemple moi.
Tout le monde n'a pas besoin d'"utiliser tous les centimètres de la carte qu'ils ont achetés". J'ai une vielle ATI sans rien (pas de 3D, XV) et j'en suis très content. J'aurais une NVidia, j'utiliserais 1 % de la carte car le reste je m'en fout.
Alors fesont une news dans la catégorie "gamers" (car ça intéressent des gens et il est plus sympa de s'éclater sur un PC sous GNU/Linux que sous Windows) mais j'aimerai qu'un site dédié au libre fasse moins de pub a des solutions proprios (voir l'épisode skipe).
J'aimerai un peu plus de news sur le driver libre que sur le driver proprio.
J'aimerai que des gens qui utilisent le driver libre donne leur avis sur le driver et dans quel type d'utilisation il est satisfesant. Histoire de faire un peu la promotion du driver libre qui le mérite bien.
Non, c'est pour le noyau. La stack des applis reste énorme (genre 1 Go).
> Aucune ne risque d'empiler plus de 4 ko de données ?
Pour le noyau il y a quelques problèmes avec certain drivers (comme Nvidia par exemple). Globalement il n'y a pas de problème puisque FC2 utilise 4KSTACK.
Mais c'est un faut problème car il y a aussi deux nouvelles stacks dont une pour les interruptions. J'ai un peu oublié les détails du truc mais il n'y a globalement pas de perte.
la pile noyau passe de 8k à 4k. Contrairement au apparence, on y perd pas. Il y a maintenant une pile spécifique pour les interruptions et aussi un troisième dont j'ai oublié l'utilité :-)
Prends n'importe qu'elle distribution rpm-based et on te fera pas chier, on te laisse faire et tu peux recompiler ton noyau.
Il y a des tonnes et des tonnes de personnes qui savent parfaitement ce que leur "grosse" distribution fait et qui en font ce qu'ils veulent avec. La distinction avec Gentoo, sourcemage, etc n'est vraiment pas là.
> globalement toujours la possibilité de faire ce qu'on veut
> SUN a un gros avantage sur les autres vendeurs de distribs linux : la notoriété, la crédibilité, etc. RedHat, Mandrake et les autres, c'est du linux, faut s'en méfier.
En sait trop rien mais voilà peut-être des pistes.
Lors de l'installation, par défaut Fedora lance un serveur X11. Il est probable que le serveur soit configuré pour utiliser le moniteur et non la sortie tv. Malheureusement ce n'est pas modifiable.
Tu peux aussi faire une installation en mode texte. Lors de l'installation tape "texte" au premier prompt.
Pour que ça marche, tu es dépendant de la carte graphique. Il faut qu'elle soit suffisament "intelligente" pour remarquer qu'il n'y a pas de moniteur et utiliser la sortie TV. Ou activer la sortie tv et moniteur par défaut.
C'est passé inaperçu mais Fedora 2 a une solution élégante.
Le boot en parallèle permet de gagner du temps mais il a le défaut d'avoir un moins bon contrôle sur l'ordre de lancement des services et être plus confus dans l'affichage détaillé.
FC2 lance les script readahead_early readahead dès le début du boot. Ces scripts lancent en tache de fond le programme /usr/sbin/readahead. Sa fonction est simple : lire le début d'une liste de fichier. Ses fichiers sont normalement lu lors d'une séquence de boot et un login graphique.
La liste des fichiers à lire est établie avec un noyau spécial (utilisé uniquement en phase de développement) qui loggue tous les fichiers accédés.
Donc on a une boot séquenciel "classique" avec en parallèle des accès disques pour mettre en cache les prochains accès. Ça accélère significativement. Je gagne presque 10 secondes.
Je suis d'accord avec ta formulation. Le "certaines implementations" est très important.
On est loin des articles/benchs à l'origine de ce long thread : http://www.osnews.com/story.php?news_id=7372(...) Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby.
Lire les commentaires osnews avant de faire "amen".
Ben en langage C c'est "compilé" en bytecode natif.
T'as rien compris.
Le problème est de savoir comment fait l'optimiseur pour détecter si 'a' (dans f()) sera toujours à 0 ou non et ainsi appliquer une optimisation. C'est un exemple simpliste.
Exemple :
f(int a) {
while (a) { a-- ; [...] }
}
const int a = 0 ;
f(a) ;
f(a) ;
f(0) ;
Là le compilateur peux remarquer assez facilement que l'appel à f() ne fait rien et peu supprimer les appels à f().
Un autre exemple et là j'attends tes "lumières" :
f(int a) {
while (a) { a-- ; [...] }
}
h(int a) {
while (!a) { a++ ; [...] }
}
int a = 0 ;
g = f ;
p(&a) ;
g(a) ; // a : n'est pas connu à la compilation
a = read(stdin) ; // a : n'est pas connu à la compilation
conpute_it_with(chose_randomly(g,h)) ; // a : n'est pas connu à la compilation et f() n'est peut-être pas appelé...
Là pour savoir si f() est toujours appelé avec en paramètre 0, c'est impossible.
Et si c'est possible avec une compilation "dynamique" j'aimerai que tu m'expliques.
Et quelque chose de plus consistant que "parce que c'est déjà "précompilé" en bytecode"
> Ce n'est pas parce que tu le penses que ce n'est pas le cas.
Ben montres moi un bench avec java qui n'utilise pas les fonctions de haut-niveau de la VM.
Par exemple un bench avec un tri bulle écrit en java (c'est à dire sans utiliser de fonctions C de la VM qui font le tri).
Tu peux aussi choisir la manipulation de chaine de caratère, la recherche dans une liste, etc... T'es libre. Mais que du java et pas du java qui utilise une librairie écrite en C (généralement dans la VM).
> J'invite tout le monde à coder une implémentation d'algorithme de hashage
Les fonctions de hashage utilisées lors des benchs java sont celle de la VM et elles sont écrites en .... devines .... en C :-)
Si t'as beaucoup de donnée et utilise des fonctions de haut niveau (comme changer lors de tri, fusionner des grosses listes, etc), tu te retrouves à comparer des fonctions de hashage, tri, etc écritent en C. Pas de quoi conclure sur java mais seulement sur la différence d'implémentation des fonctions en C.
Par contre un comparatif java/C avec les fonctions de hackage, tri, etc écritent en java pour java et en C pour C, comme par hazard on en entend pas parler...
Bref, on ne compare pas deux languages mais des implémentations différentes de fonctions écritent en C.
> ATTENTION : je ne dis pas que Java rame
Moi non plus. Chaques technos a ces avantages et défauts.
> en Java il est possible de faire des optimisations dans la VM en cours d'exécution et donc de générer dynamiquement du code optimisé
Pour donner le fond de ma pensée : c'est du pipo de marketeux !
Je veux de concrêt. Trouves mois un cas concrêt où c'est possible. C'est-à-dire que l'analyse ET l'optimisation supplémentaire ne coût pas plus cher qu'une optimisation "statique" aux petits oignons par le compilateur "statique" (il a le temps de faire l'optimisation lui...). Comme je l'ai dit ailleur je ne vois pas ce que peut apporter cette optimisation "dynamique". Si tu peux répondre à l'autre post sans pipo marketeux, c'est un plus.
btw, si l'optimisation est faite qu'une seule fois (comme souvent dit ici), je ne vois pas en quoi c'est dynamique !
> il est tout à fait possible que dans *certains* cas un programme Java soit plus rapide que le même proramme en C/C++
Si celà arrive, c'est seulement la preuve que le compilateur C n'est pas bon ou que le code C équivalent à la fonctionnalité java n'est pas top. Point barre.
Lis les commentaires de la news osnews : http://www.osnews.com/comment.php?news_id=7372&limit=no#249529(...) g++ lost fibo, hash2, methcall narrowly (scored between the 2 jvm's in all cases)
g++ won heapsort, objinst, sieve narrowly
g++ won hash, ackerman, strcat, matrix by 1.4 - 3x faster
g++ won nestedloop, random by 6x - 7x.
Et ça sur des tests qui sont sensés montrer la supériorité de java. Alors en usage général... Tiens donnes UN programme de la "vie réelle" ou java tourne plus vite.
Si g++ ne "gagne" pas pour les premiers tests, c'est de peu.
De plus, on ne connais pas les fonctions écritent en C qui sont utilisées par java et qui sont peut-être mieux foutu que le code C utilisé pour le bench de g++ (ya pas les source jdk). Et oui, java utilise des fonctions dans la VM qui sont écrites en C.
Ce que peut faire Java, le compilateur C peut le faire et à coût 0 lors de l'utilisation.
> tu peux imaginer une analogie simple avec les bases de données qui te permettent de faire des statistiques en cours de fonctionnement sur tes données pour en optimiser les chemins d'accès
C'est de l'analyse de données qui sont DYNAMIQUE !
Que je sache, je code java n'est pas dynamique. Où alors c'est un sacré bordel à programmer et forcément lent (il faut systématiquement optimiser à nouveau un code qui change).
> En revanche, Java utilisera à coup sur tjs plus de mémoire que le même programme en C/C++.
Et donc il passe du temps à "brasser" plus de données, le cache cpu est moins heureux, etc. Belle optimisation.
J'ai vu un test qui montrait que ne plus mettre certaines fonctions réseaux _inline_ dans le noyau permettait un gain significatif de performance simplement car le cache du cpu est moins stressé. Et pourtant _inline_ sur le papier c'est mignon.
> Mais bien sur le profil de test peut être partiellement different de l'usage réel.
Je ne suis pas un spécialiste en compilateur ni en java. Mais j'ai un sérieux doute sur le fait d'avoir une meilleur optimisation si c'est fait à la volée.
Lorsque que tu optimises un bloque tu vas brosser plusieurs scénarios en fonction des variables dans ce bloque. Cette analyse est aussi pertinente lors d'une compilation à la volée qu'en "statique". Si 'a' est une variable à l'entrée du bloque elle le sera toujours que la compilation soit faite à la volée ou en statique. Le compilateur a la volé ne peut pas suposer que 'a' sera toujours à 0 à l'entrée du bloque et adapté l'optimisation. Idem pour le compilateur "statique".
Exemple naïf :
f(a) {
while (a) {
a-- ;
[...]
}
Si 'a' est à 0 la fonction ne fait rien. Comment peut faire le compilateur à la volée pour savoir que 'a' sera toujours à 0 à l'entrée de la fonction ? Même problème pour le compilateur "statique".
Le deux type de compilation ne peuvent pas le savoir à moins que ce soit des cas très simple genre il n'y a que des appels à f(0). Mais même ce cas est très difficile a détecter avec les pointeurs de fonction par exemple ou les plug-ins chargés à la demande et qui appèlent f() . N'envisagons pas le cas où la valeur de 'a' est fixé par un autre thread ou processus ou une entrée/sortie. Même en rêve c'est impossible.
Je fais des tests unitaires. Faut pas rêver.
Les tests sont indispensables et c'est un "art". Les mailings de developpement sont pleins d'exemples de la difficulter de faire des bons tests pour tracker un bug obscur.
> Et bien non, le bytecode de Java et celui de C# sont compilés au vol.
Interprété, compilé, machiné, bidulé, trucmuchiné, le problème n'est pas là. Il y a une étape supplémentaire par rapport à du C lors de l'excution.
> Code dans les inombrables buffer overflow qui pourissent la sécurité des applications standards ?
Très bon exemple, merci. Les buffer overflow sont TRÈS RARES par rapport à tous les autres bugs d'une application en C. Puis amuses à compter les trous de sécurité par buffer overflow par rapport à l'ensemble des trous de sécurité des applis écrite en C et je ne serais pas étonné que ça fasse moins de 5 %. Par contre ils sont effectivement très génant lorsque ça permet d'attaquer un segment exécutable. Mais c'est en passe de s'arranger avec exec-shield ou NX.
Je recentre encore le "débat", je ne discute pas des divers avantages de java mais uniquement de la vitesse. Et plus particuliairement du "java est plus rapide que le C".
> Java en tant que technologie présente des avantages sympas
Je ne reproche rien à Java et je ne dis pas qu'il est lent compte-tenu de ces avantages. Mais j'en ai marre de lire tous les mois un bench donc la conclusion est "java est plus rapide que le C et le C++". Ceci est techniquement impossible. Ou alors le compilateur C est loin d'être au point.
J'utilise aussi des langages interprétés avec beaucoup de bonheur (python, php). Mon propos n'est pas de dissuader les gens d'utiliser java (sauf pour l'aspect un petit peu proprio de java).
Tu codes beaucoup en C pour affirmer que mon affirmation est fausse ?
Si tu parles de déréférencement de pointeur après un free(), voire pas alloué du tout, ou de fuite de mémoire, je veux bien te croire que ça arrive souvent en C. Mais des débordements quand tu codes proprement (et sans forcer) c'est assez rare et souvent des erreurs de nouveaux (oublie d'ajouter '\0', manque un "+1" après un strlen(), utilisation d'un fonction qui n'est pas "safe", etc).
Pour avoir beaucoup codé en C, les erreurs sont très souvent ailleurs. Par contre au début ça arrive assez souvent.
J'espère que quelqu'un qui code beaucoup en C pourras te le confirmer.
la phase "gcc hello.c" il faut que la jvm la fasse. C'est du boulot, ça bouffe de la mémoire. "gcc hello.c" n'est fait qu'une seul fois en C et rarement par l'utilisateur. C'est un fait.
Je répète pour la 20 000 ième fois. J'ai rien contre Java. Ce qui m'énerve c'est d'entendre que Java est plus rapide que le C ou le C++. C'est tout.
Si on me trouve un navigateur web écrit en java aussi complet que gecko et aussi rapide j'y réfléchirai un peu plus.
Mais il n'y a pas une seule applis une peu "lourde" qui tourne plus vite en java qu'en C ou C++. Mais si je me trompe n'hésitez pas à me donner des exemples.
> Tu as la garantie que l'autre application ne pourra pas écrire dans ta mémoire.
Je répète encore : je ne parle QUE de vitesse.
D'accord, la vitesse c'est pas tout dans un langage. Mais je ne parle que de vitesse.
> Et qui te garantie que tu as prevu tous les cas d'utilisation...
Pssss.
T'inquiète pas, je sais coder en C et des applis qui tournent 24/24h 7/7j 365j/an (appli résidante de suivi de production).
> A t'endendre les bugs n'existeraient pas.
A t'entendre les bugs c'est toujours des débordements...
Les débordements sont souvents les trucs les plus faciles à détecter (au moins avec dmalloc).
Et ne t'en déplaise, c'est une pratique très courrante en développement C.
De plus quand tu codes proprement, tu ne fais pas des tableaux (avec des hideux "#define MAX_ELTS") mais des listes chainées et tu utilises malloc. Les cas de débordement sont très rare et les problèmes sont dans 99 % cas ailleurs.
[^] # Re: News
Posté par 007 . En réponse au journal Pilotes nvidia 6106. Évalué à -7.
Tout le monde n'a pas besoin d'"utiliser tous les centimètres de la carte qu'ils ont achetés". J'ai une vielle ATI sans rien (pas de 3D, XV) et j'en suis très content. J'aurais une NVidia, j'utiliserais 1 % de la carte car le reste je m'en fout.
Alors fesont une news dans la catégorie "gamers" (car ça intéressent des gens et il est plus sympa de s'éclater sur un PC sous GNU/Linux que sous Windows) mais j'aimerai qu'un site dédié au libre fasse moins de pub a des solutions proprios (voir l'épisode skipe).
# News
Posté par 007 . En réponse au journal Pilotes nvidia 6106. Évalué à 2.
J'aimerai que des gens qui utilisent le driver libre donne leur avis sur le driver et dans quel type d'utilisation il est satisfesant. Histoire de faire un peu la promotion du driver libre qui le mérite bien.
[^] # Re: 4kstack
Posté par 007 . En réponse au journal Nouveaux drivers nvidia 1.0-6106 - IA 32. Évalué à 0.
Non, c'est pour le noyau. La stack des applis reste énorme (genre 1 Go).
> Aucune ne risque d'empiler plus de 4 ko de données ?
Pour le noyau il y a quelques problèmes avec certain drivers (comme Nvidia par exemple). Globalement il n'y a pas de problème puisque FC2 utilise 4KSTACK.
Mais c'est un faut problème car il y a aussi deux nouvelles stacks dont une pour les interruptions. J'ai un peu oublié les détails du truc mais il n'y a globalement pas de perte.
[^] # Re: 4stack ?
Posté par 007 . En réponse au journal Drivers nvidia compatibles avec les kernels 4kstack. Évalué à 3.
# 4kstack
Posté par 007 . En réponse au journal Nouveaux drivers nvidia 1.0-6106 - IA 32. Évalué à 0.
Enfin compatible avec FC2 et linux >= 2.6.7 avec 4kstack.
NB : 8kstack va être viré dans quelques mois.
[^] # Re: autre idée
Posté par 007 . En réponse au journal idée : Un kernel qui boute plus vite. Évalué à 1.
Prends n'importe qu'elle distribution rpm-based et on te fera pas chier, on te laisse faire et tu peux recompiler ton noyau.
Il y a des tonnes et des tonnes de personnes qui savent parfaitement ce que leur "grosse" distribution fait et qui en font ce qu'ils veulent avec. La distinction avec Gentoo, sourcemage, etc n'est vraiment pas là.
> globalement toujours la possibilité de faire ce qu'on veut
là je suis d'accord :-)
[^] # Re: Et un vrai système de boot plus rapide?
Posté par 007 . En réponse au journal idée : Un kernel qui boute plus vite. Évalué à 0.
Donc pas de gain significatif à attendre avec python au-lieu de bash.
[^] # Re: Je me demande ce qui nous attends
Posté par 007 . En réponse au journal Microsoft perd un contrat à Sun.... Évalué à 4.
Pour RedHat c'est très loin d'être évident et de plus sur le marché des serveurs qui est assez influencé par l'image.
D'ailleur l'un des sports favoris de Sun ces derniers temps est de FUDer sur Red Hat.
Exemples (un coup de google rapide) :
http://www.eweek.com/article2/0,1759,1601495,00.asp(...)
http://techupdate.zdnet.com/techupdate/stories/main/Sun_Red_Hat_gir(...)
# Re:
Posté par 007 . En réponse au message Installation sur une machine reliee a la TV. Évalué à 1.
En sait trop rien mais voilà peut-être des pistes.
Lors de l'installation, par défaut Fedora lance un serveur X11. Il est probable que le serveur soit configuré pour utiliser le moniteur et non la sortie tv. Malheureusement ce n'est pas modifiable.
Tu peux aussi faire une installation en mode texte. Lors de l'installation tape "texte" au premier prompt.
Pour que ça marche, tu es dépendant de la carte graphique. Il faut qu'elle soit suffisament "intelligente" pour remarquer qu'il n'y a pas de moniteur et utiliser la sortie TV. Ou activer la sortie tv et moniteur par défaut.
> Je vais bientot installer Fedora Core 1
Fedora Core 2 est dispo depuis plusieurs semaines :-)
http://linuxfr.org/2004/05/19/16296.html(...)
[^] # Re: idée : Un kernel qui boute plus vite
Posté par 007 . En réponse au journal idée : Un kernel qui boute plus vite. Évalué à 4.
Le boot en parallèle permet de gagner du temps mais il a le défaut d'avoir un moins bon contrôle sur l'ordre de lancement des services et être plus confus dans l'affichage détaillé.
FC2 lance les script readahead_early readahead dès le début du boot. Ces scripts lancent en tache de fond le programme /usr/sbin/readahead. Sa fonction est simple : lire le début d'une liste de fichier. Ses fichiers sont normalement lu lors d'une séquence de boot et un login graphique.
La liste des fichiers à lire est établie avec un noyau spécial (utilisé uniquement en phase de développement) qui loggue tous les fichiers accédés.
Donc on a une boot séquenciel "classique" avec en parallèle des accès disques pour mettre en cache les prochains accès. Ça accélère significativement. Je gagne presque 10 secondes.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Je suis d'accord avec ta formulation. Le "certaines implementations" est très important.
On est loin des articles/benchs à l'origine de ce long thread :
http://www.osnews.com/story.php?news_id=7372(...)
Here is a comparison of a C and Java speech librarywhere the Java version is 2-3 times faster, with server VM configuration. And here are some more C++ and java comparisons, with various algorithms. Elsewhere, Java 1.5 is 20% faster than C says JavaLobby.
Lire les commentaires osnews avant de faire "amen".
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Ben en langage C c'est "compilé" en bytecode natif.
T'as rien compris.
Le problème est de savoir comment fait l'optimiseur pour détecter si 'a' (dans f()) sera toujours à 0 ou non et ainsi appliquer une optimisation. C'est un exemple simpliste.
Exemple :
f(int a) {
while (a) { a-- ; [...] }
}
const int a = 0 ;
f(a) ;
f(a) ;
f(0) ;
Là le compilateur peux remarquer assez facilement que l'appel à f() ne fait rien et peu supprimer les appels à f().
Un autre exemple et là j'attends tes "lumières" :
f(int a) {
while (a) { a-- ; [...] }
}
h(int a) {
while (!a) { a++ ; [...] }
}
int a = 0 ;
g = f ;
p(&a) ;
g(a) ; // a : n'est pas connu à la compilation
a = read(stdin) ; // a : n'est pas connu à la compilation
conpute_it_with(chose_randomly(g,h)) ; // a : n'est pas connu à la compilation et f() n'est peut-être pas appelé...
Là pour savoir si f() est toujours appelé avec en paramètre 0, c'est impossible.
Et si c'est possible avec une compilation "dynamique" j'aimerai que tu m'expliques.
Et quelque chose de plus consistant que "parce que c'est déjà "précompilé" en bytecode"
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à -3.
Ben montres moi un bench avec java qui n'utilise pas les fonctions de haut-niveau de la VM.
Par exemple un bench avec un tri bulle écrit en java (c'est à dire sans utiliser de fonctions C de la VM qui font le tri).
Tu peux aussi choisir la manipulation de chaine de caratère, la recherche dans une liste, etc... T'es libre. Mais que du java et pas du java qui utilise une librairie écrite en C (généralement dans la VM).
Bonne chance...
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Les fonctions de hashage utilisées lors des benchs java sont celle de la VM et elles sont écrites en .... devines .... en C :-)
Si t'as beaucoup de donnée et utilise des fonctions de haut niveau (comme changer lors de tri, fusionner des grosses listes, etc), tu te retrouves à comparer des fonctions de hashage, tri, etc écritent en C. Pas de quoi conclure sur java mais seulement sur la différence d'implémentation des fonctions en C.
Par contre un comparatif java/C avec les fonctions de hackage, tri, etc écritent en java pour java et en C pour C, comme par hazard on en entend pas parler...
Bref, on ne compare pas deux languages mais des implémentations différentes de fonctions écritent en C.
> ATTENTION : je ne dis pas que Java rame
Moi non plus. Chaques technos a ces avantages et défauts.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Pour donner le fond de ma pensée : c'est du pipo de marketeux !
Je veux de concrêt. Trouves mois un cas concrêt où c'est possible. C'est-à-dire que l'analyse ET l'optimisation supplémentaire ne coût pas plus cher qu'une optimisation "statique" aux petits oignons par le compilateur "statique" (il a le temps de faire l'optimisation lui...). Comme je l'ai dit ailleur je ne vois pas ce que peut apporter cette optimisation "dynamique". Si tu peux répondre à l'autre post sans pipo marketeux, c'est un plus.
btw, si l'optimisation est faite qu'une seule fois (comme souvent dit ici), je ne vois pas en quoi c'est dynamique !
> il est tout à fait possible que dans *certains* cas un programme Java soit plus rapide que le même proramme en C/C++
Si celà arrive, c'est seulement la preuve que le compilateur C n'est pas bon ou que le code C équivalent à la fonctionnalité java n'est pas top. Point barre.
Lis les commentaires de la news osnews :
http://www.osnews.com/comment.php?news_id=7372&limit=no#249529(...)
g++ lost fibo, hash2, methcall narrowly (scored between the 2 jvm's in all cases)
g++ won heapsort, objinst, sieve narrowly
g++ won hash, ackerman, strcat, matrix by 1.4 - 3x faster
g++ won nestedloop, random by 6x - 7x.
Et ça sur des tests qui sont sensés montrer la supériorité de java. Alors en usage général... Tiens donnes UN programme de la "vie réelle" ou java tourne plus vite.
Si g++ ne "gagne" pas pour les premiers tests, c'est de peu.
De plus, on ne connais pas les fonctions écritent en C qui sont utilisées par java et qui sont peut-être mieux foutu que le code C utilisé pour le bench de g++ (ya pas les source jdk). Et oui, java utilise des fonctions dans la VM qui sont écrites en C.
Ce que peut faire Java, le compilateur C peut le faire et à coût 0 lors de l'utilisation.
> tu peux imaginer une analogie simple avec les bases de données qui te permettent de faire des statistiques en cours de fonctionnement sur tes données pour en optimiser les chemins d'accès
C'est de l'analyse de données qui sont DYNAMIQUE !
Que je sache, je code java n'est pas dynamique. Où alors c'est un sacré bordel à programmer et forcément lent (il faut systématiquement optimiser à nouveau un code qui change).
> En revanche, Java utilisera à coup sur tjs plus de mémoire que le même programme en C/C++.
Et donc il passe du temps à "brasser" plus de données, le cache cpu est moins heureux, etc. Belle optimisation.
J'ai vu un test qui montrait que ne plus mettre certaines fonctions réseaux _inline_ dans le noyau permettait un gain significatif de performance simplement car le cache du cpu est moins stressé. Et pourtant _inline_ sur le papier c'est mignon.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Je ne suis pas un spécialiste en compilateur ni en java. Mais j'ai un sérieux doute sur le fait d'avoir une meilleur optimisation si c'est fait à la volée.
Lorsque que tu optimises un bloque tu vas brosser plusieurs scénarios en fonction des variables dans ce bloque. Cette analyse est aussi pertinente lors d'une compilation à la volée qu'en "statique". Si 'a' est une variable à l'entrée du bloque elle le sera toujours que la compilation soit faite à la volée ou en statique. Le compilateur a la volé ne peut pas suposer que 'a' sera toujours à 0 à l'entrée du bloque et adapté l'optimisation. Idem pour le compilateur "statique".
Exemple naïf :
f(a) {
while (a) {
a-- ;
[...]
}
Si 'a' est à 0 la fonction ne fait rien. Comment peut faire le compilateur à la volée pour savoir que 'a' sera toujours à 0 à l'entrée de la fonction ? Même problème pour le compilateur "statique".
Le deux type de compilation ne peuvent pas le savoir à moins que ce soit des cas très simple genre il n'y a que des appels à f(0). Mais même ce cas est très difficile a détecter avec les pointeurs de fonction par exemple ou les plug-ins chargés à la demande et qui appèlent f() . N'envisagons pas le cas où la valeur de 'a' est fixé par un autre thread ou processus ou une entrée/sortie. Même en rêve c'est impossible.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Les tests sont indispensables et c'est un "art". Les mailings de developpement sont pleins d'exemples de la difficulter de faire des bons tests pour tracker un bug obscur.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Interprété, compilé, machiné, bidulé, trucmuchiné, le problème n'est pas là. Il y a une étape supplémentaire par rapport à du C lors de l'excution.
> Code dans les inombrables buffer overflow qui pourissent la sécurité des applications standards ?
Très bon exemple, merci. Les buffer overflow sont TRÈS RARES par rapport à tous les autres bugs d'une application en C. Puis amuses à compter les trous de sécurité par buffer overflow par rapport à l'ensemble des trous de sécurité des applis écrite en C et je ne serais pas étonné que ça fasse moins de 5 %. Par contre ils sont effectivement très génant lorsque ça permet d'attaquer un segment exécutable. Mais c'est en passe de s'arranger avec exec-shield ou NX.
Je recentre encore le "débat", je ne discute pas des divers avantages de java mais uniquement de la vitesse. Et plus particuliairement du "java est plus rapide que le C".
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Je te béni pour ta démarche.
> Java en tant que technologie présente des avantages sympas
Je ne reproche rien à Java et je ne dis pas qu'il est lent compte-tenu de ces avantages. Mais j'en ai marre de lire tous les mois un bench donc la conclusion est "java est plus rapide que le C et le C++". Ceci est techniquement impossible. Ou alors le compilateur C est loin d'être au point.
J'utilise aussi des langages interprétés avec beaucoup de bonheur (python, php). Mon propos n'est pas de dissuader les gens d'utiliser java (sauf pour l'aspect un petit peu proprio de java).
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Je peux pas non.
> mais pour ces algo c'est la realité.
Même pas. Lis les commentaires :
http://www.osnews.com/comment.php?news_id=7372&limit=no(...)
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à -1.
Tu codes beaucoup en C pour affirmer que mon affirmation est fausse ?
Si tu parles de déréférencement de pointeur après un free(), voire pas alloué du tout, ou de fuite de mémoire, je veux bien te croire que ça arrive souvent en C. Mais des débordements quand tu codes proprement (et sans forcer) c'est assez rare et souvent des erreurs de nouveaux (oublie d'ajouter '\0', manque un "+1" après un strlen(), utilisation d'un fonction qui n'est pas "safe", etc).
Pour avoir beaucoup codé en C, les erreurs sont très souvent ailleurs. Par contre au début ça arrive assez souvent.
J'espère que quelqu'un qui code beaucoup en C pourras te le confirmer.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
la phase "gcc hello.c" il faut que la jvm la fasse. C'est du boulot, ça bouffe de la mémoire. "gcc hello.c" n'est fait qu'une seul fois en C et rarement par l'utilisateur. C'est un fait.
Je répète pour la 20 000 ième fois. J'ai rien contre Java. Ce qui m'énerve c'est d'entendre que Java est plus rapide que le C ou le C++. C'est tout.
Si on me trouve un navigateur web écrit en java aussi complet que gecko et aussi rapide j'y réfléchirai un peu plus.
Mais il n'y a pas une seule applis une peu "lourde" qui tourne plus vite en java qu'en C ou C++. Mais si je me trompe n'hésitez pas à me donner des exemples.
> Tu as la garantie que l'autre application ne pourra pas écrire dans ta mémoire.
Je répète encore : je ne parle QUE de vitesse.
D'accord, la vitesse c'est pas tout dans un langage. Mais je ne parle que de vitesse.
[^] # Re: Excellent
Posté par 007 . En réponse à la dépêche Le code de Java3D est disponible. Évalué à 0.
Pssss.
T'inquiète pas, je sais coder en C et des applis qui tournent 24/24h 7/7j 365j/an (appli résidante de suivi de production).
> A t'endendre les bugs n'existeraient pas.
A t'entendre les bugs c'est toujours des débordements...
Les débordements sont souvents les trucs les plus faciles à détecter (au moins avec dmalloc).
Et ne t'en déplaise, c'est une pratique très courrante en développement C.
De plus quand tu codes proprement, tu ne fais pas des tableaux (avec des hideux "#define MAX_ELTS") mais des listes chainées et tu utilises malloc. Les cas de débordement sont très rare et les problèmes sont dans 99 % cas ailleurs.
[^] # Re: amule
Posté par 007 . En réponse au message xmule se ferme tous seul et amule aussi un idée ?. Évalué à 0.
Ah oui. Désolé.
J'ai fait un "yum search mule", j'ai obtenu :
Available package: amule.i386 0:1.2.6-0.lvn.1.2 from Fedora Extras (non-US) - stable
et je n'ai pas fait attention au "(non-US)".
btw : pas si "stable" que ça apparament :-)
[^] # Re: Commentaire
Posté par 007 . En réponse au journal Une mise à jout de Skype. Évalué à -3.
Si IE est porté sous Linux tu vas aussi nous faire de la pub pour IE car tu pourras aller sur les site "optimisé pour IE" de tes pôtes ?
Ton raisonnement ne tient pas deux secondes.
Que skype soit porté sous Linux c'est bien comme il est bien que flash existe sous Linux.
MAIS CE N'EST PAS UNE RAISON POUR FAIRE DE LA PUB A DES SOLUTIONS PROPRIOS !
Surtout sur un site consacré au libre.