iug a écrit 501 commentaires

D'ailleurs, je faisait même tourner du traitement temps-réel de son sur Ardour sous Gnome 2.4 (Mandrake 9.2 ou 10.0) avec la même machine.

Si tu fais une compile ou une mise à jour de distrib, la réactivité se mesure plus pareil. La c'est d'abord la connec Internet, puis les disques, puis la quantité de RAM et enfin le proc qui joue.

Niveau réactivité mes un QNX ou un RT Linux :)

Mon céléron 433 sous Gnome 2.4 était lui aussi très réactif...

JE viens de lire un SPEC, un G5 2GHz est 10% plus lent qu'un Xéon 3 GHz en entier et 15% plus rapide en flotant.

Donc il se fait larguer par un P4 3.8 GHz ou un Athlon 64 dernier cri.

Etant donnée la philosophie Apple, excécrable (ITMS...), je resterais au "free as in freedom" c'est sûr. Après, pourquoi pas OSX pour remplacer Windows dans mon dual boot, pour les softs de zik par exemple.

Je plussoie, Intel à des reins solides et peut se permettre de payer beaucoup plus chers ces développements.

Et puis, ils sont contraints à la compatibilité arrière, donc ils ont jamais vraiement pu passer au RISC, mêmes si leurs archis actuelles sont un peu hybrides.

C'est clair que Apple va perdre la face, parce que "les qualités du au PPC" n'étaient que du vent Marketing. Les G5 n'ont jamais été vraiement plus rapides que les procs x86, ni les G4.

D'ailleurs c'est la deuxième fois qu'ils font le coup d'abandonner un proc pour sa lenteur : y'a déjà eu ces bouses de G4, qui valaient le coup à leur sortie mais n'ont jamais scalé, maintenant c'est la future lenteur des G5. HUHU

Heureusement qu'ils avaient un public de fans conquis pour ne pas porter un regard critique sur leurs procs.

L'avantage principal du Risc par rapport au Cisc est pour les conepteurs de puces : c'est plus simple.

Niveau perfs c'est autre chose. Par exemple, la philosohie Risc c'est de n'avoir que des instructions simples, qui ne travaillent que sur des registres (du point de vue du code assembleur) etc... Les instructions façons Altivec/SSE/3DNow, c'est tout le contraire du Risc, et c'est vachement bien pour les perfs. De mêmes, les antiques "REP MOVS" du jeu d'instruction Intel ont pendant longtemps boosté les perfs de nos vieux 286 et 386.

On pourrait mettre en place un site web de paris sur la date de sortie de la release suivante. Les gains engrangés par le site pourraient financer des bounties qui permettraient d'égaler MacOS X, qui va concurrencer Debian.

Une bonne daube façon Yann Tiersen surement....

Exactement, je suis contre le contenu des vieux traités, donc je vote non.

En ne sélectionnant que le sous-ensemble implémenté par tous les langages cités voilà le résulta :

1er C Intel 34
2eme C GCC 31
3eme Ocaml 22
5eme C# Mono 13
6eme Java 11

PS: inclure les C++ aurait néxessiter de désactiver trop de benchs

Ceux qui auront suivi/participé au troll Java v.s C# comprendront qu'ils feraient mieux de se mettre à OCaml s'ils cherchent un langage à la fois puissant et performant. Si tant est qu'on peut qualifier les deux derniers de puissant quand on les compare à OCaml lol.

C'est 99,99% de tes cas...

Tu peux dire tout et n'importe quoi là dessus. C'est là que le débat est un gros troll.

Java c'est bien pour faire du code dont les perf sont secondaires. Le seul problème c'est de l'utiliser dans des cas où les perfs sont pas secondaires.

Ensuite supposer que les perfs sont secondaires ça devient vite une contrainte sur l'utilisation qui va être faite de ton appli. Prenons le cas d'une IHM. Si tu fais un petit soft avec trois boutons et deux textfields, ok Java c'est bien.

Par contre c'est pas envisageable d'avoir toutes tes applis en Java, window manager compris.

Même une IDE en Java, ça devient moyen. Tu te retrouves avec tes threads qui se font suspendre à tout bout de champs par les threads de l'IDE. T'as un overhead énorme quand tu fais du profiling....

