boubou a écrit 1384 commentaires

Je crois que tu confonds deux choses : ce qu'on pourrait faire avec des outils mathématiques évolués et ce qu'on sait/veut faire en pratique. Les exemples que tu donnes sont parfaitement modélisable par des outils mathématiques. Le problème, c'est que les outils en question sont en général très complexes, d'autant plus complexes qu'ils modélisent fidèlement la réalité. Ils sont tellement complexes qu'on ne sait plus résoudre théoriquement les diverses équations mise en jeu et on doit donc en général passer à des solutions numériques, obtenues grâce à des programmes. Dans ce cas, il devient un peu ridicule de développer un programme de modélisation pour estimer par exemple le temps de calcul d'un modèle, alors qu'il suffit de faire tourner le modèle pour avoir une idée de ce fameux temps de calcul...

Concernant ton exemple 3, on est en plein dans ce que je raconte. A ton avis, d'où vient la borne théorique de 1 400/1 ? D'un modèle du signal vidéo pour lequel on est capable de faire les calculs. Ce modèle est très certainement faux et conduit donc à des résultats optimistes. Dans la pratique, il faut donc faire des tests sur des séquences vidéo réalistes pour avoir une idée des performances réelles d'un algo de compression. Les matheux d'Intel ne savent donc pas calculer, mais a priori personne d'autre ne sait le faire dans ce cas...

Pour moi l'informatique n'est qu'une section des mathématiques.


Ca me rappelle un vieux troll qui a eu lieu ici (bien entendu) sur le thème "l'informatique est-elle une science ?". Sur le fond, on se rend bien compte que tu t'arranges pour définir l'informatique comme la partie de cette science qui est sa mise en oeuvre, de sorte à extirper tout l'aspect mathématique. En fait, l'informatique, ce n'est pas la programmation, qui n'est qu'un aspect de celle-ci.

