Eric Masson <emss@free.fr> wrote:
> talon@lpthe.jussieu.fr (Michel Talon) writes:
>
> 'Lut,
>
> > Oui, mais avec tous les tests que je vois sur plusieurs machines Core 2
> > Duo (sous Linux, il est vrai) la plupart des programmes (aussi bien des
> > caluls numériques que des calculs formels avec maple) tournent entre 1.5
> > et 2 fois plus vite en 64 bits qu'en 32 bits, excuse du peu.
>
> Au hasard, machines gavées de ram et gros volumes de données à traiter,
> non ?
>

Machines avec 1 ou 2 Gig de ram et des programmes qui tiennent dans
toute la mémoire, bien sûr. Pour des programmes plus petits, qui
tiennent dans le cache, l'effet est moins sensible, de l'ordre de 20%.
Au total il y a *constamment* un avantage considérable à tourner en 64
bits, beaucoup plus considérable que ce dont on parle dans les tests
sous Windows qui passent dans les revues. Donc à mon avis, à part le cas
où on rencontre des bugs, utiliser systématiquement la version amd64 de
l'OS me semble une bonne idée.


--

Michel TALON

fredmfp@gmail.com wrote:
>
> Michel Talon a écrit :
>
> > Oui, mais avec tous les tests que je vois sur plusieurs machines Core 2
> > Duo (sous Linux, il est vrai) la plupart des programmes (aussi bien des
> > caluls numériques que des calculs formels avec maple) tournent entre 1.5
> > et 2 fois plus vite en 64 bits qu'en 32 bits, excuse du peu.
> Justement.
> C'est une machine de calcul.
> (ben oui, on peut vouloir le son, mplayer et les ports usb fonctionnels
> sur une machine de calcul, non ? ;-)
> Je n'ai pas (encore ?) de Core 2 Duo, mais un Pentium D 930.
> Et jamais au grand jamais, sous mes debian, je n'ai vu un tel facteur
> pour mes codes de
> calculs (calcul bourrin sur quadruple boucle) entre la version i686 et
> la version x86_64.

Oui mais le Pentium D c'est nul. Des écarts comme ça j'en avais vu avec
la seule machine Athlon64 qu'on ait au labo. On a reçu récemment une
dizaine de Core 2 Duo, et des laptops en Core 2 Duo, et on voit cet
effet sur toutes les machines. C'est particulièrement frappant avec le
calcul formel utilisant la version 64 bits de Maple10. Quand on voit des
calculs de plusieurs heures qui sont raccourcis par un facteur presque 2
ça fait une différence qu'on ne peut pas faire semblant de ne pas voir.
(je parle du même calcul exactement, effectué soit avec maple10 32 bits
sur Ubuntu 32 bits, ou avec maple10 64 bits sur Ubuntu 64 bits, sur la
même machine). Les calculs numériques dont la taille est voisine de la
taille du cache peuvent faire croire a un effet inverse, si par exemple
le calcul en 32 bits tient dans le cache, mais le calcul en 64 bits ne
tient pas parcequ'il est un peu plus gros - des pointeurs plus gros,
etc. Tu peux alors croire que la machine est plus efficace en 32 bits.
C'est tout de suite ce que certains collègues ont dit car ils ont des
simulations très petites. Dès que tu charges la machine avec un calcul
qui tient sur 500 megs tu vois tout de suite cet effet disparaître
complètement - là encore si le calcul explore effectivement la totalité
de son espace de travail et ne se confine pas à un petit bout qui teint
dans le cache.



--

Michel TALON

talon@lpthe.jussieu.fr (Michel Talon) a écrit :

> fredmfp@gmail.com wrote:
>>
>> Michel Talon a écrit :
>>
>> > Oui, mais avec tous les tests que je vois sur plusieurs machines Core 2
>> > Duo (sous Linux, il est vrai) la plupart des programmes (aussi bien des
>> > caluls numériques que des calculs formels avec maple) tournent entre 1.5
>> > et 2 fois plus vite en 64 bits qu'en 32 bits, excuse du peu.
>> Justement.
>> C'est une machine de calcul.
>> (ben oui, on peut vouloir le son, mplayer et les ports usb fonctionnels
>> sur une machine de calcul, non ? ;-)
>> Je n'ai pas (encore ?) de Core 2 Duo, mais un Pentium D 930.
>> Et jamais au grand jamais, sous mes debian, je n'ai vu un tel facteur
>> pour mes codes de
>> calculs (calcul bourrin sur quadruple boucle) entre la version i686 et
>> la version x86_64.
>
> Oui mais le Pentium D c'est nul.
(tm) :-))

