> > Si je voulais passer d'Eclipse à Wireshark (qui avec une grosse capture chargée), par exemple, ça prenait des dizaines de secondes.
> Avec 512 Mo sous windows et bien plus d'apps gourmandes j'ai rarement atteint de pareils records..
Cf.
./478: c'est pas complètement aberrant que la lecture + l'écriture de dizaines de MB de données non contiguës sur un disque lent prenne jusqu'à quelques dizaines de secondes.
Donc je doute que tes applis aient été aussi gourmandes
Il y a des patches type "swap prefetch" pour Linux, mais ils n'auraient pas aidé dans mon cas, la RAM étant pleine.
Un patch de load/store spéculatif du contenu de la RAM n'aurait probablement pas aidé non plus en moyenne, vu que les algos spéculatifs augmentent la pénalité s'ils se trompent parce que l'utilisateur fait autre chose que ce qu'ils avaient anticipé.
> et je pense que ça fait longtemps qu'on a dépassé la concurrence propriétaire.
A peu près personne de sérieux ne peut soutenir que Windows est mieux fait que Linux (et les *nix d'une façon générale) du point de vue technique: gestion de la mémoire, gestion des processus (création et switch plus rapides sur *nix), allocateur de blocs sur le disque (celui de Windows pour NTFS est mauvais et fragmente certains fichiers qu'il serait possible de ne pas fragmenter), etc.
Même s'il y a toujours des progrès à faire dans Linux (et ailleurs), citons:
* la gestion du disque. C'est carrément mieux que Windows, mais moins bien qu'OpenSolaris si on utilise ZFS...
* un DTrace ou similaire qui marche. Systemtap, ça fait des mois que je lis la mailing list, et DTrace, plutôt moins ambitieux il est vrai, était fonctionnel ET fiable quand il avait le même "âge" que Systemtap a maintenant;
* un debugger kernel dans mainline:
_____* sa présence par défaut sur OpenSolaris m'a permis d'obtenir un backtrace complet, et diverses autres infos, lors d'un kernel panic tôt dans le boot sur ma machine de boulot;
_____* sur le P4 que j'ai chargé comme une bourrique (voir
./478), plusieurs kernels récents (notamment ceux de SimplyMEPIS 7, Mint 4.0) font kernel panic très tôt dans le boot. Je n'ai qu'un backtrace incomplet car il ne rentre pas sur l'écran. F8 ne boote pas complètement non plus. Je fais comment pour tenter de faire remonter des infos sur ce qui se passe (à part prendre le source intégral du kernel, le patcher, le compiler intégralement avec les mêmes options de compilation que l'original, et faire un remaster de l'ISO de la distro, ce qui est une procédure lourde) ?
)