Dans le domaine de la programmation, il existe de nombreux supports théoriques qui utilisent bien entendu la modélisation mathématique, mais qui n'en restent pas moins de l'informatique. Prétendre par exemple que l'algorithmique est une branche des mathématiques est totalement absurde. C'est une branche de l'informatique car ce sont des motivations informatiques (analyse a priori d'un programme quelles que soient ses conditions matérielles de mise en oeuvre) qui ont conduit à sa création. Le problème P!=NP (ou P=NP, d'ailleurs, pourquoi pas) est un problème d'informatique. De même la résolution de l'équation de schroedinger est un problème de physique et de chimie, même si les gens qui travaillent là dessus sont des mathématiciens (au sens de leur formation principale). Pour prendre des exemples plus parlant encore, on peut citer le domaine des spécifications formelles de programme qui utilisent des techniques algébriques assez évoluées, toute l'IA (beaucoup de maths discretes et de statistiques), etc.

L'amiga avait un multitache preemptif, c'etait meme le 1er OS grand public a l'avoir

Tu es vraiment sur ? Dans ce cas, au temps pour moi. Ceci étant, c'était juste un exemple parmi d'autre pour dire que l'aspect préemptif n'implique pas de meilleures performances.

note que multitache preemptif n'a rien a avoir avec kernel preemptif.

Je sais. Encore une fois, je voulais juste dire que préemptif n'implique pas meilleurs.

Creer un process sous Linux est clairement plus rapide que sous Windows, pas de doute la-dessus, la difference etant que sous Linux, les gens utilisent principalement des process pour parralelliser alors que sous Windows c'est des threads, et creer un thread sous Windows ca coute pas grand chose.

Tout à fait d'accord, mais d'après les micro-benchs que j'ai pu voir, la création d'un thread coute aussi peu cher sous Linux que sous Windows (meme moins sous linux, sauf erreur de ma part).

De meme, le scheduler sous Linux gere des process(il y a pas vraiment de difference entre un process et un thread sous Linux, c'est juste des param pour clone() differents en gros) alors que sous Windows c'est des threads, difference de conception.

Oui mais non. Dans le kernel de Linus, les threads sont des threads noyaux, ce qui veut dire effectivement qu'il y a assez peu de différences entre un thread et un noyau, sauf que la création d'un thread est plus rapide justement à cause des légères différences (pas de copie de la mémoire, en gros). Par contre, dans le noyau RedHat de Molnar, les threads sont mixtes, comme sous Windows (enfin, je crois, tu peux peut etre confirmer), c'est-à-dire que plusieurs threads peuvent correspondre à un seul process, avec un scheduling en mode user (et donc un peu plus efficace mais un peu moins réactif, en simplifiant).

Pour ce qui est des priorites, ben Windows a 32 niveaux de priorites, avec des particularites selon les niveaux, priority boosting, ainsi que soft & hard affinity, ce qui manque encore sous Linux si je ne me trompe, etc...

Dont acte. Je croyais qu'il y avait moins de niveaux. C'est quoi les hard et soft affinity ?

Il est vrai que des locks tres fins partout ca a des consequences sur les machines mono-cpu, et si tu installes Windows sur un systeme bi-proc et sur un systeme mono-cpu, tu verras que les kernels sont differents.... pas mal de locks sont vires dans la version mono-cpu.

Oui, mais d'après les ingénieurs de Sun (et d'autres d'ailleurs), l'introduction des locks très fins induit des modifications de conception et la presque mise en place de plusieurs noyaux très différents...

De toute manière, le bench TPC ne teste pas que le noyau, loin s'en faut (il teste aussi énormément la BD et le moniteur transactionnel). Effectivement, le triplet tout MS fonctionne très bien et pour un cout raisonnable. Il ne sert à rien d'épiloguer là dessus, MS a les meilleurs scores au bench TPC. Dans quelle proportion cela vient-il de Windows ?

Sauf erreur de ma part, c'est lié aux terminaux. Si tu actives plus de terminaux (les /dev/tty) tu as moins de serveurs X possibles et vice versa. Je ne connais pas les détails, cepedant...

Mouai, bof.

Concernant le kernel préemptif, je ne suis pas du tout d'accord, ce sont des choses assez différentes. Je te rappelle que l'amiga (et oui) avait un multi-tâche non préemptif (alors pour le noyau, ah, ah, ah) et que pourtant, il fonctionnait très bien ce multi-tâches. En fait, on peut même montrer que le multi-tâche préemptif coûte du temps d'exécution (le temps passé dans le scheduler, justement) et c'est pourquoi certains systèmes embarqués ou temps réel n'ont même pas de scheduler. De même, les programmeurs de jeu ont longtemps été très très réticents à utiliser des threads pour éviter de perdre quelques fps. J'ai moi même été obligé de me battre avec les développeurs de freecraft pour pouvoir placer mon patch de son dans un thread à part. Mon expérience à ce moment est qu'effectivement, on perdait des fps en passant à la version avec thread, mais qu'au moins on avait un son potable. Avec le scheduling à la main, on perdait parfois des évènements de son.

Bref, tout ça pour dire qu'un kernel preemptif, c'est très bien pour l'interactivité et pour la réactivité en général (un truc à la BeOS par exemple) mais que ça ne veut pas dire que ça scale bien (grand nombre de process) par exemple. Les tests menés avec linux montrent que les patchs low-latency font gagner des perfs sur certains aspects (justement la réactivité) mais perdre sur d'autres.

D'autre part, les différents micro-bench que je connais montrent que linux est meilleur que windows (sur un mono processeur) en terme de scheduling : la création d'un thread ou d'un process est plus rapide, le temps passé dans le scheduler est moins important, etc. pour des charges normales. Par contre, quand on atteint un grand nombre de threads (genre 500), windows devenait meilleur (avant le patch O(1) de Molnar). D'ailleurs, ce problème de thread est connu car il faisait pas mal merder certaines applications Java, car il fallait en Java utiliser des threads pour faire des IO non bloquantes (alors que la bonne façon de faire est l'appel système select sous unix). Depuis la version 1.4, ce problème est réglé grâce à une api à la select en Java. D'autre part, Molnar et consort ont implémenté un modèle de threads mixte à la Solaris/NT qui peut être ajouté à Linux et qui améliore encore les performances du scheduling. Et ne me dit pas que c'est le futur, c'est la RedHat actuelle.

Sinon, il me semble que le système de priorité des threads/process est moins fin (moins de niveau de priorité) sous windows que sous linux, mais ça je ne suis pas sûr.

Concernant le SMP, je ne me prononce pas pour plusieurs raisons. La première, c'est que je n'ai pas une super confiance dans les benchs TPC. Je n'accuse pas MS de les bidouiller, mais je ne suis pas sûr que cela soit très représentatif de ce que la communauté linux cherche à faire avec le linux SMP. D'autre part, tous les articles que j'ai pu lire sur l'optimisation pour le grand nombre de processeurs sont négatifs, au sens où ils disent tous que la stratégie employée actuellement (un gros des locks très fins dans le noyau) a beaucoup de conséquences négatives sur les performances en mono ou dual (je parle entre autres d'articles d'ingénieurs de chez Sun qui connaissent bien le problème). Mon point de vue est que Linux progresse lentement dans le support efficace des grosses machines pour une raison très simple : il est inacceptable que les choix architecturaux effectués dans cette progression fassent baisser les performances en mono processeur.

que Linux ne supporte toujours pas le changement de session dynamique

Tu sais que tu peux lancer plusieurs serveurs X sous linux. Ah, non, tu ne sais pas...

Ils pourraient également se rendre compte que le multitâche a tendance à être moins performant que celui utilisé sous Windows, et surtout, que la gestion multiprocesseurs est beaucoup moins performante que sous Windows.


Mais bien sûr...

même parfois de simple CD audio

Je suppose que tu veux parler des disques à l'aspect métalique dits "protégés contre la copie". Parce que ce ne sont pas des CD, tu vois.

Au lieu de faire des commentaires crétins, il faudrait en prendre de la graine. En fait, il y a un gros effort de MS pour comprendre les technologies concurrentes dangeureuses, soit donc Linux pour Windows et J2EE pour .NET, afin de s'inspirer de ce qui marche bien, de critiquer ce qui ne marche pas, etc.

C'est une stratégie très intelligente, la meilleure même, et c'est exactement ce que les communautés Linux et Java doivent faire dans l'autre sens. Et c'est d'ailleurs ce qu'elles font. Je me rappelle d'un remarquable article de Linux Journal qui montrait comment la comparaison avec NT avait permis d'améliorer le scheduling de Linux (c'était des micro benchs sur le temps de changement de contexte entre deux threads ou process). Autre exemple, les améliorations prévues dans le jdk 1.5 (autoboxing, méta-données, etc.) presque toutes pompées dans C# (excepté les génériques qui sont en avance). Et je suppose que la liste est infinie.

Et puis, on peut toujours se dire que ça va réduire le FUD, on ne sait jamais...

tu remarqueras, cher Happypeng, que je n'ai pas dis que C++ était un bon langage, mais un langage moderne. Le fait que tu préfères C me fait d'ailleurs une belle jambe et prouve simplement que tu ne connais pas bien le C++ et les services qu'il pourrait te rendre.

mais si elle était implémentée en objets à la c++, on ne pourrait pas l'implémenter dans certains langages ou alors avec un micmac pas possible.


Ouai, bof. L'exemple de Corba montre qu'on peut très bien mapper de l'objet vers du C. De plus, le choix de C dans gtk fait qu'est très lourd à utiliser en C++. Guillaume Laurent, habitué de linuxfr, t'expliquerait ça beaucoup mieux que moi (cf http://www.telegraph-road.org/writings/why.html(...)). Bref, c'est une fiction de croire qu'on peut faire quelque chose qui marche à la fois avec un langage antédiluvien comme C et avec un langage moderne comme C++ (et je ne parle pas de C# ou de Java).

Scénario : tu tappe ta ligne , t'es un peu fatigué, tu te trompe de chiffre et machinalement tu appui sur "entrer" tu perds ton /home.
mk2fs /dev/hdaX

trop tard :((


Ouai, c'est fou, c'est comme avec un couteau de boucher, tu te le plantes dans le bide, tu tournes un peu, et vlan, t'es mort. Mal foutou, les couteaux de boucher.

Sérieusement, tu tappes souvent des mk2fs ? Et su - , c'est pas déjà une grosse sécurité ? Parce que tu sais quand tu baisses le petit levier de ton automatique, que tu regardes ensuite dans le canon et que tu appuies sur la détente, et bien, ça te part dans la gueulle et ensuite, en général, tu es mort.

Une syntaxe unique et une racine.

Je ne dis pas le contraire, je dis juste que le système des lecteurs puait... Les liens symboliques, ça n'existe pas sous windows ?

Je ne dis pas que l'approche Unix est moins bien, simplement je ne vois pas quel probleme ca cause.

Un manque d'unité dans les noms de fichiers. Ce système de lecteur est vraiment pourri, honnêtement.

Si tu dois lire des infos dans la zone mémoire d'un device dont on te done l'adresse, comment fais tu en Java? Tu l'as dans le cul. Désolé d'être aussi vulgaire ;-), mais c'est la triste vérité. Java n'est pas du tout prévu pour ce genre de chose, c'est le moins qu'on puisse dire. Bien entendu, on peut toujours s'arranger en s'intrefaçant avec du C, mais bon... Et oui, je vais lire ton article sur MISC! Il est encore en librairie, ou il est en ligne? C'est le dernier numéro de MISC (le 7), en librairie mai et juin. Pour la mise en ligne, il faudra attendre une hypothétique autorisation de Diamon Edition...

Juste une remarque : certains compilateurs évolués, comme jikes pour java, sont capables de détecter des trucs du genre toTo utilisé à la place de toto, au sens où, en l'absence de symboles toTo, le compilateur va te dire qu'il ne trouve pas toTo, mais par contre qu'il trouve toto... Sinon, à titre personnel, je ne pense pas que la syntaxe soit tellement importante que ça dans le design d'un langage, mais j'accepte l'opinion contraire, en particulier quand je vois le succès de Python ou les idées de Sather (dans lequel un nom de classe doit être entièrement en majuscules, sauf erreur de ma part).

Oui et puis le site de la SNCF tu m'excusera, ce n'est pas terrible terrible ....

C'est marrant, parce que personnellement, je suis d'accord, mais les enquêtes de satisfaction commandées par la SNCF semble prouver que le site est très apprécié des utilisateurs. Comme quoi...

Avec une JVM libre ?

Au dernières nouvelles (mailing list de classpath), ce n'est pas encore possible, il y a quelques problèmes liés au chargement dynamique des classes, qui est une des parties les plus subtiles de Java. De toute manière, aucune JVM libre n'est complètement compatible avec le jdk 1.2, donc...

Comme je percois une pointe d'ironie dans ton post (!), j'en profite pour redire pour la centième fois que je trouve insupportable de lire que Java est propriétaire car c'est faux. Cependant, je ne dis pas que Java est libre car c'est tout aussi faux. Par contre, je pense que la plateforme est beaucoup plus libre que .NET car Mono semble beaucoup plus en retard sur le .NET de MS que l'ensemble des projets libres Java sur SUN (et s'en entrer dans les considérations liées aux brevets etc.).

c'est *TRES* lourd
c'est plein de bloat

"Des arguments, des exemples !" demande la foule en délire.

1 JVM par application sur le desktop (Java2) c'est un peu a mourir de rire.

C'est surtout complètement con, vue qu'on peut très bien avoir plusieurs applications sur une même JVM, c'est même fait pour ça.

Je suis curieux de voir comment IBM va récupéré Java quand Sun va crevé

Moi aussi, vu que les JVM IBM torchent grave.

Oui, Ada est issu d'un appel offre de l'armée US, donc je pense que pour certains développements, il doit être imposé.

Pour l'aspect "désagréable", je voulais juste dire que l'argument vie humaine n'est malheureusement pas toujours suffisant pour imposer des langages un peu moins engendreur de bug que le C, voilà, c'est tout.

Mon aregument ?
C'est l'utilisation quotidienne pour des travaux professionnels des deux.
Que ça te plaise ou non.


Bravo, ouverture d'esprit, argumentation logique, tout y est, c'est remarquable.

Oui, oui, tu es un homme fort et surtout tu argumentes à fond. .NET c'est mieux. ça c'est de l'argument ultra puissant.

Comme tu es un grand garçon, tu peux aller lire http://www.25hoursaday.com/CsharpVsJava.html(...) et tu verras qu'il n'y a pas tant de différences que ça entre les deux langages. Certains points de cet article seront de plus rendu obsoletes par la version 1.5 de Java qui apporte de plus les génériques. Par exemple, la version 1.5 apportera les énumérés et le foreach. Ton exemple des délégates est amusant car les classes anonymes les remplacent avantageusement en proposant une solution beaucoup plus objet et beaucoup plus souple. Normalement, les meta données dévraient être ajoutées aussi dans la version 1.5, mais la situation n'est actuellement pas claire, même si en pratique XDoclet permet de résoudre la plupart des problèmes liés à l'absence de ces méta données (que tu appelles les attributes).

Si tu veux faire vraiment une comparaison, il faut aussi parler de ce qui manque en C#, en particulier une vraie gestion saine de la mémoire, à cause du unsafe, l'absence de vrai chargement dynamique de classes, le système totalement débile du virtual, l'absence des checked exceptions, etc.

Bref, les langages sont effectivement différents et quand la version 1.5 de Java sortira, il restera clairement à C# quelques avantages comme la surcharge d'opérateur, les properties et le passage de référence, mais au prix de la mémoire unsafe et du virtual.

Java a été conçu pour tourner avec ou sans JIT, .NET ne fonctionne qu'avec un JIT...

Et alors ? Le fait est que les JVM Java performantes ont un JIT, je ne vois pas l'intérêt de cet argument foireux.

Le bytecode java... s'appelle le bytecode java... ça te donne une idée? sérieusement, le bytecode java a été pensé pour java, pas pour permettre à plusieurs langage de l'utiliser... .NET n'a pas été conçu de la sorte, c'est même parfois légèrement pénalisant pour le C#.

Et alors ? Oui, le bytecode de .NET a un énorme avantage par rapport à celui de la JVM, il permet de le passage par référence. Donc les langages qui ont besoin de ça sont potentiellement pénalisé par la JVM. Mais la réalité, c'est que de très nombreux langages sont actuellement compilable pour la JVM, éventuellement avec des performances dégradées dans certains cas. D'autre part, si on veut parler de .NET lui même, effectivement, on peut programmer en .NET dans d'autres langages que le C#, mais on reste dans le monde .NET. Avec J2EE, on parle CORBA, RMI et web services, ce qui permet d'être interopérable avec d'autres plate-formes. Tant qu'à faire à comparer tout et n'importe quoi, autant y aller fort !

Si, bien sûr, c'est le but de l'architecture de sécurité de Java et c'est utilisé par les serveurs d'application type JBoss et compagnie.

Sans vouloir être désagréable, de nombreux DSP utilisés dans du matériel embarqué critique (genre controleur des canards dans un avion de chasse, etc.) étaient encore programmés en C ou en assembleur lors de mon passage chez Thales il y a une dizaine d'années. La majorité était en Ada, il est vrai.

Sinon, je suis bien d'accord des applications critiques au sens fric, il y en a malheureusement en VB...

Hum, je vois que tu connais Java aussi bien que je connais Ada...

Tout ce que tu décris existe déjà dans Java, ou bien déjà intégré, ou bien sous forme de bibliothèques open source.

Par exemple, IBM propose une implémentation open source d'un JSR (future extension officielle de Java) qui propose des flotants décimaux, c'est-à-dire des calculs exacts en flottant, avec lesquels on simule très facilement les réels à virgule fixe (dont l'intérêt m'échappe, excepté sur du hardware spécifique). Cf http://www2.hursley.ibm.com/decimalj/(...)

Le mapping mémoire n'existe pas au sens strict en Java puisque le système de type est très réduit, contrairement à Ada, je le reconnais sans problème. Cela ne veut pas dire que tu ne peux pas faire ce dont tu parles, mais ça risque d'être effectivement chiant et surtout inutile (en Java).

Concernant l'introspection etc., l'aspect fair est ridicule. Les langages existent tels qu'ils sont, point final. On reproche toujours à Java d'être basé sur une JVM, on ne peut pas de l'autre côté vouloir en plus supprimer les avantages de cette approche !

Pour l'architecture de sécurité, tu peux lire mon article dans le dernier MISC ;-)

Concernant enfin l'aspect réparti, je suis impressionné. As-tu de la doc ou des références à me conseiller sur le sujet ?

Facile, la sémantique de base des structs est différente de celle des objets, c'est une sémantique dans laquelle les méthodes sont obligatoirements non virtual. C'est un truc très classique dans Sather et Eiffel par exemple. Par contre, pour avoir une sémantique objet propre (ce qui est le cas de tous les langages objets sauf C++) il faudrait interdire d'hériter depuis une struct.