C'est un client pour jouer, avec sûrement pas mal de dette technique.
Mouai.
Steam date de 2003, les archi 64 n'étaient certes pas encore populaires à l'époque, mais existaient déjà.
Et franchement, porter un code haut niveau de 32 bits à 64 bits, ça me semble nettement moins complexe que de porter de windows à Linux.
Du coup, comment justifier, malgré le portage à un OS totalement différent, en effet...
Comment le justifier ?
Déjà, par l'intégration au système.
Sinon, je ne connais pas les détails pour windows, mais de nos jours sur Debian, Ubuntu, et donc probablement sur SteamOS, avoir un seul paquet 32 bits implique d'installer toutes ses dépendances en 32 bits, ce qui fait pas mal de doublons.
Donc, performance de 2 points de vue:
* disque dur (et si tu me dis que nos disques durs de nos jours ne voient pas la différence,
* bande passante
Pour ce qui est des performances, si elles ne sont pas importantes, expliques-moi pourquoi Steam dépends de libgl1-mesa-dri (et libtxc)? Ce paquet, de mémoire, permets l'utilisation d'OpenGL (et txc la compression des textures).
Je note aussi une dépendance à xz-utils, qui sert pour compresser (encore).
Pour toi, la performance n'a peut-être aucun intérêt, et d'ailleurs, la performance en CPU d'un client 32 bits pourrait même bien être parfois supérieure à celle d'un client 64 bits (à priori, dans les binaires 64bits, les pointeurs pèsent 8 octets chacun, contre 4 dans les 32 bits, qui vont donc moins saturer les caches pour rien, la plupart des applications n'ayant pas besoin d'adresser 4Gio de ram), mais steam est un outil qui tourne en arrière-plan (mais est actif) en même temps que des jeux vidéos, applications souvent gourmandes.
Donc, pomper le moins possible pour laisser de la place aux jeux me semble utile (pour le disque, je t'accorde qu'en regard de l'espace occupé par les jeux c'est négligeable, surtout qu'on peut l'étendre. C'est moins vrai pour l'usage CPU des caches, ceci dit).
Le fait d'utiliser des builds x86 de bibliothèques implique aussi de s'exposer à plus de risque de bugs, puisqu'il y a de moins en moins de machines x86 vendues (je suis pas sûr que du matériel x86 neuf soit encore vendus, en fait) et donc très probablement moins de tests et d'attention accordés à cette architecture.
Pour finir, il y a probablement au moins autant d'intérêt à porter Steam en 64 bits, que Skype, qui a probablement une dette technique équivalente, puisque 1ère version la même année (2003) selon wikipedia.
[^] # Re: +Steam
Posté par freem . En réponse à la dépêche Sortie de « La bataille pour Wesnoth » 1.14. Évalué à 4.
Mouai.
Steam date de 2003, les archi 64 n'étaient certes pas encore populaires à l'époque, mais existaient déjà.
Et franchement, porter un code haut niveau de 32 bits à 64 bits, ça me semble nettement moins complexe que de porter de windows à Linux.
Du coup, comment justifier, malgré le portage à un OS totalement différent, en effet...
Déjà, par l'intégration au système.
Sinon, je ne connais pas les détails pour windows, mais de nos jours sur Debian, Ubuntu, et donc probablement sur SteamOS, avoir un seul paquet 32 bits implique d'installer toutes ses dépendances en 32 bits, ce qui fait pas mal de doublons.
Donc, performance de 2 points de vue:
* disque dur (et si tu me dis que nos disques durs de nos jours ne voient pas la différence,
* bande passante
Pour ce qui est des performances, si elles ne sont pas importantes, expliques-moi pourquoi Steam dépends de libgl1-mesa-dri (et libtxc)? Ce paquet, de mémoire, permets l'utilisation d'OpenGL (et txc la compression des textures).
Je note aussi une dépendance à xz-utils, qui sert pour compresser (encore).
Pour toi, la performance n'a peut-être aucun intérêt, et d'ailleurs, la performance en CPU d'un client 32 bits pourrait même bien être parfois supérieure à celle d'un client 64 bits (à priori, dans les binaires 64bits, les pointeurs pèsent 8 octets chacun, contre 4 dans les 32 bits, qui vont donc moins saturer les caches pour rien, la plupart des applications n'ayant pas besoin d'adresser 4Gio de ram), mais steam est un outil qui tourne en arrière-plan (mais est actif) en même temps que des jeux vidéos, applications souvent gourmandes.
Donc, pomper le moins possible pour laisser de la place aux jeux me semble utile (pour le disque, je t'accorde qu'en regard de l'espace occupé par les jeux c'est négligeable, surtout qu'on peut l'étendre. C'est moins vrai pour l'usage CPU des caches, ceci dit).
Le fait d'utiliser des builds x86 de bibliothèques implique aussi de s'exposer à plus de risque de bugs, puisqu'il y a de moins en moins de machines x86 vendues (je suis pas sûr que du matériel x86 neuf soit encore vendus, en fait) et donc très probablement moins de tests et d'attention accordés à cette architecture.
Pour finir, il y a probablement au moins autant d'intérêt à porter Steam en 64 bits, que Skype, qui a probablement une dette technique équivalente, puisque 1ère version la même année (2003) selon wikipedia.