Salut,
Merci pour l'outil. Apache et mod_c peuvent aller se cacher...
Meilleures salutations.

Je rejoins totalement tguillod.

Et je vais ajouter que le benchmark me semble comparer des pommes et des poires. Est-ce que gwan gère ssl, l'authentification http, le contrôle d'accès, fait proxy, gère les vhosts, dispose de réécriture des urls, gère le multilangue, les encodages différents, etc etc ? c'est malhonnête de comparer les performances sans les fonctionnalités.

Oui, bon..

"Pourtant, toutes les plateformes ont un compilateur C... qui est utilisé pour faire le runtime de vos langages Web favoris"

Toutes les plateformes ont un langage d'assemblage, dans lequel sont écrites les primitives du C. ça signifie que l'assembleur est un langage portable ?

Si le C est vraiment portable, pourquoi doit-on se farcir l'horreur que sont les autotools ou leurs concurrents ? et pourquoi gwan n'est-il disponible que sur linux 32bits ?

En ce qui concerne la grosse erreur, et le point sur lequel je rejoins tguillod, ce n'est pas la performance mais la sécurité. Même si le peu de code qu'on voit de gwan (les headers) a l'air soigneusement écrit, ça ne sera pas forcément le cas des servlets. La dernière chose dont j'ai envie, c'est de devoir auditer individuellement chaque servlet en sachant qu'elles recèlent peut-être une exécution de code arbitraire. Je vois qu'il y a une petite lib de buffer à taille variable, ce qui est sûrement une très bonne chose, mais je ne pense pas que ça soit suffisant pour garantir la sûreté du code en toutes circonstances.

Globalement, cela m'apparait comme un gros retour en arrière en matière de sûreté (mais j'aime bien les langages abstraits, alors je suis surement biaisé)

Dernier point que je n'avais pas remarqué avant: d'ou sort le chiffre de 5 millions ?

Au mieux, on observe un facteur de 400000 si on compare a la fois les RPS et le nombre de users servis. MAIS: pour que ce chiffre aie un sens, il faudrait que le RPS soit le RPS par utilisateur et pas le RPS total. Alors, ce n'est pas indiqué, mais la courbe a la tête d'un rps total (la pente raide au début et le plafond ensuite) alors que pour un RPS par utilisateur on s'attendrait a un plateau au début et une décroissance géométrique ensuite.

Je demanderai aussi pourquoi les graphes présentent le RPS et pas le temps de traitement moyen d'une requête. L'inversion favorise visuellement les résultats les plus hauts, et généralement les temps de traitement sont une mesure plus intuitive du cout d'une opération.

Cher PierreG,

PierreG a écrit:

Un langage portable signifie que le MEME CODE SOURCE peut
être utilisé sur plusieurs plateformes.

C'est le cas du C, mais pas celui de l'assembleur. L'assembleur
n'est donc pas portable.

Je vous défie d'écrire du code C qui compile correctement sur Linux, BSD, windows, sur plusieurs architectures, et qui ne fasse pas recours a un système de compilation sophistiqué.

Comparez avec Ada, Haskell, OCaml, qui disposent tous de compilateurs natifs.

PierreG a écrit:

Il n'est compilé qu'en 32-bit et pas encore en 64-bit parce
que je n'ai pas encore installé Linux 64-bit sur une machine
de développement

.

Et c'est bien le problème, puisqu'avec un des langages susnommés une compilation croisée aurait suffi

> "sécurité et garantir la sûreté du code en toutes circonstances"

PierreG a écrit:

Java, C# et PHP exposent les développeurs à quelques dizainnes
de vulnérabilité critiques de leur runtime -chaque année.

Ce n'est pas le cas du C, dont le runtime n'offre pas de failles de
sécurités basées sur une implémentation défaillante.

Oui, et ces vulnérabilités sont identifiées et corrigées a une vitesse décente.

C'est également le cas du C; expliquez donc pourquoi la libc ne peut pas être considérée comme un runtime, et pourquoi elle serait exempte de problèmes. Le kernel  n'est pas immunisé non plus contre ce genre de problèmes.

