Monter un PC. - Page 16

$ cat > Makefile
all: t1 t2 t3 t4 t5 t6 t7 t8
t%:
        dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

$ time make -j1
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    0m32.498s
user    0m28.242s
sys     0m1.274s

$ time make -j4
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    0m8.440s
user    0m27.900s
sys     0m1.118s

$ time make -j8
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    0m8.289s
user    0m27.698s
sys     0m1.131s

(XP64, pas sûr que ça joue bcp)

(XP32 chez moi et j'ai vu la nette différence en passant de bicore à quadcore le WE dernier)

Une différence sur quoi ? Mon PC tourne avec un AMD 64 3500+ tout con et rien ne me paraît lent. Vous faites du montage vidéo ?

Y a plein de possibilités, compression, montage vidéo / audio, encodage de divx, jeux, résolution de programmes linéaires, etc...

Tu as quoi comme machine Pollux ?

MacBook-Pro-de-MTR:tmp godzil$ time make -j1 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
time make -j4
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
time make -j8
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 

real	1m4.397s
user	0m0.033s
sys	1m3.589s
MacBook-Pro-de-MTR:tmp godzil$ time make -j4
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 

real	1m3.076s
user	0m0.029s
sys	1m3.072s
MacBook-Pro-de-MTR:tmp godzil$ time make -j8
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null 

real	1m3.091s
user	0m0.028s
sys	1m3.134s

/dev/urandom est peut-etre pas un foudre de guerre sous Mac OS X, mais la le -jx ne change rien (a croire qu'il est pas accessible en multithreadé, ce qui d'ailleurs est fort possible)

Thibaut (./453) :
Une différence sur quoi ? Mon PC tourne avec un AMD 64 3500+ tout con et rien ne me paraît lent. Vous faites du montage vidéo ?

Perso, ça me permet (enfin) d'utiliser proprement les réverbs à convolution que je ne pouvais pas utiliser avec mon 2800+

Godzil (./455) :
Tu as quoi comme machine Pollux ?

un Q6600, je crois, avec XP64 + cygwin, je suppose ?

Fedora 9 x86_64 sur un Core 2 Duo T7700 (2 cores, donc évidemment ça ne speede plus au-delà de -j2):

[kevin@laptop64 ~]$ time make -j1
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    1m14.005s
user    0m0.015s
sys     1m13.948s
[kevin@laptop64 ~]$ time make -j2
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    0m39.416s
user    0m0.011s
sys     1m18.548s
[kevin@laptop64 ~]$ time make -j4
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    0m39.487s
user    0m0.019s
sys     1m18.803s
[kevin@laptop64 ~]$ time make -j8
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null
dd if=/dev/urandom of=/dev/null bs=64k count=1000 2>/dev/null

real    0m39.469s
user    0m0.015s
sys     1m18.749s

Je vous laisse tirer vos conclusions sur l'utilisation du multicore de la part de OS X (./455).

Kevin Kofler (./458) :
Je vous laisse tirer vos conclusions sur l'utilisation du multicore de la part de OS X (./455).

Marrant, on ne lit pas la même chose Ici

Tu sais kevin, c'est pas forcement un probleme de multicore contrairement a ce que tu dit, je suis persuadé que /dev/urandom, n'est pas accessible par plusieurs process en meme temps. (sans compter que le code derriere n'est surement pas optimal, vu la différence entre pollux et moi alors qu'au nombre de core pret, on a le meme CPU (Core 2 peryn @ 2.4ghz, 2core ici 4 core lui)

Godzil (./460) :
Tu sais kevin, c'est pas forcement un probleme de multicore contrairement a ce que tu dit, je suis persuadé que /dev/urandom, n'est pas accessible par plusieurs process en meme temps.

J'appelle ça un problème de multicore ça, ce device est SMP-safe partout ailleurs, pourquoi pas sous OS X? Lock inutile == perte de performance en multicore!

Core 2 peryn @ 2.4ghz, 2core ici

T7700? (C'est le mien et il est à 2,4 GHz.)

AMHA le code /dev/urandom est moins rapide sous les *nix (F9 aussi) parce qu'il est plus complexe pour une meilleure sécurité. (D'ailleurs, Pollux, qu'as utilisé pour ces tests sous XP? SFU/Interix? Cygwin? MSYS?)

(C'est vrai que c'est le device le plus utilisé au monde ! )

(d'ailleurs sous OS X les /dev sont rarement utilisé directement par les applications donc bon en plus je pense qu'il a du etre posé la pour une compatibilitée avec certaines applications Unix)

Flanker (./457) :

Godzil (./455) :
Tu as quoi comme machine Pollux ?

un Q6600, je crois, avec XP64 + cygwin, je suppose ?

Apparemment le code est là, Cygwin fait simplement appel à l'API de windows (et en cas d'échec /dev/urandom utilise un vieux générateur linéaire merdique, mais normalement /dev/urandom = /dev/random [c'est bien le cas chez moi])

J'ai trouvé la réponse :

/dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will
produce lower quality output if the entropy pool drains, while
/dev/random will prefer to block and wait for additional entropy to be
collected. With Yarrow, this choice and distinction is not necessary, and the two devices behave identically. You may use either.

From the RANDOM(4) BSD Kernel Interfaces Manual

/dev/random est la meme chose que /dev/urandom sur tout sauf Linux ou urandom est une version "amoindrie" de /dev/random

Godzil (./464) :
With Yarrow, this choice and distinction is not necessary,

Yarrow net ?

Godzil (./464) :
J'ai trouvé la réponse :

/dev/urandom is a compatibility nod to Linux. On Linux, /dev/urandom will
produce lower quality output if the entropy pool drains, while
/dev/random will prefer to block and wait for additional entropy to be
collected. With Yarrow, this choice and distinction is not necessary,and the two devices behave identically. You may use either.

From the RANDOM(4) BSD Kernel Interfaces Manual

Euh non, tu n'as rien trouvé, ça n'explique pas du tout pourquoi ce n'est pas SMP-safe, ça dit juste que /dev/urandom == /dev/random sous *BSD.

/dev/random est la meme chose que /dev/urandom sur tout sauf Linux ou urandom est une version "amoindrie" de /dev/random

C'est plutôt l'inverse, /dev/random est plus puissante du point de vue sécurité parce qu'elle bloque si elle n'a pas d'entropie réelle, apparemment *BSD fonctionne toujours comme /dev/urandom.

Bref tu sais pas lire :

On Linux, /dev/urandom will produce lower quality output if the entropy pool drains, while /dev/random will prefer to block and wait for additional entropy to be collected.

/dev/urandom est plus sujet a problemes que /dev/random

Et c'est ce qui rend /dev/urandom plus rapide /dev/random

et *BSD utilise toujours l'équivalent de /dev/random et non urandom

Godzil (./467) :
Bref tu sais pas lire :

Toujours très aimable à ce que je vois

Bah pollux, il a pas bien lu j'y peut rien

Oui oui mais t'es pas spécialement obligé de le dire comme ça ^^

Ben non, *BSD ne bloque jamais pour attendre que l'utilisateur appuie sur des touches ou bouge sa souris pour créer de l'entropie, donc c'est comme /dev/urandom, c'est moins secure que le /dev/random du noyau Linux.

Et sinon, regarde un peu les chiffres avant de discuter la rapidité. /dev/(u)random sous OS X n'est pas plus ni moins rapide (enfin, à 10 secondes près) que /dev/urandom sous Linux (en revanche c'est 2 fois plus rapide sous XP, je vous laisse tirer vos conclusion sur la qualité de leur générateur de nombres pseudoaléatoires, visiblement ils ont priviliégié la vitesse par rapport à la sécurité), le problème sous OS X, c'est qu'il y a un lock qui empêche l'accès simultané par plusieurs cores.

(Bref, c'est qui qui ne sait pas lire?)

http://en.wikipedia.org/wiki/Urandom

"The [Linux] implementation was also designed with the assumption that any given hash or cipher might eventually be found to be weak, and so the design is durable in the face of any such weaknesses." alors que *BSD a une confiance aveugle en leur algorithme Yarrow, "based on the assumptions that modern PRNGs are very secure if their internal state is unknown to an attacker".

Ils disent même clairement: "Unlike the Linux /dev/random, the FreeBSD /dev/random never blocks. It is similar to the Linux /dev/urandom".

Kevin Kofler (./471) :
en revanche c'est 2 fois plus rapide sous XP, je vous laisse tirer vos conclusion sur la qualité de leur générateur de nombres pseudoaléatoires, visiblement ils ont priviliégié la vitesse par rapport à la sécurité

C'est rapide sous XP => C'est mal codé
C'est rapide sous Linux => C'est optimisé

J'ai bon ? ##triroll##

Bienvenue sur yAronet !

Flanker (./473) :

Kevin Kofler (./471) :
en revanche c'est 2 fois plus rapide sous XP, je vous laisse tirer vos conclusion sur la qualité de leur générateur de nombres pseudoaléatoires, visiblement ils ont priviliégié la vitesse par rapport à la sécurité

C'est rapide sous XP => C'est mal codé
C'est rapide sous Linux => C'est optimisé

J'ai bon ? ##triroll##

C'est sous XP => C'est mal codé
C'est sous Linux => C'est optimisé


je dirais plutôt

Thibaut (./453) :
Une différence sur quoi ? Mon PC tourne avec un AMD 64 3500+ tout con et rien ne me paraît lent. Vous faites du montage vidéo ?

oui, depuis que j'ai un camescope ^^

mais aussi le truc qui a été le plus probant c'est Forged Alliance, il sait tirer profit de ce type d'archi...

avec mon core2duo, j'avais des ralentissements en qualité 'basse' alors qu'avec le core2quad, c'est fluide avec les détails au maxi... (et en plus j'ai pu augmenter la résolution d'un des deux écrans)

D'acc.

Re à tous,

Vu que mes 2 pauvres disques durs IDE ne me permettent pas de profiter de tout ce que /hc/ l'internet a à m'offrir de gratuit et libre, il m'en faut un, et un de type MADNESS (pourquoi ? Parce THIS IS S-AATAAAAAAAAAAAAAAAA ). Vous avez un à me conseiller en particulier ? Kudos pour un qui se trouve sur materiel.net (je compte commander dessus bientôt, alors pour économiser des fdp...) Seagate est une bonne marque non ?
Merci d'avance

http://www.materiel.net/ctl/Disques_durs_internes_SATA/31703-Barracuda_7200_11_S_ATA_750_Go_32_Mo.html

Seagate parce que garanti 5 ans.

Attention quand-même à sauvegarder bien les données, les garanties des disques durs (que ce soient les 5 années de Seagate ou les durées plus courtes proposées par d'autres producteurs) ne couvrent pas les données sur le disque et une récupération de ces données comme la proposent certaines entreprises spécialisées est limite impayable.