université, et effectivement en amphi c'est horrible

Ca me rappelle, à la fac, notre prof de Système nous avait fait de la lecture commentée d'un bout du noyau Linux, avec de vrais morceaux d'ASM dedans.
Tout ça en amphi; sté chouette

Il utilisait Emacs

Pour ton premier jour à EDF ?

Akala niam niam

klolthxbye

 
b_l y connait pas Naheulbeuk

il connait mais il a pas dit qu'il aimait qu'on s'exprime de façon débile

 
il connait mais il a pas dit qu'il aimait qu'on s'exprime de façon débile

 
il connait mais il a pas dit qu'il aimait qu'on s'exprime de façon débile

Mais qui ?!

Mais qui ?!

'tain les cravates ca devrait être interdit dès que la température dépasse 22°C

Non le castor

'tain les cravates ca devrait être interdit dès que la température dépasse 22°C

Mais qui ?!

snorkies

hey, mais c'est ma réplique à moi ça  

 
maintenant qu'openldap est dans le basesys netbsd il va pouvoir s'éclater

 
Ah ouais, mais c'est Manu.
 
A l'occasion, je lui transmettrais
 
 
 
On a été plus d'un à dire non. Le code d'openldap, il est plutot dégueux  

 
Dans le contexte de la mondialisation actuelle, l'employé du privé est jetable à tout moment.  Face aux États-Unis qui licencie à tour de bras, le Japon est un modèle à suivre car le Japon ne licencie pas.  L'économie du Japon est donc foutrement plus forte qu'aux USA    
 

Y'a t'il un interêt à utiliser une archi/version 64bits tant qu'elle n'est pas totalement supporté
 
XaT

Bonjour
 
 
 
Depuis le temps qu'elle existe, ca serait peut être bien qu'elle le soit. Surtout que ca va faire pas mal de temps que cette architecture est accessible au grand public, mais merci aux éditeurs de logiciels de merde^W^W^W^W^Wproprios pour leur magnifique travail dans son support.

Je trouve ça dommage
 
Comme la gestion multicore
 
Mode expert ?
 
XaT

 
C'est pas vraiment propre au BKL. Les systèmes qui n'ont pas été étudiés pour du parallèlisme ont toujours un overhead sur du SMP, ne serait-ce qu'à cause des migrations/changement de contexte entre CPU (ou même des threads, pour du CMT).
 
Il y a aussi quelque chose de très pénalisant dans le SMP, c'est la synchronisation des caches (les trucs qu'un vendeur carrouf vante en disant 2Mo de cache L2, c'est encore plus rapide, pour quelqu'un qui connait un peu ca peut faire un très joli débat à manants dans le rayon ) et les invalidations du TLB (le buffer qui traduit des adresses virtuelles en physiques.
 
L'exemple typique, c'est le processeur P0 qui écrit en mémoire, mais n'y accède pas directement (l'écriture se faisant dans L1). Le processeur P1 attend le résultat justement, et le cache n'est pas flushé. Il faut donc marquer la page mémoire comme "sale" (dirty), et flusher le cache.
 
Chaque constructeur à sa manière de voir les choses. AMD/Intel considère que ca doit être caché du monde soft, c'est à dire que tout doit être fait dans le circuit. C'est pour cette raison que l'archi x86 est "lourde", mais "tolérante" à des conneries de programmations (accès pas alignés, pas de controle software des miss TLB, etc.). A l'inverse, fujitsu/sun considère que c'est le soft de faire ca proprement, du coup l'architecture est plus simple, mais faut gérer. Les programmes codés comme les pieds qui fonctionnent sous x86 mais finissent en SIGBUS sous sparc sont légions.
 
Maintenant, comparons: actuellement, les CMT de Sun, un bête T2000, c'est 32 threads, 8 core sur un processeur. Là ou sous x86, pour en mettre 4, c'est déjà très chaud de le faire sans bug
 

 
En activité serveurs, les "sérieux", oui (a la louche, dans mes derniers developpement: xen et postgresql sont de bons exemples).
 
Pour les logiciels de madame michu, ca n'a pas tellement d'importance, ses activités quotidiennes ne le justifient pas, sauf (à la rigueur) si elle fait de la vidéo (mais ca, les frameworks n'ont pas attendu le multi core pour le faire), et le temps réel, qui demande au noyau d'être préemptible (ce qu'un BKL, sémaphore ou pas, ne permet pas de faire proprement).

 
oui, j'en ai eu aussi (à la fac).
 
Sinon pour ce que tu as dit plus haut j'avais lu un papier qui comparait les perfs pour une utilisation en temps que routeur en mono et multicoeur des procs. Intel prenait très cher par rapport à AMD (genre 2 fois moins de PPS). Dès qu'on passait en multicoeur, c'était la boucherie, la synchro des caches et autres était moisie.

 
 
Le multi-core, ça ne m'impressionne plus vraiment,  

Ca me rappelle, à la fac, notre prof de Système nous avait fait de la lecture commentée d'un bout du noyau Linux, avec de vrais morceaux d'ASM dedans.
Tout ça en amphi; sté chouette

 
Méga troll ? Debian en x64, c'est supporté depuis longtemps et ca buggue pas. Sans rappeler que debian a toujours été compilé sur de multiples archi 64 bien avant nos x86-64. De toute façon le 64 c'est "ubiquitous" maintenant, et seuls les fans de techno ultra stable continueront à utiliser du 32 par sécurité et simplicité. Mais ca disparait progressivement des ordis standard ce qui n'est pas forcément bien. Exemple, mon portable intel core duo, acheté 600 euros, c'est ma meilleure machine, jamais vu plus rapide avec aussi peu de latence.
 

apparemment les devs de LDAP se prennent trop pour des leets du coup quand un contributeur externe leur apporte un bon patch en leur disant que "leur truc c'est bien mais surtout çà çà et çà c'est pas bien" ca les émerve un peu    

J'étais deg de ne pas aller au déjeuner avec lui, je sais pas si j'aurais encore l'occase    
Passe le bonjour à Antonio aussi

Intéresant. J'ai discuté avec des collègues sur l'efficacité du multicore et sur des archis intel/AMD ca scale très mal, surtout intel à cause des problèmes d'échange de données entre cores. Et donc des proces comme le Q9300 c'est lol (faiblesse du cache)

 
Au niveau des logiciels ? Au niveau de autre chose que Debian ?
 
XaT

Bonjour les gens
J'ai des chances de tenir le stand netbsd avec lui aux RMLL (suivant ce que mon employeur permettra au pauvre stagiaire que je suis), donc si ca dit à des gens d'ici de passer dire bonjour

Au niveau des logiciels ? Au niveau de autre chose que Debian ?
 
XaT