PierreG a écrit:

Quand au "retour en arrière", j'invite le lecteur éclairé à lire ma
comparaison de Java, C# et PHP pour se faire une idée des
pseudo-améliorations (ou de la valeur ajoutée) de ces langages
"modernes" sur le C (voir la fin du manuel de G-WAN v1.0.97+).

Eh bien justement, je viens de le lire.

Point 1: la portabilité. Votre argument est que Java, PHP, C# ont des runtimes écrits en C, et que donc ces langages ne sont pas plus portables que C.

Vous appliquez ici un raisonnement binaire, en prétendant qu'un programme est portable ou ne l'est pas. Vous ignorez totalement l'effort requis pour porter du code d'une arch a une autre, et le fait qu'écrire en C vous force a refaire ce travail pour chaque architecture, alors qu'il est fait une fois pour toutes dans un langage plus abstrait.

Point 2: la, ok, vous avez entièrement raison en ce qui concerne la pollution du namespace de PHP. ça ne date pas d'hier.

Point 3: vous affirmez que C#, Java, PHP n'apportent aucune évolution par rapport au C parce que la syntaxe pour les commentaires est identique ? cet argument est franchement risible

Point 4: vous argumentez que ces langages sont identiques parce qu'ils utilisent les mêmes structures de contrôle ? très bien, regardez du côté de Lisp, Haskell ou Erlang alors.

Point 5: donc vous reconnaissez que les runtimes Java, PHP, C# sont buggés alors qu'ils sont écrits en C ? c'est un argument à l'encontre du C, pas de ces langages.

Et globalement, vous ignorez totalement le vrai problème, a savoir le danger et la complexité de la gestion de la mémoire manuelle. Consultez le top 25 CWE, et vous constaterez qu'en 3e position se place le débordement de tampon, une erreur impossible dans un langage a gestion automatique de la mémoire. (et les faiblesses en position 1 et 2 sont indépendantes du langage)

PierreG a écrit:

Je vois: un serveur qui sert plus d'un client n'a aucun intérêt
pour l'académic.

Non, vous avez mal compris. Il est correct d'utiliser le RPS total comme métrique, et c'est ce que votre graphe montre. Votre graphe montre en revanche, a la louche, une amélioration de l'ordre de 10^3 sur IIS, c'est plus que respectable, mais je ne comprends toujours pas d'ou sort le 5 millions, si ce n'est par une multiplication incorrecte du RPS et du nombre de clients.

PierreG a écrit:

J'apprécierais, d'une manière plus générale, que vous évitiez
de me servir de gros mensonges, ou des non-sens techniques
comme seuls arguments contre G-WAN

Vous considérez que la sécurité d'un langage à gestion automatique de la mémoire est un non-sens technique ? Et ce ne sont pas des arguments contre G-WAN, qui me parait un produit de qualité, mais contre le concept d'écrire des servlets en C, qui me parait fort dangereux. Vous êtes peut-être un programmeur C d'exception, mais si vous pensez qu'il s'agit de l'avenir de la programmation web, vous êtes cruellement peu au fait des réalités sur les compétences du programmeur d'entreprise moyen.

PierreG a écrit:

Ah, dernière précision, IBM a demandé les conditions d'une
licence de code source pour G-WAN (preuve que tout le monde
ne pense pas comme vous, heureusement).

grand bien vous en fasse s'ils peuvent se le permettre. En ce qui me concerne, je préfèrerais vraiment le voir open source avant de travailler avec. J'y vois un intérêt certain pour le développpement embedded (interfaces de contrôle d'appareils sans console), oui. Mais pas pour remplacer de grosses applications web.

Je n'en reviens pas d'autant de mauvaise foi, d'agressivité et
d'approximations techniques, le tout réuni contre un projet
gratuit dont le seul tort est de faire mieux que tous les autres:

"HATRED, n. A sentiment appropriate to the occasion of another's superiority."
(Ambrose Bierce, The Devil's Dictionary)