matiasf a écrit 1969 commentaires

> c'est la "ligne de cache", c'est 32 octets sur les x86

Et même 64 bits sur athlon xp.

> tes préoccupations relatives au langage C

C'est pas mes préoccupations. Relis.

> perdent tout sens dès qu'un cache entre en jeu.

C'est aussi ce que je dis. Relis.

Le site a été mise à jour :
http://www.microbsd.net/(...)

> http://www.ubix.org/(...)

Voir la news :
http://www.ubix.org/cgi-bin/rhum?action=planche&forum=1&thr(...)

avec un "formidable" :-) :
- "Le projet est closed-source, et l'équipe de développement est volontairement réduite afin de rester efficace et productif. (il semblerait en effet que dans les "grands" projets open-source les querelles entre développeurs sont inévitables et nuisent à l'ambiance de l'équipe, comme on a pu encore le voir récemment dans la communauté BSD)"

le SE au nom "bizarre" pour les francophones de Sequel :
http://www.xentronix.com/node.php?id=246(...)

> limite le support des anciennes distrib a une periode si petite....

C'est le support de la RedHat Linux qui a été ramené à 1 an (suivi par Mdk). La RH SA a au minimum 3 ans de support.

Pour moi il est claire qu'il y a deux RedHat. La RedHat SA non dispo en download en binaire/iso et la RedHat Linux (la classique, la "vieille").

Avec la RedHat Linux, ils font avancer le LL sans faire de pognon. D'ailleur il disent (sur la home page http://www.redhat.com/(...) ) que c'est la distribe de la "communauté". Avec la RH SA l'objectif c'est les entreprises et faire du pognon. Ce qui est primordial c'est qu'il continuent la RedHat Linux (je rappèle que up2date reste gratuit pour gérer une machine) et qu'avec le pognon récupéré avec la RH SA ils fassent du LL ou la promotion du LL.

Si le fichier est en cours d'utilisation (utiliser /usr/sbin/lsof pour confirmer), ça ne marche car il y a deux descripteurs de fichier ouverts sur le même fichier. C'est le dernier qui ferme le fichier qui défini la taille.
Exemple :
$ free -s 1 > toto &
[1] 17839
[ attendons un peu]
$ > toto
$ cat /dev/null > toto ; ll toto ; sleep 2 ; ll toto
-rw-r--r-- 1 f.matias users 0 fév 24 02:38 toto
-rw-r--r-- 1 f.matias users 72996 fév 24 02:38 toto

La première taille à 0 de toto c'est car le jobs %1 n'a pas encore écrit depuis la fermeture du fichier par "> toto".
C'est même une caratéristique appréciée d'unix. Imaginons le "drame" si le process qui écrit en continu fait un seek ! Ça nous priverait aussi de la possibilité d'écriture pas plusieurs process dans un fichier.

Cette caractéristique, n'est pas lié au shell mais au noyau.

marche pas, ça crée un fichier avec un caractère ('\n').
il faut :
echo -n > fichier

Non, touch change la date de dernière modification du fichier alors qu'il ne modifie pas le fichier (s'il existe).
Si tu fait >> fichier, ça ne change pas le fichier, donc ni la date de dernière modification.

> Pour info, Red Hat n'est globalement toujours pas rentable

