Anonyme a écrit 62292 commentaires

Une autre tentative _interessante_ :)
http://devsecure.sourceforge.net(...)

on entre dans un régime de croisière de 2/3 sujets à troll souvent à base de mandrake.

T'as pas remarqué, y'avait quelques SuSE dans le lot aussi.

Je ne vois pas en quoi c'est dérangeant que ça soit une mandrake. On peut juste se demander quelles sont les raisons d'un tel choix. On écarte tout de suite les histoires de support et de newbie :)

Tellement malheureux que pour la premiere fois, je delaisse ma station alpha fetiche et je poste depuis un win honteux.

Dire que la RH7.1 allait sortir (elle est sorti,
puis reparti).

Pfff, quel monde....

pour la beauté des copies d'écran
http://www.linuxgames.com/articles/rune/(...)

Malheureusement l'alpha chauffe bien plus que les x86
80 Watts pour l'EV67 617 Mhz

He bien pas exactement.
Ce qu'ils ont racheté, c'est avant tout la technologie. Les ingénieurs, eux, ont été trops contents de pouvoir prendre des vacances avec la prime... (façon de parler...)
Quand Digital à été racheté, la technologie à été partagée en deux, entre Compaq et AMD. Et a priori, ce serait plutôt AMD qui aurait récupéré la technologie des procs, utilisée dans la série Athlon, en partie.

Aucun, mais alors, aucun rapport avec ce que j'ai dit, decrasse-toi les yeux avant de dire n'importe quoi !

De quelles entreprises tu parles ? de Suse ?

En plus, qu'elle ne soit pas libre a 100% mais a 99% ne me pose aucun probleme de conscience, le fascisme, c'est pas mon truc. Vouloir a tout prix que tout soit libre ... moi je veux que chacun soit libre de faire du code comme il lui plait.

Mais non, ca va pas, la liberte pour toi, c'est d'obliger tout le monde a faire du GPL, sinon c'est de la merde.

Tout ca c'est bien pour les etudiants en mal de rebellions ...etc, mais ca ne correspond pas a ce que veulent les entreprises, elles en ont RIEN a foutre que Suse ne soit pas 100%, ce qui compte, c'est qu'elle marche, et elle marche BIEN. Tout comme la RedHat, tout comme Debian (MDK je peux pas dire, jamais eu entre les mains).

Et a ce que je sache, il n'est pas interdit ni honteux de se fair du fric, meme sur du GPL.

Quand on vivra dans un monde meilleur, fait d'amour et d'eau fraiche, tu reviendras nous ressortir tes theories.

Tu veux quoi ? Que Linux reste un jouet comme il l'a ete au debut ?

Suse et RH repondent aux besoins des entreprises, c'est comme ca, et t'auras beau gueuler que suce c'est de la merde, que tout ceux qui font pas comme toi sont des cons, ca ne changera rien, a part bien sur te decredibiliser et par la meme occasion la communaute des dev Linux qui grace a des gens comme toi passent pour des debiles.

Tu as un cerveau, utilise le !

Ca ne serait pas mieux d'empecher de rentrer plutot que de detecter les entrées?

Pour ceux qui ne comprendraient rien à cette news (comme moi) et qui ne comprennent pas l'anglais (je n'ai pas ce problème). Voilà un résumé clair de la chose, made in toolinux :
http://www.toolinux.com/lininfo/news/news/news20010625001496.htm(...)

Sachant q'un x86 chauffe à 80°C et dissipe jusqu'a 60W...

Calculez en combient de temps les gars qui travaillaient dans la salle des serveurs se sont mis à bouillir en cette après midi de canicule...

Calculez les éconnomies pour la sécu si tous les serveurs avaient tournés en Alpha...

Moi je veux bien un mac mais c'est super cher. sinon y a ptetre des machine a base d'arm
Ce qui a l'air sympa c'est playstation II + kit linux (linux disque dur clavier souris)+ un ecran PC

Le problème de Compaq, c'est qu'il n'ont pas les ingénieurs qualifiés pour maintenair à flot une telle technologie. Il ne faut pas oublier que Compaq n'est rien d'autre qu'un fabriquant de clones de PC.

Rendons leurs tout de même leur honneur, car sna seux le PC serait encore plus fermé que ne l'est un certain système d'exploitation. Cependant, dévellopper et continuer une architecture de processeurs, surtout à ce niveau, cela requiert des compétances dont ils ne disposent pas.

Saluons dignement ce processeur, qui en a fait rêver plus d'un...

> Ai-je tort ?

Oui, si tu prends le temps de lire l'article, tu verras que l'auteur s'est posé les mêmes questions et qu'il a fait un bench sur du calcul pur, sans transfert de blocs mémoires (calcul fractal).

Résultat:
Linux 2.2.16-22 ..... 4.065
Linux 2.4.4 ......... 4.087
Windows 2000 AS ..... 4.300

La différence n'est plus la même...