Java aurais pu être bien pour faire du code de calcul en utilisant des structures évoluées si ils avaient un peu plus chiadé l'utilisation des types primitifs. En l'état actuel des choses c'est pas la peine.

Justement, c'est le GC qui est foireux. Ils devraient plutôt faire une analyse statique du code pour éliminer un maximum de cas ou les places des désalocations sont triviales, et laisser le GC traiter les allocations que l'ananlyse statique n'a pas su gérer.

Le problème de Java, ce sont justement ses concepteurs, qui n'ont rien à foutre des perfs.

Ils sont dans un trip tout blanc/tout noir mes en fait ils auraient pu développer un langage plus performant en passant sur des modifs minimes.

Je suis tout à fait d'accord avec toi, il ne faut pas croire.

Le seul truc c'est que dire que Java est plus rapide que C ou C++, c'est du pipo dans le cas général, même si dans beaucoup de cas c'est vrai. Tu arriveras souvent à plus d'efficacité en hard-codant en C des trucs présents sous formes plus génériques dans les api java.

Après le fameux bench qui traine chépaou où ils comparent les perfs sur un for(i=0;i<n;i++); c'est quand même du pipo (j'exagère sur le bout de code je sais, m'enfin ce sont des codes taillés sur mesure pour pas déclancher le GC en tout cas, sans allocation dynamique et tout).

M'enfin, parler perf, c'est parler compilateur/interpréteurs et pas langage.

En tant que langage, j'aime beaucoup java depuis sa version 5. Il me manque juste de l'ordre supérieur. En tout cas, c'est mon langage de prédilection, moi qui n'est fait que de l'objet pour ainsi-dire.

Après, c'est pareil si on confond langage et api, on peut partir sur de longs trolls sur Swing qui est à mon sens une daube sans nom. Ils ont réussi à faire une api à la fois complexe et fortement limitée. J'aurais préféré un truc simple et limité ou complexe et très puissant, mais là, ils ont de failles de designs, des bugs en pagaille...

Trollons, trollons :)

Et ben non, y'a jamais eu de facteur 10 en perf entre deux kernels, sur peut-être 99% des cas d'utilisation. Ou alors faut remonter à des versions de la préhistoire du noyau où ils avaient désactivé le cache lol.

De même entre deux versions consécutives de GCC.

Java, c'est pas rapide comme langage, intrinsèquement, y'a des gros problèmes qui font que dans beaucoup de cas d'utilisation c'est lent : y'a un GC dedans (non pas toi GC, toi t'es dans Perl :). Ex: fait un bench d'allocation avec des patterns spécififques de certains cas d'utilisation, et d'une JVM a l'autre tu verra des failles.

Effectivement, avec certaines JVM qui font du Just in Time, un for(i=0;i<n;i++) ; c'est aussi rapide qu'en C.

Et oui ça dépend...

Tu parles de quelle JVM ?

J'ai testé dans le temps, à l'époque du JDK 1.4 une démo graphique en Java, et ben elle tournait à 1-2 fps avec la JVM de Sun et à 20 fps sur la JVM de MS IE.

Avec un langage portable comme C ou C++ on aurait pas eu de telles différences entre les compilateurs.

C'est sympa, on va retrouver les vieilles traditions de pondre du code supplémentaire pour la portabilité.

Ile ne me semble pas que le langage soit adapté à l'utilisation de plusieurs vaiantes. En c/c++ on a un préprocesseur pour ça, mais en Java, comment va-t-on faire.

Des différences existeront à coup sûr entre le Java de GCJ et le Java de Sun. Il faudra se taper des appels à l'API de réflexivité pour voir quel compilo/interpréteur tourne et utiliser des paths différents dans le code pour ça.

Je préfère largement la formule avec préprocesseur, qui permet de voir du premier coup d'oeuil la différence entre le code de traitement et le code de portabilité.

Sinon, la communauté peut toujours créer un préprocesseur pour Java, qu'il faudrait utiliser pour générer des sources compatibles avec l'une ou l'autre des implémentations.

Ca serait comique, une innovation de la communauté qui permettrait d'améliorer la portabilité d'un langage marketé comme étant portable .

