On Sat, 25 Feb 2012 18:05:55 +0300, Alain Rédic wrote:
Le 24/02/2012 23:41, Williamhoustra a écrit :
A propos de Linux, une question : la distrib Ubuntu dernière est présentée en "32 bits (recommandé)". Pourquoi pas 64 bits ?
la 12.04, à venir en avril de cette année, verra la version 64 bits proposée par défaut.
Vivement la 12.04 que je reinstalle ma machine (la fleme de le faire pour si peut de temps)
Nicolas George
Alain Rédic , dans le message <jib53g$1rhb$, a écrit :
mon pourquoi s'adresse à jp w quand il dit que ça ne s'applique pas à linux !
Mon message expliquait pourquoi il y a plein de bonnes raisons de préférer x86_64 même quand on a nettement moins de 4 Go de RAM. Ces raisons sont valables pour tous les systèmes.
Il est possible que, ponctuellement, tel système soit mal réalisé au point que ses inconvénients surpassent les raisons que j'ai données. Ce n'est pas le cas de Linux x86_64.
Alain Rédic , dans le message <jib53g$1rhb$1@talisker.lacave.net>, a
écrit :
mon pourquoi s'adresse à jp w quand il dit que ça ne s'applique pas à
linux !
Mon message expliquait pourquoi il y a plein de bonnes raisons de préférer
x86_64 même quand on a nettement moins de 4 Go de RAM. Ces raisons sont
valables pour tous les systèmes.
Il est possible que, ponctuellement, tel système soit mal réalisé au point
que ses inconvénients surpassent les raisons que j'ai données. Ce n'est pas
le cas de Linux x86_64.
Alain Rédic , dans le message <jib53g$1rhb$, a écrit :
mon pourquoi s'adresse à jp w quand il dit que ça ne s'applique pas à linux !
Mon message expliquait pourquoi il y a plein de bonnes raisons de préférer x86_64 même quand on a nettement moins de 4 Go de RAM. Ces raisons sont valables pour tous les systèmes.
Il est possible que, ponctuellement, tel système soit mal réalisé au point que ses inconvénients surpassent les raisons que j'ai données. Ce n'est pas le cas de Linux x86_64.
Nicolas George
Pascal Hambourg , dans le message <ji99bc$hl7$, a écrit :
Je pense qu'il veut dire que lorsque la quantité de mémoire physique est du même ordre de grandeur que l'espace d'adressage des processus comme c'est le cas en 32 bits, la fragmentation de ce dernier, résultant d'allocations et désallocations successives, peut conduire à une situation où il est impossible d'allouer un bloc de mémoire non par manque de mémoire physique mais par manque d'espace d'adressage contigu de taille suffisante.
Par exemple.
Un autre exemple se rencontre quand un mécanisme compte sur de l'overcommit. Par exemple, essayez de transcoder un Matroska affublé de sous-titres vers une haute résolution avec un avconv récent (moins d'une semaine) compilé en 32 bits.
Bien sûr, compter sur l'overcommit est toujours cavalier, et ici ce n'était en outre absolument pas nécessaire. D'ailleurs, un ffmpeg très récent (moins d'une demi-heure) n'a pas le problème.
Pascal Hambourg , dans le message <ji99bc$hl7$1@saria.nerim.net>, a
écrit :
Je pense qu'il veut dire que lorsque la quantité de mémoire physique est
du même ordre de grandeur que l'espace d'adressage des processus comme
c'est le cas en 32 bits, la fragmentation de ce dernier, résultant
d'allocations et désallocations successives, peut conduire à une
situation où il est impossible d'allouer un bloc de mémoire non par
manque de mémoire physique mais par manque d'espace d'adressage contigu
de taille suffisante.
Par exemple.
Un autre exemple se rencontre quand un mécanisme compte sur de l'overcommit.
Par exemple, essayez de transcoder un Matroska affublé de sous-titres vers
une haute résolution avec un avconv récent (moins d'une semaine) compilé en
32 bits.
Bien sûr, compter sur l'overcommit est toujours cavalier, et ici ce n'était
en outre absolument pas nécessaire. D'ailleurs, un ffmpeg très récent (moins
d'une demi-heure) n'a pas le problème.
Pascal Hambourg , dans le message <ji99bc$hl7$, a écrit :
Je pense qu'il veut dire que lorsque la quantité de mémoire physique est du même ordre de grandeur que l'espace d'adressage des processus comme c'est le cas en 32 bits, la fragmentation de ce dernier, résultant d'allocations et désallocations successives, peut conduire à une situation où il est impossible d'allouer un bloc de mémoire non par manque de mémoire physique mais par manque d'espace d'adressage contigu de taille suffisante.
Par exemple.
Un autre exemple se rencontre quand un mécanisme compte sur de l'overcommit. Par exemple, essayez de transcoder un Matroska affublé de sous-titres vers une haute résolution avec un avconv récent (moins d'une semaine) compilé en 32 bits.
Bien sûr, compter sur l'overcommit est toujours cavalier, et ici ce n'était en outre absolument pas nécessaire. D'ailleurs, un ffmpeg très récent (moins d'une demi-heure) n'a pas le problème.
Pascal Hambourg
Nicolas George a écrit :
Un autre exemple se rencontre quand un mécanisme compte sur de l'overcommit. Par exemple, essayez de transcoder un Matroska affublé de sous-titres vers une haute résolution avec un avconv récent (moins d'une semaine) compilé en 32 bits.
C'est-à-dire, que se passe-t-il ? L'application demande tellement de mémoire qu'elle remplit son espace d'adressage ?
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits est l'impossibilité de mapper en mémoire entièrement un fichier de plus de 2 à 3 Go selon l'OS.
Nicolas George a écrit :
Un autre exemple se rencontre quand un mécanisme compte sur de l'overcommit.
Par exemple, essayez de transcoder un Matroska affublé de sous-titres vers
une haute résolution avec un avconv récent (moins d'une semaine) compilé en
32 bits.
C'est-à-dire, que se passe-t-il ?
L'application demande tellement de mémoire qu'elle remplit son espace
d'adressage ?
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits
est l'impossibilité de mapper en mémoire entièrement un fichier de plus
de 2 à 3 Go selon l'OS.
Un autre exemple se rencontre quand un mécanisme compte sur de l'overcommit. Par exemple, essayez de transcoder un Matroska affublé de sous-titres vers une haute résolution avec un avconv récent (moins d'une semaine) compilé en 32 bits.
C'est-à-dire, que se passe-t-il ? L'application demande tellement de mémoire qu'elle remplit son espace d'adressage ?
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits est l'impossibilité de mapper en mémoire entièrement un fichier de plus de 2 à 3 Go selon l'OS.
Nicolas George
Pascal Hambourg , dans le message <jilqjl$20dp$, a écrit :
C'est-à-dire, que se passe-t-il ? L'application demande tellement de mémoire qu'elle remplit son espace d'adressage ?
Oui, c'est à peu près ça. La nouvelle API d'encodage réserve d'énormes paquets (de l'ordre de dix octets par pixel) pour ne pas avoir à se préoccuper des bornes, et les remplit évidemment très peu (c'est de la compression vidéo, quand même). S'il y a des sous-titres à gérer en même temps, les paquets vidéo s'accumulent en attendant les paquets de sous-titres pour la synchronisation. En espace d'adressage, du 720p va bouffer près de 10 Go pour une minute de vidéo, pour seulement quelques dizaines de méga-octets effectivement utilisés.
La solution est évidemment de rétrécir les paquets à la fin.
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits est l'impossibilité de mapper en mémoire entièrement un fichier de plus de 2 à 3 Go selon l'OS.
En effet. Ou même un filesystem entier, d'ailleurs.
Pascal Hambourg , dans le message <jilqjl$20dp$1@saria.nerim.net>, a
écrit :
C'est-à-dire, que se passe-t-il ?
L'application demande tellement de mémoire qu'elle remplit son espace
d'adressage ?
Oui, c'est à peu près ça. La nouvelle API d'encodage réserve d'énormes
paquets (de l'ordre de dix octets par pixel) pour ne pas avoir à se
préoccuper des bornes, et les remplit évidemment très peu (c'est de la
compression vidéo, quand même). S'il y a des sous-titres à gérer en même
temps, les paquets vidéo s'accumulent en attendant les paquets de
sous-titres pour la synchronisation. En espace d'adressage, du 720p va
bouffer près de 10 Go pour une minute de vidéo, pour seulement quelques
dizaines de méga-octets effectivement utilisés.
La solution est évidemment de rétrécir les paquets à la fin.
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits
est l'impossibilité de mapper en mémoire entièrement un fichier de plus
de 2 à 3 Go selon l'OS.
En effet. Ou même un filesystem entier, d'ailleurs.
Pascal Hambourg , dans le message <jilqjl$20dp$, a écrit :
C'est-à-dire, que se passe-t-il ? L'application demande tellement de mémoire qu'elle remplit son espace d'adressage ?
Oui, c'est à peu près ça. La nouvelle API d'encodage réserve d'énormes paquets (de l'ordre de dix octets par pixel) pour ne pas avoir à se préoccuper des bornes, et les remplit évidemment très peu (c'est de la compression vidéo, quand même). S'il y a des sous-titres à gérer en même temps, les paquets vidéo s'accumulent en attendant les paquets de sous-titres pour la synchronisation. En espace d'adressage, du 720p va bouffer près de 10 Go pour une minute de vidéo, pour seulement quelques dizaines de méga-octets effectivement utilisés.
La solution est évidemment de rétrécir les paquets à la fin.
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits est l'impossibilité de mapper en mémoire entièrement un fichier de plus de 2 à 3 Go selon l'OS.
En effet. Ou même un filesystem entier, d'ailleurs.
Pascal Hambourg
Nicolas George a écrit :
Pascal Hambourg , dans le message <jilqjl$20dp$, a écrit :
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits est l'impossibilité de mapper en mémoire entièrement un fichier de plus de 2 à 3 Go selon l'OS.
En effet. Ou même un filesystem entier, d'ailleurs.
Tu parles d'un block device contenant un système de fichiers (ça reste un fichier, bien que spécial), ou d'autre chose ?
Nicolas George a écrit :
Pascal Hambourg , dans le message <jilqjl$20dp$1@saria.nerim.net>, a
écrit :
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits
est l'impossibilité de mapper en mémoire entièrement un fichier de plus
de 2 à 3 Go selon l'OS.
En effet. Ou même un filesystem entier, d'ailleurs.
Tu parles d'un block device contenant un système de fichiers (ça reste
un fichier, bien que spécial), ou d'autre chose ?
Pascal Hambourg , dans le message <jilqjl$20dp$, a écrit :
En parlant de gros fichiers, il me semble qu'une limitation en 32 bits est l'impossibilité de mapper en mémoire entièrement un fichier de plus de 2 à 3 Go selon l'OS.
En effet. Ou même un filesystem entier, d'ailleurs.
Tu parles d'un block device contenant un système de fichiers (ça reste un fichier, bien que spécial), ou d'autre chose ?
Az Sam
"HAAAAAA, c'est la fin du monde on va tous MOURIR." a écrit dans le message de
Vivement la 12.04 que je reinstalle ma machine
pourquoi faut il réinstaller ?
-- Cordialement, Az Sam.
"HAAAAAA, c'est la fin du monde on va tous MOURIR." <Yenapa@pasdemail.spam>
a écrit dans le message de