Quoiqu'il en soit, pour répondre à la question initiale, l'auteur de l'article n'ayant procédé à aucune optimisation particulière (fonction memcpy() classique) on peut en déduire qu'un programme faisant un usage intensif de transferts de blocs mémoires aura intérêt à tourner sur Linux x86 s'il n'a pas été optimisé pour une plateforme particulière.

Xavier

Sans compter que dans l'édito de l'article, l'auteur du test dit :
Sur Wnt la taille de page est 4Ko, sur Linux aussi.
Ah Ah.
C'est dans le CPU ça, pas dans l'OS.
Oublions ce post, ce bench, consacrons nous à autre chose.

Surtout que la différence constatée n'a sans doute rien à voir avec la gestion des pages mémoires.

Linux x86 a une version optimisée de la copie mémoire par memcpy (copie avec des instructions MMX ou 3Dnow ou ? je ne sais plus) alors que l'auteur de l'article constate clairement que les copies sous Win2k se font élément par élément (char par char, short par short, etc.).

Pour moi, ce bench vaut ce qu'il vaut mais il est probant, l'auteur ayant vérifié que des paramètres comme la charge cpu (ou le time-slice ou quoi que ce soit) n'avaient pas d'influence significative sur le résultat.

Xavier

Je suis l'auteur de la news, je n'ai rien a voir avec SuSE (je l'utilise seulement).

Ce genre de propos nuis a la communauté Linux.

C'est pas parce qu'on post un truc concernant une boite commerciale sur Linuxfr qu'on veut forcement en faire de la pub.

Et puis, franchement, soyons adulte : Redhzt/SuSE/Mandrake : Meme combat. Ne soyons pas des imbeciles...

Les plaisanteries de ce type devraient être assorties d'un smiley car ça risque de donner de mauvaises idées à quelques naïfs.

Tu en doutes ? Et bien sache qu'on m'a déjà fait cette suggestion. Si, si.

Xavier

faudra attendre le noyau 2.6...
Vive le libre, ou plus exactement les logiciels pour développeurs !
Et après ça on essaira de faire croire que Linux perce dans les entreprises. pffff, bouffons !

Oui, mais cela ne change rien au bench qui utilise le meme code C dans les 2 cas.

nicO

Comme il s'agit du meme source, on considere donc la plateforme software : compilateur + OS. gcc+linux vs win+vc.
Par contre, pour mesurer reellement les temps, il devrait utiliser RDTSC, cela prendra en compte tout les temps.

La ou son truc n'a pas beaucoup de valeur, c'est concernant les debits retournes. Avec un codage different, il peut avoir des valeurs tout autre (utilisation de QMOV et de prefetch).

nicO

C'est ce que je me demandais dans le post anonyme (bench à la con).
Dans la mesure où on ne peut pas gérer le time-slice (quantum) il se peut que Linux soit paramétré pour un quantum de 100ms, et NT pour une autre valeur. Mon Amiga a un quantum de 3ms. Il est donc prévu pour faire du context-switch intensif, mais ce n'est peut-être pas le cas de Linux ni de NT. De plus j'ai, par exemple, un algo de scheduling qui est dynamique, alors pour ce qui est de mesurer le temps ...
Sans compter la ligne de pseudo-code ci-dessous :
(admettons un CPU avec un CACHE)
>charge ma_valeur dans mon_adr
>charge ma_valeur dans mon_adr2
>teste le dernier bit de la valeur dans mon_adr
>teste le dernier bit de la valeur dans mon_adr2
est plus rapide que :
>charge ma_valeur dans mon_adr
>teste le dernier bit de la valeur dans mon_adr
>charge ma_valeur dans mon_adr2
>teste le dernier bit de la valeur dans mon_adr2
(ben oui !)

Ais-je tord ?

J'aimerai bien avoir accès à des benchmarks systèmes 'sérieux' pour pouvoir dire à des clients : notre environnement tournera plus vite sur un Unix plutot que sous Win32 car il est de fait plus efficace

Mon context : EJB / Java. Bref, du très haut niveau, loin de l'OS. Peut-on mettre la JVM en cause. J'en doute. Mon problème vient d'échange de messages sur socket (loopback en ce qui concerne mon test)... WinNT perd visible son temps dans le context switching.
Le principe : envoie d'un message, et réception d'un ACK en retour (niveau Java). Si on enlève l'envoi du ACK au protocole, on voit très très peu de différence sous Linux mais NT semble avoir des ailes qui lui poussent comparé à la version avec ACK.
Etrange n'est-ce pas...

Existent-ils donc des VRAIS benchmarks ?
Sur l'utilisation de la mémoire, des sockets, ou ce genre de choses ?

a tous les coups !!

moi j'ai mis mon swap dans un ramdisk ... et ops ...
plus de problème !

ca a pas l'air de beaucoup vous inspirer la doc
du noyau :)
allez, un petit effort, de l'aspirine, des amphet'
et lisez-moi tout ca :)