informatique et high-tech (les meilleures news) %) - Page 6

squalyl (./148) :
je vois aussi le multicore pour les dévs en effet.

par contre je vois pas trop comment marche le "hyperthreading". Linux (et al) voit bien "2 CPU" mais c'est quoi la différence avec 2 cores?

2 core -> le scheduler peut leur attribuer 2 processus différents

2 threads -> le scheduler fait quoi? Il dispatche les threads d'un même processus? donc si tes applis sont pas multithreadées ça sert à que dalle

C'est exactement la même chose : tu peux dispatcher 8 processus sur les 8 cœurs logiques d'un Nehalem quadricœur. Seulement, c'est parfois plus lent vu qu'il n'y a qu'un peu plus de 4 cœurs (certaines unités sont dupliquées, mais pas toutes, le but étant de rentabiliser justement au maximum les différentes unités d'un seul cœur)

non mais en fait j'ai déja du mal à voir comment on fait booter un processeur/core secondaire, alors un coeur logique, j'te dis pas

Un processeur HT fait parfois certaines opérations d'un thread en parallèle avec certaines autres d'un autre thread, parce qu'elles n'utilisent pas exactement les mêmes parties du processeur.

Espérons qu'ils auront bien analysé et résolu le problème des P4 HT qui sont parfois plus *lents* que des P4 non-HT de même fréquence, sur certains workloads (par exemple certains workloads faisant participer beaucoup de threads).

Au niveau soft, le coeur logique se comporte exactement comme un coeur physique déjà
Ensuite, quand tu as un pipeline dans un processeur, tu te retrouves parfois bloqué à une instruction en cours d'exécution car tu as besoin du résultat d'une autre opération aussi dans le pipeline pour te servir d'opérande... Sans HT tu vas mettre des NOP, avec tu vas passer la main à l'autre coeur logique, qui va donc exploiter les "temps morts" d'exécution. Après il doit y avoir des mécanismes pour répartir la charge entre les deux (pour pas en avoir un qui fait toujours le programme principale et l'autre qui attend toujours pour boucher les trous) mais on s'en fiche
C'est donc plus ou moins efficace selon les programmes que tu exécutes, mais c'est beaucoup moins coûteux à mettre en place au niveau transistors qu'un coeur de plus, et presque gratuit en terme de puissance consommée. Et niveau perfs, ça peut doubler, au mieux, et être inutile, au pire

ok donc l'HT c'est un 2nd CPU qui bosse uniquement pendant que le premier glande en attendant ses opérandes ?

"grosso modo" oui, disons que c'est une méthode pour mieux rentabiliser les ressources du matériel en "simulant" un coeur de plus. Comme un OS multithreadé, mais appliqué au processeur.

Et niveau perfs, ça peut doubler, au mieux, et être inutile, au pire

En théorie, ça peut doubler. En pratique, ça dépasse rarement 30%, mais c'est déjà bien
Mais ça peut être nuisible, sur certains workloads particuliers.

./155: non non, c'est un unique CPU, qui a "juste" quelques modifs.

oué, pigé, mais bon c'est le même effet

il a deux jeux de registres je suppose, au moins deux PC nan?

Ben oui, sinon ça serait pas transparent du tout ^^

Ximoon (./154) :
Et niveau perfs, ça peut doubler, au mieux, et être inutile, au pire

Même si c'était vrai j'imagine que ça peut avoir un impact très négatif sur la latence, non ? (Nil ?)

http://www.pcinpact.com/actu/news/44018-filtrage-internet-neutralite-FAI-operateurs.htm

ça passera jamais, c'est pas possible

Si si, c'est possible, malheureusement...

Martial Demolins (./162) :
Comme ça doit être imbitable à coder en assembleur ce genre de processeurs

Il ne faut pas coder en assembleur sur des x86 modernes, t'as toutes les chances de te rater Mais coder avec ou sans HT doit revenir au même, puisque tu ne sais pas quel autre thread sera en cours d'exécution en parallèle... Même s'il est sûrement possible de trouver des combinaisons qui permettent d'optimiser le threading avec des "slots de temps" judicieusement placés

./162> et oui, comme quoi ne jurer que par l'asm...
(cross)

Martial Demolins (./162) :
Comme ça doit être imbitable à coder en assembleur !

Fix'd

L'assembleur x86 n'est pas si dur que ça. Le problème, c'est plutôt que si tu codes comme sur 68k, ton code risquera d'être moins rapide que ce que pond GCC parce qu'il y a plein d'effets à prendre en considération sur une machine moderne, GCC a un modèle assez complexe du processeur pour ça. En revanche, tu as toujours des chances de t'en sortir pour une optimisation en taille pure en ignorant complètement la vitesse. Mais bon, si ton code fait 210 octets et met 2 fois plus longtemps que le code de 220 octets de GCC, sur une RAM de 4 GO, ça ne va pas être très intéressant.

Kevin Kofler (./166) :
Mais bon, si ton code fait 210 octets et met 2 fois plus longtemps que le code de 220 octets de GCC, sur une RAM de 4 GO, ça ne va pas être très intéressant.

Kevin, c'est bien toi ?

non c'est un clone je te rassure

Aujourd'hui, il a également dit qu'il était d'accord avec moi et il a parlé de Kubuntu. Quelqu'un lui a volé son compte

normal dans kubuntu y'a KDE

http://www.gizmodo.fr/2008/06/08/la_carte_sd_sans_fil_eyefi_sert_aussi_a_confondre_les_voleurs_idiots.html
chopés par une carte eye fi

http://www.gizmodo.fr/2008/06/07/un_radiateur_geant_pour_refroidir_les_ardeurs_des_processeurs.html
ça c'est pas un ventirad de pédé

(là où gizmondo s'est (un peu, disons que ça n'est pas dit clairement) foiré, c'est qu'il ne s'agit pas d'un simple radiateur, mais de l'un des éléments d'un boitier presque passif)

Des boîtiers fanless existent déjà, mais sont souvent hors de prix Il y a jenesaisplusquellemarque qui a sorti une tour de base fanless ruineuse il y a quelques temps, sinon, plus abordable en mini-itx :

http://www.maisondunumerique.com/prod-1705-Configuration-Mini-ITX-fanless.html

http://www.maisondunumerique.com/prod-2024-Config.-HFX-Mini-Metal.html

etc...

bientot (atom toussa)

plus abordable

Les nouveaux UMPC, comme l'eeePC 901 sont sans ventilo, sans disque dur. Rien de fragile et rien de bruyant

sans autonomie aussi

Plus de 4h il me semble, pour le 901. L'autonomie est justement très bonne car il n'y a ni ventilateur ni disque dur à faire tourner.