Alors, ça dépend pour qui. Par exemple dans les jeux vidéos on trouve toujours des fous furieux pour qui toute forme d’abstraction est une hérésie, et où la nécessité d’être ultra performant est essentielle afin de proposer un produit fonctionnel. Mais même là les pressions sont très fortes et tout le monde n’est pas logé à la même enseigne.
C'est vrai...tant que le marché va dans le même sens. Le cas du multithread est un contre exemple : modifier les moteurs, modifier les méthodes de développement pour coder de nouveaux moteurs en multithread, c'est chiant. Alors que tous les CPU grand public étaient multicœurs, on s'est coltiné des jeux vidéos monothread pendant des années. Sur les procos Intel taillés pour délivrer beaucoup de puissance par cœur ça passe crème, sur les procos AMD taillés pour de la puissance multicœur c'est la cata. L'industrie du jeu vidéo appliquait simplement la logique suivante :
On reste sur du monothread, ça tourne pas bien sur de l'AMD -> pas grave tous les joueurs achètent du Intel
Et les joueurs :
Les jeux tournent pas bien sur de l'AMD -> on achète du Intel
Et l'industrie :
Tous les joueurs achètent du Intel -> on se fait pas chier, on reste sur du monothread
Et la boucle est bouclée.
Et enfin le « hardware » c’est dur... je me suis toujours intéressé aux questions de performance et il se trouve que j’ai regardé quelques conférences sur le sujet. Il en ressort que rien n’est évident, qu’on peut réellement passer des journées entières sur de petits problèmes (en apparence), et que de toute façon, faut livrer rapidement parce qu’on a un PoC à faire avec le client qui a été avancé d’un mois.
Le problème c'est quand ça devient une culture. Normalement dans le monde du logiciel libre on devrait être à l'abri de ça, on peut développer/modifier des logiciels sans rendre des comptes à un boss ou une clientèle.
Pourtant même dans le libre on se retrouve avec des trucs bloatés et énergivores. Je ne parle pas des trucs développés par des entreprises pour des entreprises (Puppet, Jenkins, Gitlab...), ça il ne tient qu'à nous (la communauté) de les rendre utilisables. Je parle du reste : tous les bloats à la Diaspora, Etherpad, Mediawiki, Openstreetmap (je ne sais pas quel est le nom de leur logiciel, je ne sais même pas si il a un nom), les "clouds personnels" (Owncloud, Yunohost, etc.) qui a priori ne sont pas conçu avec des deadlines et des objectifs financiers en tête.
Elle est où l'époque où quand on identifiait un nouveau besoin sur Internet, on faisait un Proof of Concept avec un client intelligent, un serveur débile, un protocole entre les deux, conçu pour être le plus simple possible et le plus rapide possible, on soumettait ça à l'IETF et chacun écrivait ses clients et serveurs en respectant le protocole ?
Que ce soit le cas du côté de l'industrie je comprends. Le gars qui invente un nouveau réseau social, il a pas que ça à foutre de faire standardiser un protocole. Il met en place son site web vite-fait mal-fait, si il a besoin d'interactions plus complexes que du POST et du GET, il mettra un paquet de javascript dans son site et le navigateur de l'utilisateur se démerde. Et si ça bouffe toute la RAM, ben il n'aura qu'à racheter de la RAM, et si ça rame à cause des accès disques, ben il n'aura qu'à acheter un SSD, et si WebGL c'est trop lent, ben il n'aura qu'à acheter un nouveau GPU. Pas le temps de niaiser, faut que ça entre en bourse avant la fin de l'année. Pas le temps de faire un Proof of Concept, la version en prod EST le concept.
Dans l'industrie, il faut faire vite et sale parce qu'il y a de l'argent à gagner.
Dans la communauté il faut faire vite et sale parce que...quoi au juste ?
[^] # Re: 256Mo
Posté par eingousef . En réponse au journal Tout cela me fatigue.... Évalué à 10.
C'est vrai...tant que le marché va dans le même sens. Le cas du multithread est un contre exemple : modifier les moteurs, modifier les méthodes de développement pour coder de nouveaux moteurs en multithread, c'est chiant. Alors que tous les CPU grand public étaient multicœurs, on s'est coltiné des jeux vidéos monothread pendant des années. Sur les procos Intel taillés pour délivrer beaucoup de puissance par cœur ça passe crème, sur les procos AMD taillés pour de la puissance multicœur c'est la cata. L'industrie du jeu vidéo appliquait simplement la logique suivante :
On reste sur du monothread, ça tourne pas bien sur de l'AMD -> pas grave tous les joueurs achètent du Intel
Et les joueurs :
Les jeux tournent pas bien sur de l'AMD -> on achète du Intel
Et l'industrie :
Tous les joueurs achètent du Intel -> on se fait pas chier, on reste sur du monothread
Et la boucle est bouclée.
Le problème c'est quand ça devient une culture. Normalement dans le monde du logiciel libre on devrait être à l'abri de ça, on peut développer/modifier des logiciels sans rendre des comptes à un boss ou une clientèle.
Pourtant même dans le libre on se retrouve avec des trucs bloatés et énergivores. Je ne parle pas des trucs développés par des entreprises pour des entreprises (Puppet, Jenkins, Gitlab...), ça il ne tient qu'à nous (la communauté) de les rendre utilisables. Je parle du reste : tous les bloats à la Diaspora, Etherpad, Mediawiki, Openstreetmap (je ne sais pas quel est le nom de leur logiciel, je ne sais même pas si il a un nom), les "clouds personnels" (Owncloud, Yunohost, etc.) qui a priori ne sont pas conçu avec des deadlines et des objectifs financiers en tête.
Elle est où l'époque où quand on identifiait un nouveau besoin sur Internet, on faisait un Proof of Concept avec un client intelligent, un serveur débile, un protocole entre les deux, conçu pour être le plus simple possible et le plus rapide possible, on soumettait ça à l'IETF et chacun écrivait ses clients et serveurs en respectant le protocole ?
Que ce soit le cas du côté de l'industrie je comprends. Le gars qui invente un nouveau réseau social, il a pas que ça à foutre de faire standardiser un protocole. Il met en place son site web vite-fait mal-fait, si il a besoin d'interactions plus complexes que du POST et du GET, il mettra un paquet de javascript dans son site et le navigateur de l'utilisateur se démerde. Et si ça bouffe toute la RAM, ben il n'aura qu'à racheter de la RAM, et si ça rame à cause des accès disques, ben il n'aura qu'à acheter un SSD, et si WebGL c'est trop lent, ben il n'aura qu'à acheter un nouveau GPU. Pas le temps de niaiser, faut que ça entre en bourse avant la fin de l'année. Pas le temps de faire un Proof of Concept, la version en prod EST le concept.
Dans l'industrie, il faut faire vite et sale parce qu'il y a de l'argent à gagner.
Dans la communauté il faut faire vite et sale parce que...quoi au juste ?
*splash!*