GC tu me sauves.

J'avais effectivement réussi à charger la vidéo dans kino, mais j'ai rien obtenu au bout de 10 minutes de clics à droite à gauche alors j'ai passé mon chemin. Cinellerra il plante au chargement du divx.

Ce que je veux surtout c'est de pas avoir à réencoder histoire de pas massacrer la qualité, quitte à passer le son en flac/wav et coller les deux flux dans un OGM.

PS: tu as vu l'épilogue de mon troll sur Java ? C'était un bug du jdk ou du driver :)

J'ai le même problème avec une vidéo avi dont le son est corrompu : il y'a un saut de quelques secondes au milieu. J'aimerais pouvoir exporter le son le cuter et le remettre dans la vidéo. Et ben aucun des softs avec IHM graphique que j'ai essayé n'étaient foutu de faire ça.

Je sais qu'on peut faire ça avec transcode mais ça va être le bordel. Surtout que je vais devoir tatonner. Itérer des (séparations des deux flux+recalage+intégration des flux) va me prendre un temps énorme.

Tu auras peut-être des problèmes sur d'autres OS ou avec ton BIOS mais les Linux récents n'utilisent pas le BIOS pour gérer l'IDE.

Sur mon Pentium 200 limité à 8 Go je mets des disques de 40 et 80 Go.

Le seul truc c'est de dire à ton BIOS que le disque fait moins de la taille limite en forçant l'un des types. Ensuite il faudra peut-être que ton lilo/grub soit sur la partie accessible par le BIOS.

>Et inutile de mettre en opposition chercheurs et ingénieurs, ils n'ont >pas le même boulot. La recherche, qu'elle soit fondamentale ou >appliqué, doit répondre à un NOUVEAU problème alors que >l'ingénierie doit résoudre un problème en utilisant
>la meilleur solution connue. C'est par exemple le travail d'un ingénieur >de transposer un résultat de recherche fondamentale en une solution >applicable...

Je ne suis pas d'accord, et dans la pratique c'est faux. Beaucoup, beaucoup beacoup même, dans des domaines dits fondamentaux comme dans des domaines dits appliqués, se contentent d'appliquer des techniques récentes à des problèmes, pas forcément nouveaux, mais non optimalement résolus.

Ex: le voyageur de commerce, ou tout le monde y va de son expérimentation en essayant telle ou telle méthode d'optimisation BIEN CONNUE.

Le fondamental dans cet exemple, ça voudrait dire inventer une nouvelle méthode, qui ne soit pas un mélange de deux ou trois approches existantes. Style le chercheur qui va inventer l'algo génétique pour résoudre son problème.

Entre ingénierie et recherche appliquée, il n'y pas de différence qualitative, juste quantitative. Un gars qui a fait une thèse dans un domaine aura surement une meilleure culture du problème, ce qui lui permettra de mieux utiliser l'existant pour résoudre un problème.

Un chercheur appliqué, c'est juste un très bon ingé.

'ortographe on s'en tape, maintenant on parle tous américains. Faut faire comme aux, au feeling l'ortographe.

De la recherche si c'est pour en faire des brevets dont MS aura l'exclusivité, on n'en verra jamais le jour avec l'un de nos chers OSs libres. Du coup, si elle n'existait pas ça serait pareil :) C'est même pire qu'elle existe cette recherche, car les brevets vont nous obliger à ne pas creuser certains domaines...

A bon, moi en passant à l'INRIA j'ai beaucoup vu le contraire. Beaucoup de softs sont développés en BSD pour être refourgués aux boîtes. Les équipes qui font de la recherche appliquée ou de l'ingénierie le font beacoup.

Y'a une page sur le site de l'INRIA qui recense les softs sous GPL et en faisant des recherches on pourrait lister les softs refourgués à des boîtes.

En langage faux-cul on appelle ça des partenariats. Dans la pratique ça s'appelle embaucher un thésard ou, pire, profiter d'un bourse de l'état pour se faire coder un soft qui couterait beacoup plus cher à développer en interne. J'ai pas envie de siter de noms, faites un google sur les différents sites de l'INRIA, ou bien mater les rapports d'activité des équipes, vous verrez.