Avec le succès de la RH SA (de 1000 à 3300 € en fonction du support !) qui a l'appuis d'IBM, DELL, HP etc..., l'arrivé d'une RH SA autour de 500 € (je ne retrouve plus l'annonce) et une version station de travail sur le même modèle (prévus pour mars), je crois que ça se passe bien...

Par contre, pour la partie embarqué, c'est moins claire.

> Oui, c'est un cas où on est obligé d'avoir des adresses absolues. Mais à l'intérieur de ton programme, ou de ta bibliothèque de fonctions, tu peux n'avoir que du relatif.

Pas dis le contraire.

> en particulier aucun risque de doublement de taille.

C'est claire.
Mais pour répondre vaguement à la question :
du -s
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS/(...)
1166250

du -s
ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/ia64/RedHat/RPMS/(...)
1194397

Mais la version ia64 a presque 90 paquets de moins !

Je n'ai pas dit que l'on ne peut pas utiliser un adressage relatif. Je dis que l'adressage relatif ne peut pas être utilisé lorsqu'un programme appel une fonction ou un variable dans une librairie partagée, ou une librairie partagée vers une librairie partagée (et surement d'autres combinaisons). Je ne dis pas qu'un programme qui utilise une librairie partagée ne peut pas utiliser les adressages relatif ! Je dis aussi que les adresses d'un objet (j'ai pris l'exemple d'une fonction static mais c'est aussi vrai pour une variable) externe qui est stocké dans une variable est forcément l'adresse absolue. C'est principalement dans le contexte d'une fonction (if, while, etc...) que les adresses relatives sont utilisées, que le programme soit statique ou dynamique !

> qu'on utilise des adressages relatifs en 16 ou 32 bits, et qu'on ne puisse pas utiliser de librairie.

Car le compilateur ne sait pas à la compilation où va être chargée la librairie partagée (d'où l'édition de lien à l'exécution pour les librairies partagée). Et donc, il ne peut supposer que la fonction appelée (ou la variable) est à une distance tenant dans un mot inférieur à sizeof(void *) (sous un système 32 bits, sizeof(void *) = 32 et pour un système 64 bits, sizeof(void *) = 64). Donc l'appel de la fonction (ou de la variable) est codé en utilisant une adresse absolue sur 64 bits (si c'est un OS 64 bits). Notes que je n'est pas dit que c'était impossible pour une librairie static (d'édition de lien étant faite à la compilation). Je ne parle que de l'utilisation d'un objet dans une autre librairie partagée !

> Sur Amiga tu pouvais bien avoir des programmes qui n'utilisaient que des sauts relatifs, alors que l'OS était 32 bits.

Sous DOS aussi c'est possible (fichier .com comme je l'ai dit précédament). Car il n'y a pas d'utilisation de librairie partagée.

> Tu te poses de drôles de questions.

C'est pas moi qui ait posé la question (relis le thread).

> Ta question "d'optimiser le cache" n'a même pas de sens à mon avis.

J'ai répondu à une question et dis que l'on ne pouvait optimiser le cache comme c'était proposé. Et je n'ai fait aucune proposition d'optimisation de cache (relis le thread).

> Et dans le cas d'un cache, la granularité du cache est bien supérieure à la taille d'un mot mémoire.

Merci de le confirmer.

Hum hum :
http://www.microsoft.com/windowsserver2003/64bit/default.mspx(...)

Voire plus bas.

Par endroit, ils ont fait un bête sed -e "s/OpenBSD/MicroBSD/g". Or l'auteur, c'est OpenBSD et non MicroBSD.

> le nForce est un chipset de type north gate

Ooops. J'ai pris ça pour la "nouvelle GForce"... des divagations.

> 2) un traitement 64Bits sur un processeur 32Bit prendra toujours 2 fois plus de cycle que sur un processeur 64Bits, que ce soit bien supporté ou pas.

Pour un cpu avec des registres de 32 bits ok. Si tu as des registres de 64 bits c'est différent. Un IA-32 moderne qui bosse sur des 'double float' n'est pas plus lent qu'un cpu dit 64 bits (sinon il y aurait pléthore de bench le montrant). D'ailleur un athlon a un bus de 64 bits et quelques registres de 64 bits.

Je ne dis pas que tu as tord mais je trouve que ce n'est pas évident.

> la réponse est non

Heuuu... C'est quoi la question ?

> mais tu te trompes pour l'adressage relatif qui ne serait pas utilisable entre fonctions.

Pour tout les appels de fonction de librarie partagé, le relatif ne peut pas marché.

> Quoique finalement ça ne devrait pas être très difficile de faire un compilateur qui serait capable de suivre les offset des pointeurs de fonction...

Faut ajouter beaucoup de code pour ça => perte de place. C'est comme les gens qui veulent économiser de l'espace en utilisant des champs bits. Faut tellement de code, que généralement ça bouffe plus de place que d'utiliser un int pour stocker un booleen. Et c'est aussi plus lent.

> Par contre, n'importe quel appel de fonction "normal" marche très bien avec des offset relatifs, c'est ce qu'il se passe quand tu génères du code "PIC"

En fait, lorsque la librairie partagée est chargée, le loader change toute les adresses relatives en absolu (depuis la table des symbols). Car ce sont des adresses relatives (donc de 64 bits sur un OS 64 bits) et non des offsets. Les librairies partagées sont faites en considérant qu'elle commence à l'adresse 0 (la résolution d'adresse sera faite à l'excécution). Il est claire que si plusieurs librairie sont utilisées, ça ne peut pas marché. Le loader va modifier les adresses relatives pour en faire des adresses absolus.

> Je te rappelle qu'un programme peut être compilé avec uniquement des offsets relatifs sur 32 bits.

Et sous ms-dos et windows il y a quelques années on pouvais faire du 16 bits en relatif aussi (les fichier .com :-) ).

