Tu plaisentes j'espère… Les accès disques physiques sont nul à chier, et ça même toi tu dois le savoir, en plus, il n'y a aucun cache, sous linux, tout accès disque est gardé en cache si la memoire est suffisante, et ensuite, tous les accès suivants sont fait par la couche vfs du noyau. Exemple simple, je me logue sous KDE, c'est lent… Je me délogue et je me relogue, ça va 10 fois polus vite, et je n'exagère pas sur le 10 ! Fais ça avec windows !
Comme exemple concret, j'ai mon boulot, TRÈS GROS (et c'est un euphémisme) logiciel multiplateforme avec plein plein plein de plugins, les accès disque sont plus lent, point à la ligne, je peux pas faire mieux que le dire, ou alors je peux vous vendre une licence si tu veux vérifier toi même.
Ensuite, regarde les temps de compilation pour un gros projet par exemple, et ce n'est pas que du à la lenteur excessive du compilo !
Et encore, fait une recherche dans les fichiers !! Pour rechercher dans les sources de mon projet, un outils codé en C qui utise des reg exp perl donne un résultat de l'ordre de 30 secondes sur tout le projet, sous windows, l'outil "optimisé" de vs 2010 qui ne recherche que dans les fichiers de la solution… Et bien je ne sais pas, personne n'a jamais tenté, mais pour un seul plugin (j'en ai 30 dans mon espace de travail, mais pour temperer, il n'y en a que quelques-uns de vraiment très gros, je dirait en taille, il fait 1/5 du total), il dépasse la minute !! La bonne blague !
Enfin, parlons-en de l'allocateur et de sa tendance à fragmenter… Tu dois savoir que windows x86 donne 2 Go de l'espace pour la partie utilisateur des process et 2 pour la partie noyau, et bien dans la pratique, on n'a JAMAIS réussi à dépasser les 1,5 Go… Et souvent à partir de 1,3 Go, ça commence à sérieusement être foireux pour les grosses alloc de plus de 100 Mo…
Sous linux, jamais un soucs d'allocation tant que je demande de la mémoire disponible !
Et c'est pas parce que ton allocateur s'appelle "L'Allocateur Qu'Il Est Trop Bien Pour Pas Fragmenter (tm) (r) (c) (trololil)" qu'il fragmente pas. À ce petit jeu, j'ai mangé des gateaux à l'huile de palme "raffiné" aujourd'hui…
[^] # Re: Oh les approximations pour prêcher sa paroisse
Posté par moi1392 . En réponse au journal Banc d’essai OpenGL/Direct3D de Source engine par Valve. Évalué à 9.
Tu plaisentes j'espère… Les accès disques physiques sont nul à chier, et ça même toi tu dois le savoir, en plus, il n'y a aucun cache, sous linux, tout accès disque est gardé en cache si la memoire est suffisante, et ensuite, tous les accès suivants sont fait par la couche vfs du noyau. Exemple simple, je me logue sous KDE, c'est lent… Je me délogue et je me relogue, ça va 10 fois polus vite, et je n'exagère pas sur le 10 ! Fais ça avec windows !
Comme exemple concret, j'ai mon boulot, TRÈS GROS (et c'est un euphémisme) logiciel multiplateforme avec plein plein plein de plugins, les accès disque sont plus lent, point à la ligne, je peux pas faire mieux que le dire, ou alors je peux vous vendre une licence si tu veux vérifier toi même.
Ensuite, regarde les temps de compilation pour un gros projet par exemple, et ce n'est pas que du à la lenteur excessive du compilo !
Et encore, fait une recherche dans les fichiers !! Pour rechercher dans les sources de mon projet, un outils codé en C qui utise des reg exp perl donne un résultat de l'ordre de 30 secondes sur tout le projet, sous windows, l'outil "optimisé" de vs 2010 qui ne recherche que dans les fichiers de la solution… Et bien je ne sais pas, personne n'a jamais tenté, mais pour un seul plugin (j'en ai 30 dans mon espace de travail, mais pour temperer, il n'y en a que quelques-uns de vraiment très gros, je dirait en taille, il fait 1/5 du total), il dépasse la minute !! La bonne blague !
Enfin, parlons-en de l'allocateur et de sa tendance à fragmenter… Tu dois savoir que windows x86 donne 2 Go de l'espace pour la partie utilisateur des process et 2 pour la partie noyau, et bien dans la pratique, on n'a JAMAIS réussi à dépasser les 1,5 Go… Et souvent à partir de 1,3 Go, ça commence à sérieusement être foireux pour les grosses alloc de plus de 100 Mo…
Sous linux, jamais un soucs d'allocation tant que je demande de la mémoire disponible !
Et c'est pas parce que ton allocateur s'appelle "L'Allocateur Qu'Il Est Trop Bien Pour Pas Fragmenter (tm) (r) (c) (trololil)" qu'il fragmente pas. À ce petit jeu, j'ai mangé des gateaux à l'huile de palme "raffiné" aujourd'hui…