et même si c'était le cas, que veux tu faire de spécifique par rapport à ça dans ton algorithme ?
Rien de spécial du coup, en ayant pris un peu de recul. J'étais étonné du fait que dans la version par blocs buggée, si on mettait comme taille de bloc la moitié environ du cache L1 c'est là qu'on obtenait les meilleures vitesses. D'où mon interrogation.
Mais étant donné que la version était buggée et que tout ce qu'elle faisait c'était copier toujours les même size_block octets d'un même pointeur source à un même pointeur destination, peu étonnant qu'on obtienne les meilleures perfs quand on peut copier toutes les données d'un côté à l'autre en restant dans le cache...
Cette deuxième question venait essentiellement de divers résultats sur le troisième test, copie "par blocs". Comme elle est complètement bugguée, (merci Samuel Thibault aka youpi), cette deuxième question n'est plus très pertinent.
Je voulais dire qu'il existe une taille optimale pour que le cache L1 soit utilisé au mieux : schématiquement, le processeur mettra de toutes façons beaucoup moins de temps à faire la copie (surtout avec les SSE) qu'à charger les données depuis la mémoire et à les y renvoyer, du coup il y a un compromis à effectuer entre données à charger dans le cache en attente d'y être copiée et taille du cache dédiée à la destination.
En fait le processeur doit gérer ça de lui même de toutes façons (c'est aussi son boulot de gérer le cache). Mais pas forcément très bien, voir par exemple http://software.intel.com/en-us/articles/copying-accelerated(...) . Pour laisser plus de place aux données en provenance ils suggèrent d'utiliser les instructions de "streaming" (opérations mémoire non temporelles) qui court-circuitent le cache (notamment pour ce qui est de l'écriture, pour laisser plus de place à ce qui arrive). C'est bénéfique dans le cas de mbw car les données copiées ne sont pas immédiatement réutilisées.
j'avoue que ces erreurs triviales (inversion des tests) m'étaient complètement passées à côté /o\
Tout est pour le mieux donc, l'ordre des choses est respecté. Je vais quand même regarder ce que donne gcc-4.4 en optimisant un peut les boucles avec le framework graphite.
Mais ça pourrait peut-être intéresser plus de monde en journal si la réponse n'est pas trop triviale. Ok fallait réfléchir avant de poster mais je ne pensais pas être si long.
Qu'en pensez-vous ?
J'avais eu ce message d'erreur en compilant un gcc dont certains fichiers objets (.o) avaient été compilés pour une autre architecture dans le même répertoire. Il vaut mieux reprendre à chaque fois à l'étape de configuration en commençant d'un répertoire vide.
C'est peut-être pour ça qu'on peut difficilement se connecter aux pages perso Free depuis la Chine ! On accuse le grand pare-feu des dragons verts, mais...
Même genre de commentaire au sujet du fit-pc (version slim).
Je recommanderais toutefois de bien mettre le disque en mode économie d'énergie pour éviter la surchauffe, sans l'autoriser à s'éteindre toutefois :
hdparm -B 128
Ça le fait passer de 43°C à 37°C en moyenne, je n'ai pas cherché à le refroidir plus (par exemple le mettre verticalement, ne pas le laisser tourner sur de hautes étagères où l'air est plus chaud qu'au sol, etc). Pas de surchauffe.
La bête n'est pas très rapide sous debian (par exemple pour les mises à jour), m'enfin c'est pas la mort non plus. Elle fait tourner des services java lourds en entrées/sorties disques sans difficulté (sur disque chiffré, avec essiv logiciel et chiffrement matériel du Geode, voir mon journal https://linuxfr.org/~khivapia/27342.html sur le sujet). Le plus gênant c'est quand on fait des transferts ssh sur le réseau local, où le chiffrement disque + ssh fait plafonner le débit à ±3Mo/s (environ 70% du CPU pour ssh, 30% pour kcryptd).
Je recommanderais (sans l'avoir jamais fait /o\ parce que sans écran, faites ce que je dit pas ce que je fais, toussa) une gentoo pour améliorer un peu les perfs (voir quelques tests dans le journal cité ci-dessus, avec le flag -march=geode. On gagne quand même 20 à 40% de perf ! Je peux refaire d'autres tests sur demande).
Sinon il y a le fit-pc 2 avec un processeur Atom qui consomme plus et qui est doté du fameux chipset poulsbo qui n'a pas de pilote libre sous Linux (ni de pilote correct pour du tout sauf pour la Ubuntu 8.04 ou 8.10).
Pour Flash il y a aussi une méthode bourrine qui consiste à effacer ~/.macromedia après chaque utilisation, ou bien à en changer les permissions pour interdire l'écriture.
Après il est effectivement détestable que comme le dit kikicnrv de plus en plus d'objets flash ne servent plus à afficher quoi que ce soit...
De même que l'Europe impose petit à petit à toute l'industrie mondiale de produire sans incorporer nombre de produits dangereux (directive REACH), par le simple fait qu'elle représente plus ou moins 30% du marché mondial soit la masse critique suffisante pour que les industries ne puissent pas s'en couper ni maintenir une production spécifique à l'Europe, de même les logiciels, mêmes libres, ne peuvent pas se couper d'une utilisation aux USA sans risquer sévèrement de stagner. Sans compter que nombre d'entreprises spécialisées dans les "services web" sont aux États-Unis (voir par exemple http://www.pcinpact.com/actu/news/55172-quelles-nations-quel(...) )
Donc oui les brevets logiciels ne sont pas valables en Europe, mais non, même en tant qu'européen on doit absolument en tenir compte.
ça risque de compliquer le travail de ceux qui voudraient la déplomber si elle est aussi verrouillée que l'iphone.
En revanche, si les specs restent fermées, il y a de bonnes chances pour qu'on ne voie pas ce processeur ailleurs.
... mais l'emploi des guillemets et des termes et le ton général de l'annonce (sur linuxfr) rendent pour moi la discrimination hors de propos. Quant à la subjectivité, j'ignorais que c'était un élément interdit dans les annonces (de toutes façons l'entretien derrière fait que cette dernière a une place déterminante dans le processus de recrutement).
Bon ben un fork pourrait être une bonne idée... On verrait si Google joue le jeu du libre !
En synchronisant avec les développements google et en ajoutant juste ce qu'il faut pour le support de theora.
Je n'ai pas forcément les compétences pour lancer le truc mais si quelqu'un fait je veux bien participer au mieux de mes compétences.
Il ne s'agit pas de les faire en même temps, mais de commencer la deuxième sitôt les 10 premières secondes (par exemple) du film passées dans la première : la deuxième peut profiter des statistiques de la première au fur et à mesure qu'elles sont produites.
Une sorte de pipeline en fait : le résultat de la première passe est fournie au fur et à mesure de la deuxième.
En tout cas c'est ce que faisaient certains outils Apple quand ils sont passés aux processeurs Intel double cœur.
Sinon c'est pas encore un gros problème avec un processeur double cœur : l'encodage se faisant en deux passes, on peut lancer la première sur un cœur et la deuxième juste après sur le cœur d'à côté.
KMail va pouvoir faire des recherches dans les pièces jointes ou les messages chiffrés
Dans les pièces jointes, c'est génial, mais par contre dans les messages chiffrés, c'est un peu étrange : l'information sera stockée dans une base de données en clair ? espérons que non vu l'existence du portefeuille chiffré de KDE, mais si l'on ne fait pas attention, retrouver des mots-clefs de messages chiffrés est une fuite d'information non négligeable.
Certes les mails chiffrés sont surtout faits pour se protéger des écoutes sur la ligne, mais c'est également pratique de conserver les messages importants directement chiffrés sur le disque sans s'ennuyer à les stocker dans un espace dédié/avec tout le reste. Ça permet d'appliquer une politique de sécurité spécifique pour les mails par exemple.
Sans rire, franchement ce journal donne envie d'essayer. Les fonctions d'intégration des différentes applications les unes aux autres sont vraiment un plus par rapport aux autres systèmes d'exploitation/etc : pour un utilisateur débutant traditionnellement sous windows/firefox/thunderbird (par exemple), la recherche et l'indexation de tout, documents à mails, via nepomuk me paraissent être un plus indéniable, une fois un effort de formation réalisé.
Après c'est sûr que le journal est peut-être un peu technique, mais on comprend bien de quoi ça parle : en un mot, "les recherches dans kmail 2 vont déchirer" et comme c'est toujours là où pèchent les bons gestionnaires de mails...
[^] # Re: Copier "par bloc" ?
Posté par khivapia . En réponse au message Performances de memcpy ???. Évalué à 4.
Rien de spécial du coup, en ayant pris un peu de recul. J'étais étonné du fait que dans la version par blocs buggée, si on mettait comme taille de bloc la moitié environ du cache L1 c'est là qu'on obtenait les meilleures vitesses. D'où mon interrogation.
Mais étant donné que la version était buggée et que tout ce qu'elle faisait c'était copier toujours les même size_block octets d'un même pointeur source à un même pointeur destination, peu étonnant qu'on obtienne les meilleures perfs quand on peut copier toutes les données d'un côté à l'autre en restant dans le cache...
[^] # Re: Copier "par bloc" ?
Posté par khivapia . En réponse au message Performances de memcpy ???. Évalué à 2.
Je voulais dire qu'il existe une taille optimale pour que le cache L1 soit utilisé au mieux : schématiquement, le processeur mettra de toutes façons beaucoup moins de temps à faire la copie (surtout avec les SSE) qu'à charger les données depuis la mémoire et à les y renvoyer, du coup il y a un compromis à effectuer entre données à charger dans le cache en attente d'y être copiée et taille du cache dédiée à la destination.
En fait le processeur doit gérer ça de lui même de toutes façons (c'est aussi son boulot de gérer le cache). Mais pas forcément très bien, voir par exemple http://software.intel.com/en-us/articles/copying-accelerated(...) . Pour laisser plus de place aux données en provenance ils suggèrent d'utiliser les instructions de "streaming" (opérations mémoire non temporelles) qui court-circuitent le cache (notamment pour ce qui est de l'écriture, pour laisser plus de place à ce qui arrive). C'est bénéfique dans le cas de mbw car les données copiées ne sont pas immédiatement réutilisées.
# Merci pour toutes vos réponses...
Posté par khivapia . En réponse au message Performances de memcpy ???. Évalué à 2.
Tout est pour le mieux donc, l'ordre des choses est respecté. Je vais quand même regarder ce que donne gcc-4.4 en optimisant un peut les boucles avec le framework graphite.
khivapia
[^] # Re: Parce qu'il n'y a pas que Linux / i386 dans la vie...
Posté par khivapia . En réponse au message Performances de memcpy ???. Évalué à 2.
# C'est posté dans un forum...
Posté par khivapia . En réponse au message Performances de memcpy ???. Évalué à 6.
Qu'en pensez-vous ?
# Différentes architectures ?
Posté par khivapia . En réponse au message [LFS] Problème compilation de gcc chap. 5.5 (passe 1). Évalué à 2.
J'avais eu ce message d'erreur en compilant un gcc dont certains fichiers objets (.o) avaient été compilés pour une autre architecture dans le même répertoire. Il vaut mieux reprendre à chaque fois à l'étape de configuration en commençant d'un répertoire vide.
[^] # Re: une personne fera un compte-rendu
Posté par khivapia . En réponse au message Le TouchBook disponible, qqu'un a déjà essayé ?. Évalué à 2.
[^] # Re: une personne fera un compte-rendu
Posté par khivapia . En réponse au message Le TouchBook disponible, qqu'un a déjà essayé ?. Évalué à 2.
Merci
[^] # Re: tuez-le
Posté par khivapia . En réponse au journal Un web animé sans flash. Évalué à 2.
les cimetières...
Une des explications des "feux follets" serait l'inflammation des gaz issus de décomposition, dont le méthane. http://fr.wikipedia.org/wiki/Feu_follet
[^] # Re: problème chez Free, ou chez Algérie-Télécom/Anis ?
Posté par khivapia . En réponse au journal Free ! j'ai rien compris !. Évalué à 3.
------------> []
[^] # Re: fit-pc
Posté par khivapia . En réponse au message Linutop, Fit-PC ou autre ?. Évalué à 2.
[^] # Re: fit-pc
Posté par khivapia . En réponse au message Linutop, Fit-PC ou autre ?. Évalué à 4.
Je recommanderais toutefois de bien mettre le disque en mode économie d'énergie pour éviter la surchauffe, sans l'autoriser à s'éteindre toutefois :
hdparm -B 128
Ça le fait passer de 43°C à 37°C en moyenne, je n'ai pas cherché à le refroidir plus (par exemple le mettre verticalement, ne pas le laisser tourner sur de hautes étagères où l'air est plus chaud qu'au sol, etc). Pas de surchauffe.
La bête n'est pas très rapide sous debian (par exemple pour les mises à jour), m'enfin c'est pas la mort non plus. Elle fait tourner des services java lourds en entrées/sorties disques sans difficulté (sur disque chiffré, avec essiv logiciel et chiffrement matériel du Geode, voir mon journal https://linuxfr.org/~khivapia/27342.html sur le sujet). Le plus gênant c'est quand on fait des transferts ssh sur le réseau local, où le chiffrement disque + ssh fait plafonner le débit à ±3Mo/s (environ 70% du CPU pour ssh, 30% pour kcryptd).
Je recommanderais (sans l'avoir jamais fait /o\ parce que sans écran, faites ce que je dit pas ce que je fais, toussa) une gentoo pour améliorer un peu les perfs (voir quelques tests dans le journal cité ci-dessus, avec le flag -march=geode. On gagne quand même 20 à 40% de perf ! Je peux refaire d'autres tests sur demande).
Sinon il y a le fit-pc 2 avec un processeur Atom qui consomme plus et qui est doté du fameux chipset poulsbo qui n'a pas de pilote libre sous Linux (ni de pilote correct pour du tout sauf pour la Ubuntu 8.04 ou 8.10).
[^] # Re: IP Fixe
Posté par khivapia . En réponse au journal Vie privée sur internet : il n'y a pas que les cookies.... Évalué à 4.
[^] # Re: Et il n'y a pas que ça.
Posté par khivapia . En réponse au journal Vie privée sur internet : il n'y a pas que les cookies.... Évalué à 2.
Après il est effectivement détestable que comme le dit kikicnrv de plus en plus d'objets flash ne servent plus à afficher quoi que ce soit...
[^] # Re: Ici, OSEF
Posté par khivapia . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 10.
http://www.pcinpact.com/actu/news/55172-quelles-nations-quel(...) )
Donc oui les brevets logiciels ne sont pas valables en Europe, mais non, même en tant qu'européen on doit absolument en tenir compte.
[^] # Re: Personne?
Posté par khivapia . En réponse au journal En finir avec la lourdeur de KDE. Évalué à 10.
[^] # Re: C'est quand même une nouvelle archi cpu...
Posté par khivapia . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 2.
En revanche, si les specs restent fermées, il y a de bonnes chances pour qu'on ne voie pas ce processeur ailleurs.
[^] # Re: et sinon ?
Posté par khivapia . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 3.
# IANAL...
Posté par khivapia . En réponse au message Pôle-emploi et la HALDE. Évalué à 3.
[^] # Re: Theora et ogg dans Chromium
Posté par khivapia . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 3.
En synchronisant avec les développements google et en ajoutant juste ce qu'il faut pour le support de theora.
Je n'ai pas forcément les compétences pour lancer le truc mais si quelqu'un fait je veux bien participer au mieux de mes compétences.
[^] # Re: H264 et GIF
Posté par khivapia . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
Une sorte de pipeline en fait : le résultat de la première passe est fournie au fur et à mesure de la deuxième.
En tout cas c'est ce que faisaient certains outils Apple quand ils sont passés aux processeurs Intel double cœur.
[^] # Re: H264 et GIF
Posté par khivapia . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 2.
Sinon c'est pas encore un gros problème avec un processeur double cœur : l'encodage se faisant en deux passes, on peut lancer la première sur un cœur et la deuxième juste après sur le cœur d'à côté.
[^] # Re: Suppression des pages.
Posté par khivapia . En réponse au journal Les services de communications ont investi Wikipedia. Évalué à 3.
# Recherches dans les messages chiffrés ?
Posté par khivapia . En réponse au journal À venir dans KMail. Évalué à 6.
Dans les pièces jointes, c'est génial, mais par contre dans les messages chiffrés, c'est un peu étrange : l'information sera stockée dans une base de données en clair ? espérons que non vu l'existence du portefeuille chiffré de KDE, mais si l'on ne fait pas attention, retrouver des mots-clefs de messages chiffrés est une fuite d'information non négligeable.
Certes les mails chiffrés sont surtout faits pour se protéger des écoutes sur la ligne, mais c'est également pratique de conserver les messages importants directement chiffrés sur le disque sans s'ennuyer à les stocker dans un espace dédié/avec tout le reste. Ça permet d'appliquer une politique de sécurité spécifique pour les mails par exemple.
[^] # Re: Foutaises !
Posté par khivapia . En réponse au journal À venir dans KMail. Évalué à 2.
Sans rire, franchement ce journal donne envie d'essayer. Les fonctions d'intégration des différentes applications les unes aux autres sont vraiment un plus par rapport aux autres systèmes d'exploitation/etc : pour un utilisateur débutant traditionnellement sous windows/firefox/thunderbird (par exemple), la recherche et l'indexation de tout, documents à mails, via nepomuk me paraissent être un plus indéniable, une fois un effort de formation réalisé.
Après c'est sûr que le journal est peut-être un peu technique, mais on comprend bien de quoi ça parle : en un mot, "les recherches dans kmail 2 vont déchirer" et comme c'est toujours là où pèchent les bons gestionnaires de mails...