Sans parler de Core 2 Duo, et en considérant des bécanes plus standard,
c'est-à-dire Pentium xxx, j'ai lu ça et là, qu'on pouvait obtenir un
gain en perf de l'ordre de 20% entre 32 et 64 bits. Ben même 20% j'y
arrive pas :-(

Mais bon, on va finir OT à ce rythme là ;-)

--
Fred.

Eric Masson <emss@free.fr> a écrit :

> fredmfp@gmail.com writes:
>
> 'Lut,
>
>> Y a une contre-indication à mettre cvsup.fr.freebsd.org ?
>> C'est ce que j'avais mis. Pas assez uptodate ?
>
> Nan, c'est juste qu'il arrive que cvsup.fr soit aux fraises (injoignable
> ou alors non synchronisé avec les maîtres) alors que cvsup.uk ne m'a
> jamais posé ce genre de problème.
Ok, je le note.

>> Bon, ok, je recadre tout, j'arrête de partir dans tous les sens, et
>> j'attaque les problèmes un à un.
>> Question, quand même : j'en fais quoi de ma 6.2 ?
>> Est-ce que je peux downgrader vers la 6.1, ou je (re)pars from scratch
>> ?
>
> Downgrader, ça se fait, mais ça peut être un peu casse gueule, doncsi
> tu ne le sens pas, réinstallation from scratch d'une 6.1.
Hmm, je m'en doutais :-(

> Pour les mises à jour de sécurité, le Security Officer de FreeBSD amis
> au point FreeBSD-update qui permet la mise à jour des releases
> supportées sans avoir à se préocupper des sources :
> http://www.daemonology.net/freebsd-update/
>
> Le client est installable via les ports ou en package :
> $ pkg_add -r freebsd-update
Ok.

> Pour le passage en 6.2, il vaut mieux attendre que la release soit
> sortie et que la poussière soit retombée.
Re ok.

Merci.

--
Fred.

fred wrote:
>
> Sans parler de Core 2 Duo, et en considérant des bécanes plus standard,
> c'est-Ã-dire Pentium xxx, j'ai lu ça et lÃ, qu'on pouvait obtenir un
> gain en perf de l'ordre de 20% entre 32 et 64 bits. Ben même 20% j'y
> arrive pas :-(

Ca dépend aussi pas mal du type de travail que la bécane doit effectuer.
Pour FreeBSD, la version i386 est tellement optimisée qu'en dehors de
quelques domaines comme le calcul pur et la crypto, elle est plus rapide
que la version amd64.

Ca tient au fait que beaucoup de fonctions bas niveau sont écrites en
assembleur alors qu'en amd64, on doit se contenter de versions en C plus
lentes.

--
Francois Tigeot

fred a écrit :


> Et pis on peut y mettre le clavier en français aussi.


Bigre, j'ai pas touché un Free depuis la 4.5
Je ne me souviens pas avec bricolé le noyo pour avoir
le clavier français

Eric Masson a écrit :

> Mouaif, compiler un machin linusque sur une machine free et s'attendre à
> ce que ça fonctionne sans soucis est amha, un poil optimiste...

faire un GNU/BSD à la sauce Debian ça craint également

Le 12 décembre 2006 à 23:35, Eric Masson a écrit :

> "F. Senault" <fred@lacave.net> writes:
>
> 'Lut Fred,
>
>> Uf. Là, je peux pas beaucoup plus aider. Il est vrai que j'essaie de
>> me tenir un maximum au loin de l'USB sous BSD, le support en étant
>> plutôt cataclysmique. :|
>
> Bah, ça peut fonctionner
>
> Le seul truc qui m'a posé problème récemment, c'est le support usb de
> nut pour un mge ellipse qui a réussi à générer deux/trois panic, je vais
> attendre la 6.2 pour retester.

Finalement, j'ai une Windows XP pour ça... :|

> Bon, de toutes façons, la pile usb de HP Selasky devrait être introduite
> en -current sous peu, l'actuelle étant toujours sous Giant.

Was ist ?

Fred
--
I was never faithful And I was never one to trust Borderlining schizo
And guaranteed to cause a fuss I was never loyal
Except to my own pleasure zone I'm forever black-eyed
A product of a broken home (Placebo, Black-Eyed)