Si ton programme n'utilise que du relative 32 bits sur un os 64 bits (par exemple) alors tu ne peux pas utiliser de librairie (comme expliqué plus haut). Dans ce cas, je vois pas où il est le gain de place.

> Originaux tes exemples, j'ai l'impression que tu n'as jamais vu d'assembleur et les modes d'adressage d'un CPU.

Tu n'as pas compris le problème. On parlait de cache. La question était de savoir s'il était possible d'économiser le cache en ne copiant que les octets "significatifs". J'ai répondu que non en prenant comme exemple un int de 8 octets. Il est évident que pratiquement tout les cpu savent récupérér 1, 2, 4 ... octets (le z80 le fesait). Quoiqu'il en soit (puisse que l'on parle de cache ! ) je me demande si le cache a ce niveau de "finesse".

> En fait les cartes nForce sont déjà en 128Bits On ne parle pas de la même chose ici. une nForce dite 128Bits, c'est la taille du mot du cpu. Mais pas les capacités d'adressage. En 32 bits il y a déjà 4 Go! C'est beaucoup pour une carte graphique. Donc 128Bits d'adressage c'est totalement inutil. Pour un OS, on parle de capacité d'adressage en général. D'ailleur on peut avoir un OS 64 bits avec un int à 32 bits (C'est le cas avec Alpha, OSF1 et DEC UNIX 3 et 4 (pas testé true64)). C'est-à-dire que l'adressage à 64 bits et que la taille naturel d'un mot est de 32 bits. > mais il y a bien gain de Bande passante mémoire. C'est à cause du bus de donnée. Les bus de données des PIII, athlon etc... sont déjà en 64 bits. Le bus de donnée est indépendant de l'adressage et de la taille d'un mot. Le passage de 32 à 64 bits de l'adressage des cpu ne va pas améliorer sa bande passage. Car on peut avoir un bus de donnée de 8 bits avec un bus d'adressage de 64 bits et un mot (le int) à 64 bits. C'est le bus de données qui compte pour la bande passante. Enfin, avoir un mot (le int) à 32 bits (et même un os et un adressage de 32 bits) ne veut pas dire que le cpu ne peut pas traiter efficacement du 64 bits. D'ailleur sous GNU/Linux i86 avec gcc on a des entiers de 64 bits (long long) et des flottants de 96 bits (long double) mais toujours les pointeurs à 32 bits. Le gros intéret d'os Linux 64 bits, c'est l'adressage mémoire. Quelqu'un qui possède un itanium (ia64) peut nous dire quelle est la taille d'un int sous Linux. Je ne serait pas étonnée qu'elle soit toujours de 32 bits.

