Ça vous arrive de douter de "l'efficacité" d'un langage de programmation... ?

a marqué ce sujet comme résolu.

Comparer les perfs des langages dans l'absolu, non. Ça ne sert à rien à part faire du kikimeter. Comparer la façon dont plusieurs technos se comportent dans une situation "haut niveau" précise, en revanche (c'est le cas de mon précédent post, qui affiche clairement la couleur sur le comportement de la boucle de base d'un serveur pour 2 protocoles donnés) n'est pas déconnant. Reste à interpréter les benches derrière.

J'ai combien de coeurs ? Combien de RAM ? Comment j'envisage de passer à l'échelle ? Est-il envisageable de multiprocesser ou bien les fils d'exécution ont-ils besoin de partager des données en RAM ? Si je multiprocesse, est-ce que les ressources partagées le sont sur un réseau ? Donc plusieurs instances peuvent tourner sur plusieurs serveurs différents ? Est-ce que l'une de ces technos propose des bibliothèques qui vont notoirement me faire gagner du temps ? Etc.

+0 -0

Très intéressant le benchmark que tu cites nohar.

Y'a un point que je ne suis pas certain d'avoir compris dans ton post :

Le bench date du mois de mai, et repose uniquement sur une boucle minimaliste (type echo-server), pour ne comparer que la boucle brute de serveurs asynchrones. J'en déduis naturellement que l'écart se creuse dans le cas d'applications réelles qui multiplient les requêtes par client servi.

nohar

Tu parles du nombre de socket ouvertes en parallèle ? Pour le benchmark http, si j'ai bien lu y a 3 clients par défaut. Je vais tenter de reproduire avec différents ordres de magnitude. Sinon j'ai peut-être pas compris ce que tu voulais dire.

+0 -0

Je parle du travail du serveur pour servir un client. Ici le serveur accepte la connexion, lit sa requête et répond aussitôt.

Dans une application réelle il ferait surement des requêtes asynchrones vers d'autres services avant de répondre, donc effectivement il va avoir plusieurs connexions en parallèle, et gérer jusqu'à N / (S+1) clients en parallèle avec N le nombre max de sockets qu'il s'autorise à ouvrir simultanément (et qui doit être inférieure à la limite système du nombre max de file descriptors ouverts par process), et S le nombre de services vers lesquels il doit se connecter pour répondre à un de ses clients.

+0 -0

Ouais, je ne suis vraiment pas né à la bonne ère. :-°

Je pense que tu te trompes. Tu as plein de domaines où le besoin de performance et de contrôle reste et restera indispensable : systèmes embarqués, industrie lourde, aéronautique ou médical, etc.

Dans ces endroits là, le système doit être déterministe, validé et tourner dans des conditions difficiles en terme de quantité de ressources. C'est là où le C (voire C++) domine encore et pendant encore longtemps. Les ordinateurs personnels et professionnels sont aujourd'hui trop puissants pour que la couche applicative soit pertinente en C.

Niveau informatique personnel, reste les couches basses comme le noyau et les bibliothèques élémentaires pour pratiquer le C pour les raisons que tu cites : besoin de performances et de contrôles, manque d'abstraction suffisante pour Python et consorts…

Bref, tu es à la bonne ère, mais les besoins ont changé et donc le contexte d'utilisation du langage C aussi.

+0 -0

Les ordinateurs personnels et professionnels sont aujourd'hui trop puissants pour que la couche applicative soit pertinente en C.

Renault

Je ne peux m'empêcher de penser que ceci constitue un gros gaspillage de ressources…

Sinon, je suis effectivement un peu trop pessimiste, il reste et restera des branches de l'informatique qui nécessiteront de la gestion de ressources précise et des performances importantes.

+1 -0

Je ne peux m'empêcher de penser que ceci constitue un gros gaspillage de ressources…

Faut voir, peut-être pas si on prend en compte le cout de développement (tests, etc… )

Sinon, je suis effectivement un peu trop pessimiste, il reste et restera des branches de l'informatique qui nécessiteront de la gestion de ressources précise et des performances importantes.

Ça me semble certain. Surtout qu'on ne peut plus trop attendre d'immenses amélioration côté matériel (en tout cas pas plusieurs ordres de grandeur). À part une meilleure gestion parallélisme avec la multiplication du nombre de cœurs (et il va de soit que les systèmes gérant ça devront être bas-niveau).

le système doit être déterministe

Là en revanche je suis plus sceptique sur l'utilisation de C et C++ qui a tendance à produire des programmes non déterministes vu le nombre de segfaults possibles. On préfère souvent du fonctionnel.

Et tourner dans des conditions difficiles en terme de quantité de ressources

Là il est certain que C et C++ conviennent bien.

Paradoxalement, l'augmentation de la quantité de données disponibles a rendu possible leur utilisation par des algorithmes (machine learning entre autre, mais pas que) qui étaient autrefois cantonnés au labo des chercheurs avec une base de données de 10Ko, et ils ont intérêt à être très rapides pour traiter la masse.

Je ne peux m'empêcher de penser que ceci constitue un gros gaspillage de ressources…

C'est discutable. La ressource matérielle est moins chère que la ressource de développement. Et les projets bureautiques ou professionnels sont beaucoup trop complexes à gérer pour le langage C. L'abstraction qu'offre Python ou autres sont très appréciables dans ces contextes.

Sans oublier que la gestion minutieuse d'une application en C n'est possible que pour les projets de taille raisonnable. Très rapidement les fuites de mémoires, soucis dans la concurrence et autres peuvent survenir. Résultat le gain espéré en C ne sera pas si grand que tu ne le penses, tout comme la fiabilité du programme obtenu. Sans compter que la perte que tu évalues devient assez négligeable devant la performance de ces machines.

il reste et restera des branches de l'informatique qui nécessiteront de la gestion de ressources précise et des performances importantes.

Et c'est loin d'être anecdotique. L'Internet des Objets ou même des pans entiers de l'industrie ont et auront besoin encore plus d'avoir des couches basses maîtrisées, performantes et fonctionnelles.

+1 -0

Là en revanche je suis plus sceptique sur l'utilisation de C et C++ qui a tendance à produire des programmes non déterministes vu le nombre de segfaults possibles. On préfère souvent du fonctionnel.

Selon le degré de criticité, en aéronautique comme en médical tu ne peux pas avoir de langages fonctionnels car le processeur moderne est de fait indéterministe. C'est microcontrôleur voire un processeur très rudimentaire.

Et le C / C++ peuvent être déterministes dans ce contexte, les normes en vigueurs interdisent l'usage de malloc et d'autres type de constructions pouvant être sujets à risque par exemple.

+1 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte