Est on censé acheter le DVD pour soutenir Blender ou pour le film ?
Les deux: les pré-ventes soutiennent directement la production du film, mais la production du film passe par le développement/l'amélioration de certaines fonctionnalités de Blender.
Si tu vas voir la page du projet, l'équipe est constituée essentiellement d'artistes, mais il y a aussi un développeur.
Tu suggères que si les sites comme last.fm et assimilés ne fonctionnent pas, c'est à cause de la "culture du tout-gratuit"?
Mais cela peut-être aussi causé par un business model inadapté, qui essaie souvent de maintenir le même nombre d'intermédiaires que dans l'économie "pré-numérique".
Après, je ne dit pas qu'il soit facile de trouver de meilleurs modèles, mais je pense qu'ils finiront par émerger, et on se rendra compte qu'au final les gens continuent de dépenser leur salaire.
Parce que, si ce culte de la gratuité existe réellement, qu'est devenu tout cet argent non dépensé?
J'ai l'impression que cette hypothétique "culture du tout-gratuit" est née dans l'imaginaire politico-médiatique, par peur des évolutions que le numérique peut apporter.
Accuser les libristes de vouer un culte à la gratuité est amha un non-sens; au contraire, certains payent pour des choses qu'ils peuvent se procurer pour rien.
Du côté des gamers sous windows, même si la plupart piratent, j'ai l'impression que la plupart ont aussi acheté quelques jeux (du moins ceux qui sont en age de choisir ce qu'ils font de leur argent). Le fameux "manque à gagner" si chers aux maisons d'éditions/boites de prods/etc. est une illusion: le porte-monnaie des joueurs n'est pas extensible à merci.
Pour en revenir au sujet du journal, je pense que ce qui pourra sauver l'avenir du jeu vidéo sous Linux, c'est qu'on se dirige petit à petit vers un développement utilisant des langages et APIs de plus en plus haut niveau (afin de garder le temps de développement dans des limites saines [1]). Arrivé à un certain point, et une fois que la couche graphique aura (re)trouvé la ligne, le portage sera peut-être de nouveau envisageable.
[1] Un pdf du patron d'Epic Games, qui mentionne la nécessité de passer à des langages de haut-niveau pour privilégier la productivité sur la performance:
D'après ce qu'il a dit à la QuakeCon [1], l'ouverture des sources d'idTech 4 n'attends plus que l'aval de ZeniMax Media (le récent acquéreur d'Id Software).
- du point de vue du joueur, une interface de match-making bien foutue; quand on voit les horreurs pondues dans certains jeux, avec soit une ergonomie affreuse ou des possibilités très limitées, c'est peut-être pas plus mal qu'ils se rabattent sur un site web;
- du point de vue d'ID software, pouvoir intégrer des pubs, plus facilement qu'à l'intérieur du jeu (parce que format web déjà existant, et aussi parce que dans un jeu l'utilisateur ne peut pas cliquer sur les pubs...); sauf que ça tombe pile au moment où tout le monde commence à se rendre compte que ce type de financement n'est pas rentable.
Il est aussi possible que ce soit une expérimentation pour voir si les joueurs sont prêts à accepter un passage obligé par le net (rendant ainsi le piratage plus difficile). A rapprocher de Starcraft II de Blizzard, qui ne proposera pas la possibilité de jouer en LAN.
Il est évident que fournir des spécifications ouvertes n'est pas (ou plus exactement: ne devrait pas être) une excuse pour sortir des drivers pourris...
En ce qui concerne le choix, tout le monde n'a pas les même priorités. Je n'ai jamais compris l'intérêt de créer un choix arbitraire entre 100% proprio ou 100% libre.
Enfin, personnellement je préfère des spécifications ouvertes à un pilote libre, mais peut-être que cette dernière option est plus réaliste.
Pour modérer un peu, il ne faut pas oublier qu'AMD participe aussi à la spécification d'OpenGL, et il semble qu'ils se soient montrés particulièrement actifs sur cette dernière version (d'après http://www.g-truc.net/#news0170 ).
Il est vrai que Nvidia est depuis longtemps très impliqué en ce qui concerne OpenGL, et rapide à sortir des drivers (beta) supportant les dernières extensions...
Côté drivers je pense qu'il sera toujours nécessaire d'avoir une version proprio aux côté des drivers libres, car il est difficile d'atteindre la performance maximale d'une carte sans une connaissance intime du matériel, voire de la façon dont elle est utilisée dans les applis (jeux notamment). L'idéal amha est une spec ouverte pour garantir un maximum de liberté, et un driver proprio pour les quelques uns qui veulent tirer le maximum de leur carte.
Sur les dernières générations de carte aussi bien ATI que Nvidia, le support d'openGL 3.1 est (ou sera "bientôt") complet (et matériel). Je ne me suis pas encore penché sur la 3.2, mais je pense qu'il en va de même.
Le passage OpenGL 2 vers OpenGL 3 a surtout été l'occasion de nettoyer l'API, et préparer sa modernisation. L'occasion aussi de passer dans l'API elle-même ce qui n'était avant que des extensions (donc déjà supportées par la majorité des cartes).
De plus, le pipeline des cartes étant devenu de plus en plus souple, il y a beaucoup d'évolutions qui peuvent s'implémenter par une simple mise à jour logicielle (tout en gardant le bénéfice d'une accélération matérielle). C'est aussi le cas pour DirectX: les cartes Direct3D 10.1 supporteront la plus grande partie de Direct3D 11.
Bon, soit tout ce que j'ai appris sur les GPUs modernes est faux, soit on ne parle pas de la même chose. Peut-être la situation est-elle différente entre le monde du jeu vidéo et les autres domaines, tel que l'imagerie médical à laquelle tu as fait allusion.
Je ne sais pas trop si c'est intéressant de continuer le débat, j'ai l'impression qu'on tourne en rond.
Peut-être que les années à venir me donneront tort, qu'on verra l'arrivée de systèmes de plus en plus haut niveau pour la gestion mémoire dans ce domaine. Pour l'instant je ne vois pas cette tendance.
Estc-e que tu connais réellement des développeurs qui réorganisent leurs display lists à la main à chaque frame ?
A ma connaissance, plus personne n'utilise les display lists dans le monde du jeu vidéo: tout passe par des VBO. Et, oui, le contenu de ces VBO est géré par le développeur.
Je ne comprends pas pourquoi tu parles de gérer les shaders vertex par vertex, où de réécrire les "fonctions de z-buffer". Quel est le rapport avec la gestion mémoire? Le seul impact que je vois c'est qu'il faut souvent regrouper les vertex par shader, et c'est en grande partie pour ça que l'on doit optimiser le contenu des VBO à la main.
Les uniforms buffers permettent surtout d'allouer un bloc de mémoire GPU et de choisir ce que l'on va y stocker, afin d'optimiser le transferts des uniforms entre le CPU et le GPU. Cela en lieu et place d'une allocation transparente gérée par l'API. Donc oui, on est dans plein dans le vif du sujet: passer d'une gestion automatisée à une gestion manuelle.
Enfin, "évaluer à priori le temps d'exécution" d'un GC ne suffit pas. Comme tu le dis, les performances des moteurs de rendus sont fonction de la complexité de la scène. Si un GC n'est pas capable de garantir que pour une scène de telle complexité son temps d'exécution sera inférieur à une valeur donnée, cela revient à autoriser la dégradation du framerate par un facteur inconnu...
On ne peut pas vraiment appeler ça un garbage collector mais dans les faits le programmeur utilise une API de haut niveau (en descendant parfois un peu sur certains points) et derrière le système se démmerde tout seul pour gérer les buffers et la mémoire vidéo.
Sauf que:
- La véritable gestion mémoire se fait à l'intérieur des buffers alloués par des appels OpenGL; et là c'est le développeur qui y organise ses données, et y accède par un système de pointeur (relatif au début du buffer). L'api "de haut niveau" n'est pratiquement utlisée que pour réserver de la mémoire.
- OpenGL fournit des garanties sur quels appels peuvent déclencher une allocation, et quels appels ne le feront pas;
- le système "automatique" que tu décris pour les buffers consiste essentiellement à incrémenter/décrémenter un compteur pour chaque buffer, sachant qu'ils ne peuvent pas avoir de références circulaires; on est très loin d'un GC moderne; (par contre les buffers peuvent en théorie être déplacés)
- les extensions récentes (par exemple les uniform buffers d'openGL 3.1) cherchent souvent à donner un accès de plus en plus fin à la mémoire GPU;
La seule possibilité que je vois pour pouvoir intégrer un GC dans un moteur de rendu (toujours dans le contexte du jeu vidéo), ce serait de pouvoir mettre une borne supérieure sur son temps d'exécution à chaque frame. Est-ce possible sur certains GC?
On ne parle pas du tout de la même chose... Je parlais des moteurs de rendus utilisés principalement dans le domaine du jeu vidéo, et des moteurs utilisés dans les synthés audio.
(Peut-être que ça en agace certains d'utiliser la qualification "temps-réel" pour ces usages, mais il faut bien faire une distinction avec les applis de type bureautique; et la distinction est qu'il y a bien, effectivement, une contrainte de temps, même si elle n'est pas "dure" comme pour les applications plus critiques.)
Dans ces domaines là, je n'ai pas connaissance d'une quelconque tendance à utiliser un GC. Il s'agit peut-être de frilosité, mais je pense surtout qu'on se situe à la limite des capacités du matériel utilisé (sur lequel on a aucune influence), et que la moindre perte de performance coûte.
En ce qui concerne l'explication sur java, cela me semble rejoindre ce que je disais: au final, on en revient à tout gérer à la main, donc à court-circuiter le GC pour les partie" hautes-performance".
Je tiens à préciser que je ne dénigre absolument pas les GC, j'ai longtemps été un apôtre d'Eiffel... Seulement je crois que ce n'est pas forcément un outil adapté à toutes les situations.
Je tiens à préciser: je ne parle pas de moteurs de jeu (donc beaucoup sont déjà écrits en grande partie en langage interprétés, donc avec GC), mais de moteurs de rendus.
En ce qui concerne les perfs des appels systèmes d'allocation mémoire, tu as tout à fait raison, c'est bien pour ça qu'on ne les utilises pas lorsqu'on a besoin d'être vraiment rapide. On alloue tout en bloc et on réutilise les mêmes zones de mémoires autant que possible. C'est en partie faisable avec un GC, mais en partie seulement, et cela revient à réinventer un système d'allocation manuelle pour empêcher que le GC ne se déclenche.
Je ne dit pas que c'est impossible, mais actuellement je n'ai connaissance d'aucun moteurs de rendus, ni d'aucun moteurs audio, qui utilise un GC. Et en ce qui concerne les premiers, la tendance me semble au contraire à être de plus en plus proche du hardware.
Le SEUL avantage de l'accès mémoire direct au point de vue programatique [...]
Il y a un autre cas où la gestion directe est quasiment indispensable: pour le temps-réel et tout ce qui s'en rapproche. Par exemple un synthé audio, ou bien un moteur de rendu pour un jeu.
Sinon je suis entièrement d'accord, quelque soit l'approche utilisée il faut accorder de l'attention à l'utilisation de la mémoire.
J'ajouterai que en C/C++, la gestion mémoire ne se limite pas à apparier malloc et free; regrouper les allocations, réutiliser ce qui est déjà alloué, utiliser l'allocation sur le tas sont tout aussi importants.
Et qu'en est-il du langage proprement dit? Il y a des gens qui utilisent encore Eiffel?
J'avais l'impression que les problèmes n'étaient pas limités à SmartEiffel, mais plutôt que le processus de standardisation chaotique avait entrainé (ou du moins accéléré) sa chute...
En tout cas c'est dommage, il y avait plein de bonnes choses dans ce langage. Et quand à SmartEiffel, ils avaient une approche originale de la compilation orientée objet (à base d'IDs et de branchement dichotomiques en lieu et place du tableau de méthodes). Sans oublier que c'était une excellente source de trolls...
Non, je pense qu'il parle bien de workflow. Avec le sens plus ou moins de méthode de travail. Autrement dit, je pense qu'ils vont faire une démonstration en réalisant un projet de A à Z, pas un atelier pour apprendre (qui serait le sens de workshop).
Quand au choix des logiciels, depuis quand est-il obligatoire pour tout le monde de n'utiliser que du libre?
J'ai dû vraiment mal m'exprimer, parce qu'à aucun moment je n'ai voulu remettre en cause la légitimité de la démarche d'Arch. Je dit pourtant clairement que j'apprécie leur échange de mails...
Ceux que je qualifie d'"intégristes" (j'aurais dailleurs dû eviter ce terme trollesque) sont ceux qui dégainent (les lettres d'insultes) sans chercher à dialoguer. Et le pire est qu'ils le font en lieu et place des principaux intéressés.
En ce qui concerne le libre, le droit des marques, et la réalité du vol, c'est une évidence. Et je n'ai jamais dit le contraire.
Par contre, je vois plus de l'insouciance qu'une volonté délibérée de nuire, et certainement pas orientée vers le libre. Cela aurait tout aussi bien pu tomber sur le logo d'une petite association, du site web d'une guilde de gamers, ou n'importe quoi d'autre.
Je parlais évidement (mais j'aurais dû le préciser) des lettres d'insultes, pas de la façon d'agir des des membres d'Arch, qui est parfaitement saine.
Et oui, je pense que l'échange de mails s'acheminait vers un règlement à l'amiable. Le représentant de la boite passe d'une désinvolture certaine à une attitude défensive, signe qu'il se sent "coincé". Il est regrettable mais presque compréhensible qu'il n'avoue pas son forfait, je reste sur l'impression qu'une simple proposition d'arrangement en provenance des gens d'Arch aurait réglé le problème.
Ils n'en ont pas eu le temps, et c'est ce que je déplore.
Un exemple frappant de l'impact de plus en plus inquiétant qu'on les "intégristes" du libre sur le cheminement du logiciel libre.
L'échange de mail donne à penser que cela aurait pu se terminer par un arrangement pacifique, par exemple une autorisation d'utiliser le logo en échange de la reconnaissance de sa provenance. Gagnant pour tout le monde. Au lieu de cela, la réputation belliqueuse des libristes est une nouvelle fois renforcée.
J'espère que cette tendance va finir par s'inverser, parce que, personnellement, j'hésite de plus en plus à promouvoir le libre: c'est presque devenu synonyme d'agression.
Pour apporter une petite précision, leur système de "fédération" entre serveurs permet à la fois de confiner une partie des données à un serveur unique (ou à un sous-ensemble de serveurs), et d'assurer le partage du reste.
En gros, avec deux serveurs A et B, les communications entre utilisateurs de A sont stockées uniquement sur A, seules celles impliquant à la fois des utilisateurs de A et B sont partagées. Sachant que même dans une "wave" (conversation) partagée entre plusieurs serveurs, une partie des échanges peut être privée et ne jamais quitter leur serveur d'origine. Et cela semble fonctionner quelque soit le nombre de serveurs impliqués...
Et effectivement, les 1h20 de vidéos valent vraiment le coup.
Je suis entièrement d'accord. Je voulais juste souligner que l'implication d'Intel n'a pas que des bons côtés... Bien sûr, elle n'en a pas que des mauvais non plus.
Le gros problème du serveur X, c'est qu'il n'y a pas beaucoup de développeurs qui s'y intéressent. Alors que c'est probablement l'un des composants qui en a le plus besoin. Malheureusement, c'est une couche logicielle "invisible", qui ne passionne donc pas les utilisateurs finaux; et comme ça ne fait pas partie du noyau, ça ne passionne pas non plus les développeurs...
Là, je pense que tu as allègrement franchi la frontière qui sépare la défense d'une idée de l'idéalisme béat.
Choisir telle ou telle carte vidéo parce que son constructeur fournit des drivers ou des specs libres, c'est une chose. Utiliser ce même critère pour lui accorder carte blanche (ou peut s'en faut), c'est très différent.
De plus l'implication d'Intel dans le libre peut-être interprété de plusieurs façons, et tout n'est pas forcément aussi idyllique que ce que tu sembles croire. Leur poids dans le développement du serveur X, par exemple, est à double tranchant: ils poussent en avant des technos privilégiant les puces de type "chipsets intégrés", au détriment de solutions plus générales (voir leur introduction d'UXA à la place d'EXA). C'est compréhensible (pourquoi faciliter la vie aux concurrents?), mais à long terme, cela peut nous apporter plus de nuisances que de bienfaits.
Sauf que parler de convivialité sans donner de contexte, ça n'a pas beaucoup de sens.
Quand on utilise une appli de manière intensive, minimiser le nombre d'actions à faire pour exécuter une tâche est un aspect important de la convivialité.
Ce que certains appellent un "cliquodrome", c'est fantastique lors des premières utilisations, mais ça peut vite devenir très énervant, et ça, AMHA, c'est une question de convivialité. Une appli qui énerve, on a pas envie de l'utiliser: comment peut-on encore la qualifier de conviviale?
[^] # Re: Hum
Posté par drakmaniso . En réponse au journal Blender - le DVD du projet Durian. Évalué à 2.
Les deux: les pré-ventes soutiennent directement la production du film, mais la production du film passe par le développement/l'amélioration de certaines fonctionnalités de Blender.
Si tu vas voir la page du projet, l'équipe est constituée essentiellement d'artistes, mais il y a aussi un développeur.
[^] # Re: Toi qui entre ici etc.
Posté par drakmaniso . En réponse au journal Le portage du moteur id Tech 5 (Rage et Doom 4) sous Linux est peu probable. Évalué à 1.
Mais cela peut-être aussi causé par un business model inadapté, qui essaie souvent de maintenir le même nombre d'intermédiaires que dans l'économie "pré-numérique".
Après, je ne dit pas qu'il soit facile de trouver de meilleurs modèles, mais je pense qu'ils finiront par émerger, et on se rendra compte qu'au final les gens continuent de dépenser leur salaire.
Parce que, si ce culte de la gratuité existe réellement, qu'est devenu tout cet argent non dépensé?
[^] # Re: Toi qui entre ici etc.
Posté par drakmaniso . En réponse au journal Le portage du moteur id Tech 5 (Rage et Doom 4) sous Linux est peu probable. Évalué à 3.
Accuser les libristes de vouer un culte à la gratuité est amha un non-sens; au contraire, certains payent pour des choses qu'ils peuvent se procurer pour rien.
Du côté des gamers sous windows, même si la plupart piratent, j'ai l'impression que la plupart ont aussi acheté quelques jeux (du moins ceux qui sont en age de choisir ce qu'ils font de leur argent). Le fameux "manque à gagner" si chers aux maisons d'éditions/boites de prods/etc. est une illusion: le porte-monnaie des joueurs n'est pas extensible à merci.
Pour en revenir au sujet du journal, je pense que ce qui pourra sauver l'avenir du jeu vidéo sous Linux, c'est qu'on se dirige petit à petit vers un développement utilisant des langages et APIs de plus en plus haut niveau (afin de garder le temps de développement dans des limites saines [1]). Arrivé à un certain point, et une fois que la couche graphique aura (re)trouvé la ligne, le portage sera peut-être de nouveau envisageable.
[1] Un pdf du patron d'Epic Games, qui mentionne la nécessité de passer à des langages de haut-niveau pour privilégier la productivité sur la performance:
http://graphics.cs.williams.edu/archive/SweeneyHPG2009/
[^] # Re: Perso, j'attend surtout l'ouverture d'idTech4...
Posté par drakmaniso . En réponse à la dépêche Quake live enfin dispo sous GNU/Linux !. Évalué à 6.
[1] http://news.bigdownload.com/2009/08/14/quakecon-2009-john-ca(...)
[^] # Re: Jeu web
Posté par drakmaniso . En réponse au journal QuakeLive sous Linux !. Évalué à 2.
- du point de vue du joueur, une interface de match-making bien foutue; quand on voit les horreurs pondues dans certains jeux, avec soit une ergonomie affreuse ou des possibilités très limitées, c'est peut-être pas plus mal qu'ils se rabattent sur un site web;
- du point de vue d'ID software, pouvoir intégrer des pubs, plus facilement qu'à l'intérieur du jeu (parce que format web déjà existant, et aussi parce que dans un jeu l'utilisateur ne peut pas cliquer sur les pubs...); sauf que ça tombe pile au moment où tout le monde commence à se rendre compte que ce type de financement n'est pas rentable.
Il est aussi possible que ce soit une expérimentation pour voir si les joueurs sont prêts à accepter un passage obligé par le net (rendant ainsi le piratage plus difficile). A rapprocher de Starcraft II de Blizzard, qui ne proposera pas la possibilité de jouer en LAN.
[^] # Re: NVidia: propriétaire mais...
Posté par drakmaniso . En réponse à la dépêche Publication d'OpenGL 3.2. Évalué à 2.
En ce qui concerne le choix, tout le monde n'a pas les même priorités. Je n'ai jamais compris l'intérêt de créer un choix arbitraire entre 100% proprio ou 100% libre.
Enfin, personnellement je préfère des spécifications ouvertes à un pilote libre, mais peut-être que cette dernière option est plus réaliste.
[^] # Re: NVidia: propriétaire mais...
Posté par drakmaniso . En réponse à la dépêche Publication d'OpenGL 3.2. Évalué à 6.
Il est vrai que Nvidia est depuis longtemps très impliqué en ce qui concerne OpenGL, et rapide à sortir des drivers (beta) supportant les dernières extensions...
Côté drivers je pense qu'il sera toujours nécessaire d'avoir une version proprio aux côté des drivers libres, car il est difficile d'atteindre la performance maximale d'une carte sans une connaissance intime du matériel, voire de la façon dont elle est utilisée dans les applis (jeux notamment). L'idéal amha est une spec ouverte pour garantir un maximum de liberté, et un driver proprio pour les quelques uns qui veulent tirer le maximum de leur carte.
[^] # Re: implémentation hardware
Posté par drakmaniso . En réponse au journal Sortie d'OpenGL 3.2. Évalué à 4.
Le passage OpenGL 2 vers OpenGL 3 a surtout été l'occasion de nettoyer l'API, et préparer sa modernisation. L'occasion aussi de passer dans l'API elle-même ce qui n'était avant que des extensions (donc déjà supportées par la majorité des cartes).
De plus, le pipeline des cartes étant devenu de plus en plus souple, il y a beaucoup d'évolutions qui peuvent s'implémenter par une simple mise à jour logicielle (tout en gardant le bénéfice d'une accélération matérielle). C'est aussi le cas pour DirectX: les cartes Direct3D 10.1 supporteront la plus grande partie de Direct3D 11.
[^] # Re: Fausse idée sur les garbages collectors
Posté par drakmaniso . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 0.
Je ne sais pas trop si c'est intéressant de continuer le débat, j'ai l'impression qu'on tourne en rond.
Peut-être que les années à venir me donneront tort, qu'on verra l'arrivée de systèmes de plus en plus haut niveau pour la gestion mémoire dans ce domaine. Pour l'instant je ne vois pas cette tendance.
[^] # Re: Fausse idée sur les garbages collectors
Posté par drakmaniso . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 0.
A ma connaissance, plus personne n'utilise les display lists dans le monde du jeu vidéo: tout passe par des VBO. Et, oui, le contenu de ces VBO est géré par le développeur.
Je ne comprends pas pourquoi tu parles de gérer les shaders vertex par vertex, où de réécrire les "fonctions de z-buffer". Quel est le rapport avec la gestion mémoire? Le seul impact que je vois c'est qu'il faut souvent regrouper les vertex par shader, et c'est en grande partie pour ça que l'on doit optimiser le contenu des VBO à la main.
Les uniforms buffers permettent surtout d'allouer un bloc de mémoire GPU et de choisir ce que l'on va y stocker, afin d'optimiser le transferts des uniforms entre le CPU et le GPU. Cela en lieu et place d'une allocation transparente gérée par l'API. Donc oui, on est dans plein dans le vif du sujet: passer d'une gestion automatisée à une gestion manuelle.
Enfin, "évaluer à priori le temps d'exécution" d'un GC ne suffit pas. Comme tu le dis, les performances des moteurs de rendus sont fonction de la complexité de la scène. Si un GC n'est pas capable de garantir que pour une scène de telle complexité son temps d'exécution sera inférieur à une valeur donnée, cela revient à autoriser la dégradation du framerate par un facteur inconnu...
[^] # Re: Fausse idée sur les garbages collectors
Posté par drakmaniso . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 2.
Sauf que:
- La véritable gestion mémoire se fait à l'intérieur des buffers alloués par des appels OpenGL; et là c'est le développeur qui y organise ses données, et y accède par un système de pointeur (relatif au début du buffer). L'api "de haut niveau" n'est pratiquement utlisée que pour réserver de la mémoire.
- OpenGL fournit des garanties sur quels appels peuvent déclencher une allocation, et quels appels ne le feront pas;
- le système "automatique" que tu décris pour les buffers consiste essentiellement à incrémenter/décrémenter un compteur pour chaque buffer, sachant qu'ils ne peuvent pas avoir de références circulaires; on est très loin d'un GC moderne; (par contre les buffers peuvent en théorie être déplacés)
- les extensions récentes (par exemple les uniform buffers d'openGL 3.1) cherchent souvent à donner un accès de plus en plus fin à la mémoire GPU;
La seule possibilité que je vois pour pouvoir intégrer un GC dans un moteur de rendu (toujours dans le contexte du jeu vidéo), ce serait de pouvoir mettre une borne supérieure sur son temps d'exécution à chaque frame. Est-ce possible sur certains GC?
[^] # Re: Fausse idée sur les garbages collectors
Posté par drakmaniso . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 2.
(Peut-être que ça en agace certains d'utiliser la qualification "temps-réel" pour ces usages, mais il faut bien faire une distinction avec les applis de type bureautique; et la distinction est qu'il y a bien, effectivement, une contrainte de temps, même si elle n'est pas "dure" comme pour les applications plus critiques.)
Dans ces domaines là, je n'ai pas connaissance d'une quelconque tendance à utiliser un GC. Il s'agit peut-être de frilosité, mais je pense surtout qu'on se situe à la limite des capacités du matériel utilisé (sur lequel on a aucune influence), et que la moindre perte de performance coûte.
En ce qui concerne l'explication sur java, cela me semble rejoindre ce que je disais: au final, on en revient à tout gérer à la main, donc à court-circuiter le GC pour les partie" hautes-performance".
Je tiens à préciser que je ne dénigre absolument pas les GC, j'ai longtemps été un apôtre d'Eiffel... Seulement je crois que ce n'est pas forcément un outil adapté à toutes les situations.
[^] # Re: Fausse idée sur les garbages collectors
Posté par drakmaniso . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 1.
En ce qui concerne les perfs des appels systèmes d'allocation mémoire, tu as tout à fait raison, c'est bien pour ça qu'on ne les utilises pas lorsqu'on a besoin d'être vraiment rapide. On alloue tout en bloc et on réutilise les mêmes zones de mémoires autant que possible. C'est en partie faisable avec un GC, mais en partie seulement, et cela revient à réinventer un système d'allocation manuelle pour empêcher que le GC ne se déclenche.
Je ne dit pas que c'est impossible, mais actuellement je n'ai connaissance d'aucun moteurs de rendus, ni d'aucun moteurs audio, qui utilise un GC. Et en ce qui concerne les premiers, la tendance me semble au contraire à être de plus en plus proche du hardware.
[^] # Re: Fausse idée sur les garbages collectors
Posté par drakmaniso . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 5.
Il y a un autre cas où la gestion directe est quasiment indispensable: pour le temps-réel et tout ce qui s'en rapproche. Par exemple un synthé audio, ou bien un moteur de rendu pour un jeu.
Sinon je suis entièrement d'accord, quelque soit l'approche utilisée il faut accorder de l'attention à l'utilisation de la mémoire.
J'ajouterai que en C/C++, la gestion mémoire ne se limite pas à apparier malloc et free; regrouper les allocations, réutiliser ce qui est déjà alloué, utiliser l'allocation sur le tas sont tout aussi importants.
[^] # Re: Le langage aussi?
Posté par drakmaniso . En réponse au journal SmartEiffel RIP. Évalué à 2.
http://sourceforge.net/projects/tecomp/
# Le langage aussi?
Posté par drakmaniso . En réponse au journal SmartEiffel RIP. Évalué à 5.
J'avais l'impression que les problèmes n'étaient pas limités à SmartEiffel, mais plutôt que le processus de standardisation chaotique avait entrainé (ou du moins accéléré) sa chute...
En tout cas c'est dommage, il y avait plein de bonnes choses dans ce langage. Et quand à SmartEiffel, ils avaient une approche originale de la compilation orientée objet (à base d'IDs et de branchement dichotomiques en lieu et place du tableau de méthodes). Sans oublier que c'était une excellente source de trolls...
[^] # Re: Workflow? gni?
Posté par drakmaniso . En réponse à la dépêche Journée de rencontre démo Blender chez Eyrolles à Paris. Évalué à 2.
Quand au choix des logiciels, depuis quand est-il obligatoire pour tout le monde de n'utiliser que du libre?
[^] # Re: Perdants...
Posté par drakmaniso . En réponse au journal Le voleur de logo. Évalué à 1.
Ceux que je qualifie d'"intégristes" (j'aurais dailleurs dû eviter ce terme trollesque) sont ceux qui dégainent (les lettres d'insultes) sans chercher à dialoguer. Et le pire est qu'ils le font en lieu et place des principaux intéressés.
[^] # Re: Perdants...
Posté par drakmaniso . En réponse au journal Le voleur de logo. Évalué à 1.
Par contre, je vois plus de l'insouciance qu'une volonté délibérée de nuire, et certainement pas orientée vers le libre. Cela aurait tout aussi bien pu tomber sur le logo d'une petite association, du site web d'une guilde de gamers, ou n'importe quoi d'autre.
[^] # Re: Perdants...
Posté par drakmaniso . En réponse au journal Le voleur de logo. Évalué à 1.
Et oui, je pense que l'échange de mails s'acheminait vers un règlement à l'amiable. Le représentant de la boite passe d'une désinvolture certaine à une attitude défensive, signe qu'il se sent "coincé". Il est regrettable mais presque compréhensible qu'il n'avoue pas son forfait, je reste sur l'impression qu'une simple proposition d'arrangement en provenance des gens d'Arch aurait réglé le problème.
Ils n'en ont pas eu le temps, et c'est ce que je déplore.
# Perdants...
Posté par drakmaniso . En réponse au journal Le voleur de logo. Évalué à -10.
L'échange de mail donne à penser que cela aurait pu se terminer par un arrangement pacifique, par exemple une autorisation d'utiliser le logo en échange de la reconnaissance de sa provenance. Gagnant pour tout le monde. Au lieu de cela, la réputation belliqueuse des libristes est une nouvelle fois renforcée.
J'espère que cette tendance va finir par s'inverser, parce que, personnellement, j'hésite de plus en plus à promouvoir le libre: c'est presque devenu synonyme d'agression.
[^] # Re: ...on ressort la nébulatique
Posté par drakmaniso . En réponse au journal encore un coup de google. Évalué à 8.
En gros, avec deux serveurs A et B, les communications entre utilisateurs de A sont stockées uniquement sur A, seules celles impliquant à la fois des utilisateurs de A et B sont partagées. Sachant que même dans une "wave" (conversation) partagée entre plusieurs serveurs, une partie des échanges peut être privée et ne jamais quitter leur serveur d'origine. Et cela semble fonctionner quelque soit le nombre de serveurs impliqués...
Et effectivement, les 1h20 de vidéos valent vraiment le coup.
http://www.youtube.com/watch?v=v_UyVmITiYQ
[^] # Re: J'ai envie de dire « Dommage »...
Posté par drakmaniso . En réponse au journal Intel se fait taper sur les doigts. Évalué à 3.
Le gros problème du serveur X, c'est qu'il n'y a pas beaucoup de développeurs qui s'y intéressent. Alors que c'est probablement l'un des composants qui en a le plus besoin. Malheureusement, c'est une couche logicielle "invisible", qui ne passionne donc pas les utilisateurs finaux; et comme ça ne fait pas partie du noyau, ça ne passionne pas non plus les développeurs...
[^] # Re: J'ai envie de dire « Dommage »...
Posté par drakmaniso . En réponse au journal Intel se fait taper sur les doigts. Évalué à 10.
Choisir telle ou telle carte vidéo parce que son constructeur fournit des drivers ou des specs libres, c'est une chose. Utiliser ce même critère pour lui accorder carte blanche (ou peut s'en faut), c'est très différent.
De plus l'implication d'Intel dans le libre peut-être interprété de plusieurs façons, et tout n'est pas forcément aussi idyllique que ce que tu sembles croire. Leur poids dans le développement du serveur X, par exemple, est à double tranchant: ils poussent en avant des technos privilégiant les puces de type "chipsets intégrés", au détriment de solutions plus générales (voir leur introduction d'UXA à la place d'EXA). C'est compréhensible (pourquoi faciliter la vie aux concurrents?), mais à long terme, cela peut nous apporter plus de nuisances que de bienfaits.
[^] # Re: Fortune !
Posté par drakmaniso . En réponse au journal IHM et le libre. Évalué à 6.
Quand on utilise une appli de manière intensive, minimiser le nombre d'actions à faire pour exécuter une tâche est un aspect important de la convivialité.
Ce que certains appellent un "cliquodrome", c'est fantastique lors des premières utilisations, mais ça peut vite devenir très énervant, et ça, AMHA, c'est une question de convivialité. Une appli qui énerve, on a pas envie de l'utiliser: comment peut-on encore la qualifier de conviviale?