Il n'y aura pas une appli qui tourne parfois en 32 bits et parfois en 64 bits. C'est soit tout l'un ou tout l'autre pour des raisons évidente d'édition de lien. On ne peut pas faire l'édition de lien d'un .o avec sizeof(void *) = 4 et d'un autre avec sizeof(void *) = 8. Image "titi = toto ;" avec titi (void *) d'un .o 32 bits et toto (void *) d'un .o 64 bits. Notes que ça implique d'avoir une libc 32 bits et une 64 bits pour faire tournée des programmes 32 bits ou 64 bits. > et de ne transfere que les bits significatifs ! Ça ne change rien. imagenons en 0x1000 qu'il y a : 0x 00 00 00 00 00 00 00 01 Le cache pour s'avoir qu'il y a cette valeur doit allé lire les 8 octets. Il ne peut pas préssuposer qu'il y a 7 octets à 0. Si le bus fait 8 octets, c'est aussi rapide de lire 1 octet que 8 (du moins s'ils sont alignés, sinon il faut au plus deux opérations de lecture). Enfin, dans un programme toute les valeurs possibles d'un short int, int, long, etc peuvent être utilisées. Donc ça ne laisse pas la possibilité au cache de faire une convention du type : 0x 07 01 => 7 octets à 0 puis 7 car 0x 07 01 c'est aussi un short int ou 2 caractères. A moins que le cache ajoute un octet pour indiquer le type. Or le cache n'est pas sencé connaitre le type des données qu'il lit. C'est comme les caches des disques dure. Ils ne savent pas le type de données lues/écrites.

Pour clarifier. Je pense qu'une appli développé avec winelib sous GNU/Linux peut tourner aussi vite voir plus vite que sous Windows. Dans ce cas on a que du elf et on ne passe pas par plusieurs couches. C'est par exemple le cas de wordperfect : http://linux.corel.com/products/wpo2000_linux/index.htm Par contre une appli qui n'est pas compilée sous GNU/Linux, comme word, je ne suis pas convaincu. Danc ce cas, il faut utilise wine qui fait l'édition de lien, appel de dll, appel de librairie .so (qui peut être libwine). Il y a une couche suplémentaire. Par contre un programme compilé sous Windows qui ne fait pas d'appel système (un programme de calcul uniquement) tournera aussi vite sous Windows que sous wine. Quand j'utilisait word avec wine (il y a longtemps...) j'ai toujours eu l'impression qu'il tournait significativement moins vite que sous Windows. Mais c'était il y a long ! Ça a peut-être changé.

> tu peut meme ateindre 103% a 108% sur des machines optimisees ( tout recompile depuis les sources ... enfin pour ce qui est recompilable C''est une utilisation différente de wine. Dans ce cas, il n'y a pas émulation de windows mais utilisation d'une librairie "classique" Linux compatible avec l'API windows. Pas d'utilisation des DLL windows. Dans ce cas, c'est effectivement rapide.

> C'est dire si les PC un peu plus costauds vont vite se casser les dents sur la limite d'adressage, avant cette date. C'est probable. Ça (sans 'à', merci pour l'info car j'ai déjà fait mille fois cette faute) explique aussi le positionnement de Intel. Beaucoup seront "forcé" de passé à 64 bits autour de 2008 s'il ne sont pas déjà passés en 64 bits. > les architectures CISC à la Intel permettent d'utiliser plusieurs modes d'adressage, en particulier relatifs Comme pratiquement tout les cpu il me semble. L'adressage relative étant utilisé dans les fonctions pour les sauts (if, while, etc...) mais pas entre fonction. Une fonction peut-être appelé n'importe où. Il faut aussi pensé aux pointeurs de fonction qui peut-être utilisé. Donc même l'adresse d'une fonction static doit être codé sur 64 bits. Exemple (j'ai surement fait des erreurs de typage car j'ai oublié comment déclarer des pointeurs de fonction...): toto.c void*(void) titi(void) { return toto ; } static void toto(void) { print("toto\n") ; } main.c main() { void* (*func)(void) ; func = titi() ; func() ; // affiche "toto" }

Ooops. Désolé.

Tu as déjà utilisé wine ? > car les soket emules de wine sont mins lourds que leur implementation originale de Microsoft dans windows C'est vrai que c'est très utile pour Word...

Si MS les laisse tomber, il peuvent mettre de la pub pour IBM, ORACLE, SUN, Mandrake ... Je sais que la presse est dépendante de la pub. Mais le cas "le monde" n'est pas dramatique apparament. Il y a d'autres presses qui sont déjà perdues. La presse féminine par exemple qui n'est qu'un intrument de propagande des vendeurs de produits de beauté, amincissant, etc... La presse spécialisé informatique est dans un état 100 fois pire que "le monde".

http://www.microsoft.com/presspass/press/2003/Feb03/02-21RMSForWindowsServerPR.asp Using Windows Rights Management Services, applications such as information portals, word processors or e-mail clients can be built so that users will be able to easily designate both who can have access to specific content and what kinds of access rights they can have. Rights and policy are managed by the server, while clients running RMS-enabled applications allow users to apply rights with a click of a button. For example, Windows Rights Management Services can be used to control forwarding, copying and printing, as well as establishing time-based expiration rules. In addition, enterprises can enforce policy broadly and reliably by centrally delivering templates that automate the process — for example, making the policy around what constitutes "company confidential" uniform and easy to manage.