PS: Pour en revenir à ta question, il me semble trivialement que si tu cherches à implémenter un langage, tu auras les mêmes problèmes (inhérents à ce langage) à résoudre quel que soit la technique utilisée. Mais j'avoue avoir mal compris le cheminement de votre discussion.
Merci pour ces contributions intéressantes. Je vais essayer de mettre mon grain de sel en espérant être à propos ;-)
Comment fais-tu avec des variants et l'approche initiale si tu veux rajouter des int et l'opération d'addition add au langage jouet avec les booléens ?
Dans le cas de metaOCaml, le language est OCaml, donc tu as déjà tout ce qu'il te faut (modulo les limitations de MO). Ce que tu peux faire avec ton approche, pour être comparable en termes de performance, c'est d'utiliser ton "observateur" pour générer du code ocaml que tu vas compiler au run-time et ensuite charger dynamiquement. Si j'ai bien compris, c'est grosso-modo le comportement de MO, avec la grosse différence que la vérification de typage sera postposée au run-time avec les problèmes qui en découlent, là où MO tente de valider la génération de code de tous les stages à la première compilation, au stage 0.
est-ce que ces os sont plutôt dans une logique de recherche plutôt que de production comme haiku ou plan9 ?
Non.
En faisant l'impasse sur le côté historique (rappelons que BSD fut développé dans une université), ces systèmes entretiennent néanmoins des relations privilégiées avec le milieu académique. Ils servent de terreau fertile à la recherche "pure", et cela peut découler en des avancées technologique directement utilisables dont capsicum (que vous avez justement mentionné) est un parfait exemple.
Par rapport à la question originale, il me semble que vouloir opposer une "logique de recherche" à une logique de production n'est pas nécessairement très pertinent dans toute industrie (qui par définition est technologique), et certainement pas dans le cas de l'informatique. (Btw haiku a plus à voir avec le côté hobbie-iste que celui de la recherche et le problème de plan9 était AMHA que UNIX avait déjà trop bien réussi, pas qu'il soit issu d'un département de R&D ou qu'il ne soit pas apte à être utilisé en "production").
Hein ? Tu as la doc de soft A qui dit "veuillez donner ce privilège à cette application pour assurer son fonctionnement correct", tu as le soft B qui dit la même chose, tu fais quoi maintenant ? Variante : tu fais comment pour faire tourner deux instances du soft A ?
Ok merci de m'avoir corrigé ! Alors c'est effectivement du au vm.overcommit_memory = 0 mentioné par gouttegd (i.e. une "grosse" allocation est rejettée).
Si on remplace le code par le suivant qui au lieu d'allouer 32 G en un coup alloue 32 fois 1G, il n'y a pas d'erreur. De même si on met le overcommit_memory à 1.
c'est juste très difficile à faire car on doit être certain que le path d'erreur ne fera pas d'allocation
Précision: plus qu'être certain de ne pas faire d'allocation, il ne faut pas accéder à de la mémoire non précédemment accédée.
Python initialise la mémoire au moment de l'allocation (calloc()/memset) pour faire un fail-early, mais il ne règle pas le problème du path d'erreur. Est-il simplement possible d'écrire du code en ayant la certitude qu'il n'y ai pas d'allocations implicites ou "cachées" ?
Donc python met un handler sur sigsegv et lance une MemoryError. Il ne dit pas qu'il y a une pénurie de mémoire, ça pourrait être un bug dans le runtime ou dans une bilbiothèque. C'est comme ça qu'on peut faire en C aussi hein (vu que malloc ne retourne pas NULL sous linux, bis repetita), c'est juste très difficile à faire car on doit être certain que le path d'erreur ne fera pas d'allocation et, qui plus est, on ne sait pas à quel endroit le programme se trouve au moment où ça pète. (je me demance ce qui se passerait en python si tu faisais une alloc dans ton bloque catch…)
Tu as juste prouvé que python ou numpy retourne une erreur, pas linux ni la libc (malloc). Si tu prennais la peine de lancer ton programme avec strace ou ltrace tu ne trouverais rien.
S'il peut déterminer la quantité de mémoire nécessaire pour tout son conteneur, il doit forcément déterminer la quantité de mémoire nécessaire à son programme (ainsi qu'à tout les autres programmes du conteneur)…
Deuxiemement admettons qu'il n'en soit pas capable, ça ne change rien au comportement de malloc.
=> Cette discussion est bel et bien dans une double voie sans issue et je ne peux que remercier tous ces lecteurs perspicaces qui ont masqué cette discussion perdue car trop "exploratoire". ;-)
D'ailleurs contrairement à un sigsegv l'application ne sait rien faire, elle ne peut pas l'intercepter pour libérer de la mémoire. Je crois qu'Android à une solution particulière à ce problème, quelqu'un pour confirmer ? Il y aussi une idée d'implémenter des allocation faibles qui pourront être libérée automatiquement par le kernel (p.e. pour faire un cache applicatif), mais ça ne change rien au problème qu'une fois toutes ces weak-allocations libérée, on se retrouve dans le même cas de figure.
malloc (en fait l'appel système brk) ne renvois jamais null
Il y a peut-ête le cas des limites dépassées (ulimit, cgroup), limites fixées par avance. Du coup ça sort du cardre de la discussion (ben oui, si on connaît d'avance la mémoire nécessaire, on n'a qu'à faire une allocation statique au début du programme…)
Sous Linux, si tu chopes un segfault en accédant a un NULL malloc sous Linux, tu as soit :
Tu peux nous la refaire ? C'est un peu dur à parser car tu parles de deux choses différentes à la fois: le comportement de malloc et du segfault.
IIMNM, sous linux:
malloc (en fait l'appel système brk) ne renvois jamais null, sauf si l'espace d'adresses est épuisé. malloc renvois bien null lorsque size=0 et probablement d'autres situations exceptionnelles mais il faut aller lire le code pour savoir. En pratique on peut considérer qu'il ne renvoit jamais null.
on se chope un segfault en déférençant null, sauf si on y a mappé quelque chose de manière explicite (je pense pas que l'allocateur de la glib s'amuse à faire ça dans notre dos, enfin peut-être avec les options de debug ?).
on se chope un OOM mais ça n'a aucune relation temporelle avec un malloc ou brk.Ça arrive au moment ou linux essaye d'honnorer une page-fault, soit après un dérérencement d'une adresse non encore accédée ou lors d'un swapout. Et la victime est limite tirée au sort. On dit que linux fait de l'overcommit: on peut allouer une quantité plus importante que l'espace de mémoire virtuelle (soit RAM+SWAP), il y a un problème uniquement lorsque la mémoire est utilisée… Ça j'ai entendu que windows ne le fait pas, ce qui peut être un avantage (pas de OOM…).
Bref, dans tous les cas, c'est super important de le savoir.
Care to elaborate? savoir quoi btw ? J'ai l'impression que sous linux on est foutu, on ne sait tout simplement rien faire du tout pour récupérer une situation de pénurie. Ce qui est un argument pour ceux qui ne veulent pas s'embêter avec ça… "c'est impossible à gérer alors à quoi bon s'embêter?" Un fois qu'on est au niveau zéro de la gestion, il n'est pas trop compliqué de porter sur un autre OS vu que le comportement attendu est "quelque chose plante" :P Tu peux carrément remplacer ton code par while (malloc()==NULL) processTerminate (GetRandomPid()) pour être vraiment au niveau de linux ;-)
Posté par benja .
En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1.
Évalué à 3.
Dernière modification le 26 octobre 2016 à 23:44.
Pour OpenBSD -current : vmm/vmd
Actuellement ça ne supporte pas un autre OS qu'OpenBSD, ce qui limite un peu son utilité.
Pour DragonFly BSD RELEASE : ?
Il n'y a pas non plus de virtualisateur de machine accéléré. Par contre il y a le choix entre un VKERNEL (~~ UML) et les jails.
[LVM / ZFS]
LVM est là car quelqu'un à décidé de le porter, c'est plus un "accident" qu'une décision de design de l'OS. En ce qui concerne les capacités raid de HAMMER1/2, ça n'a pas l'air d'être une priorité ni de faire partie du design. Il y a moyen d'étendre un volume sur plusieurs périphériques, mais (corrigez moi si je me trompe) il n'y a pas de mécanisme de protection*, de redondance ou de réparation (donc à éviter je dirais) ou alors il faut s'appuyer sur une solution en dehors de HAMMER de type LVM ou matérielle. L'idée est de s'appuyer sur les mirroirs+snapshots sur un FS différent pour s'occuper de la partie redondance. Certes, ça rend difficile la création de système de fichiers très larges et c'est peut-être plus compliqué à administrer, mais dans la majorité des cas ça ne devrait pas être un obstacle (AMHA).
*: de protection répartie j'entends. Il y a un CRC data/metadata (manque juste un outil pour le scrub… en attendant tar fait l'affaire)
Vous recommandez d'accepter d'avoir des crash à n'importe quel moment et de gérer correctement la remonté des erreurs seulement pour certaines allocations. Si je comprends bien votre solution permet de garder les problèmes des deux approches ?
Après aussi, tout dépend du programme aussi. Si c'est un petit programme de test / prototype ou un produit industriel dans un domaine critique, cela peut imposer le style de fait à tout le programme.
Étant donné que le journal pose la question, je suppose qu'il cherche une solution… De plus l'objet d'un prototype peut être, aussi, de valider la gestion des erreurs.
Posté par benja .
En réponse au message Problème avec KMS.
Évalué à 1.
Dernière modification le 26 octobre 2016 à 01:17.
Si tu te restreins aux pilotes libres et que tu veux jouer sur ton linux, il n'y a clairement pas photo entre amd, nvidia et intel, c'est du amd et puis c'est tout :)
Mais j'ai bien compris, concernant mon int8_t, que sur une architecture 32 bits il va y avoir du zéro filling pour rester aligner sur 32 bits
Quand je parle d'alignement et de conception électronique, je parle au niveau des transfert vers ou depuis la mémoire centrale depuis ou vers le cpu. C'est à dire tout les instruction dont une des opérante est une adresse va faire en sorte que le cpu lise ou écrive depuis la mémoire centrale.
PS: Tu parle souvent d'architecture 32 bits mais je pense que de nos jours c'est le 64 bits qui domine, faudrait peut-être faire une petite mise a jours concernant la nouvelle architecture 64 bits, pour mettre a jour ton grand savoir.
4.1.1 Alignment of Words, Doublewords, Quadwords, and Double Quadwords
Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. The natural
boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by
four, and addresses evenly divisible by eight, respectively. However, to improve the performance of programs, data
structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is
that the processor requires two memory accesses to make an unaligned memory access; aligned accesses require
only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand
that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access.
note: word = 16bit, double = 32, quad = 64. On peut lire que l'alignement minimum d'un cpu 32 ou 64 bit est 16 bit en utilisant les instructions travaillant avec des opérantes de 16 bits uniquement!!! Il n'est mentionné nul part quel est l'alignement naturel des opérations qui travaillent sur un byte, genre MOVZB. On peut raisonablement penser dire que l'alignement minimum des archi Intel 32 et 64 bit est de 2 octets. Mais bon, peut-être qu'effectivement il n'y a jamais de problème d'alignement en utilisant les instruction avec une "memory operand" de 8 bits. Ensuite le manuel écrit textuellement que pour un accès non aligné le cpu doit réaliser deux accès alignés, ce que j'ai tenté de vous expliquer au moyen d'une illustration.
Par ailleurs il se peut que le compilateur s'arrange pour faire un alignement optimal tout seul. Quand vous utilisez un tableau int8[], ben il ne peut pas ajouter du padding entre chaque élément et vous êtes à peu près sûr que 1 octets sur 2 ne sera pas aligné sur 16 bit, 3/4 sur 32 et 7/8 sur 64. Dans le cas d'une structure il est très facile de "désaligner" certains membres en intercallant des membres plus petits. Une recherche sur "C structure packing alignment" vous donnera des résultats très pertinents à ce sujet. Quant à moi je m'arrête ici dans l'espoir de ne pas vous perturber d'avantage. Je voulais simplement vous donner une réponse à votre question "est-ce qu'utiliser des int8 rend mon code plus rapide", celle-ci est "non sauf si vous avez de grosses contraintes mémoire (et que vous ne faites pas de padding!!!) ou que ces int8 n'entrainent pas un désalignement d'autres variables/membres". Je vous concède que j'aurais peut-être mieux fait de m'abstenir d'entrer dans de telles considérations de micro-optimisation car il est évident que même si utiliser un int8 serait légèrement plus rapide (ce dont je doute très sincèrement mais bon je n'arrive pas à trouver la preuve alors admettons*), vous n'aller rien gagner du tout compte tenu de la complexités des bibliothèques et systèmes graphiques que vous utilisés.
PS1: J'accepte vos excuses mais tâchez quand même d'être moins abrasif envers ceux qui veulent vous faire avancer. Btw je suis aussi un autodidacte, je ne prétend pas avoir la science infuse et je me trompe naturellement assez régulièrement. Je ne vous dois rien si ce n'est le respect. Je vous souhaite donc de persévérer, et dites vous bien que ce qui ne fait pas de sens aujourd'hui en fera sûrement demain.
*: Sur ce document il est montré sur un ensemble de processeurs différents qu'un mov de 32 bit n'est pas plus rapide qu'un de 64 bit, c'est identique voire dans certains cas plus lent…: https://gmplib.org/~tege/x86-timing.pdf
Est-ce-que le compilateur passe par du code assembleur pour produire du code machine ?
Oui. L'assembleur va simplement transformer un fichier d'assembleur en un fichiers objet. Les instruction (mnemoniques) sont transformées en valeurs (opcodes) directement utilisable par le cpu. Donc ce que tu vois dans ton fichier .s correspond à un objdump -D sur ton fichier .o. À une exception près que certaines mnémoniques sont des mneoniques qui codent en fait une séquence d'autre mnémoniques, un peu comme si c'était des macros.
(C'est ensuite l'éditeur de liens (le linker) qui lors de l'assemblage des différents fichiers objet va substituer certaines valeur d'adresse par le valeur absolue (en simplifiant). C'est cette étape qui permet à ton code de faire un "jmp label_fonction". Tu peux appeller sans problème une fonction "extern" depuis du code assembleur)
Donc je voit mal des valeurs valeurs stocker dans plusieurs registres se chevauchant…???
Je parlais de l'alignement en mémoire des tes variable.
Si tu as:
Le mot B4B3B2B1 est à cheval sur les "mots mémoire" 0-1-2-3 et 4-5-6-7. Pour le charge dans un registre R1, tu vas d'abord le charger dans R2 le mot 0-3, R2 vaudra --B4B3B2. ensuite tu fais un shit pour avoir R2=B4B3B200, ensuite tu charge/shift 4-7 dans R1=B1------, R1=000000B1 et tu combine R1=R1 AND R2 = B4B3B2B1. Tout cela parce qu'un cpu 32 bit est éléctriquement conçu pour travailler sur des mots aligné sur 4 octes. Admettons que B3 soit un int8 que tu veuille mettre dans un registre, il vaut lire 0-3, et faire p.e. 2 shift, un à droite puis un à gauche (sur une archi petit boutant). Sur x86 c'est transparent, le cpu va le faire pour toi automatiquement, mais c'est plus lent donc vaut mieux travailler avec des variables alignées.
j'en ai strictement marre qu'on me contredise a chaque fois que j'ai une idée.
Ne te méprends pas là n'est pas mon objectif qui est de te donner de nouvelles notions et de répondre à ta demande de feedback. Comme je t'ai dis ce n'est pas une mauvaise idée en soit car il est vrai que tu économises de la mémoire en ce faisant.
Si tu en le courage ont peut reprendre le truc (int8_t vs int) et (unsigned vs signed) en mettant l'accent sur la différence entre le compilateur qui produit du code machine et le processeur qui va exécuter le code machine.
Je t'invite à faire l'expérience que je t'ai suggéré et en plus de faire un objdump -D sur les fichiers .o pour constater que tu auras strictement 2 fois la même chose. Tu peux encore utiliser le debugger gdb pour là partie "éxécution" mais tu ne verras rien de nouveau que tu n'aurais pas déjà vu dans le désassemblage par objdump.
Le complément à deux est simplement la représentation binaire d'un entier négatif. Le truc c'est qu'en utilisant cette représentation une addition n'a pas besoin de tester le signe des opérantes. Au niveau du cpu, cela ne change strictement rien, il n'y pas de test supplémentaire, d'ailleurs comment ferait-il pour faire la différence entre une valeur signée d'une non signée ?? Pour le prouver il suffit de créer un fichier signed.c qui contient la fonction "int monadd(int a, int b) { return a+b;}", tu fais de même avec unsigned.c "unsigned int monadd(unsigned a, unsigned b) {return a+b;}", tu compiles avec gcc -save-temps -c unsigned.c, tu regarde le fichier assembleur .s et tu verras qu'il n'y a aucune différence. Comme je l'ai dit, ce qu'il peut y avoir comme différence serait du à une décision de l'optimisateur de gcc qui pourrait supprimer du code. Donc bref, tu mets unsigned si c'est effectivement le domaine de ta variable, c'est très bien mais ça ne changera strictement rien en ce qui concerne la rapidité d'exécution.
Par contre il ne faut jamais assigner un unsigned vers un signed ou inversément. Le language C admet cela en tant que cast implicite, si tu as de la chance ton compilateur t'arvertira, ou pas… Parce ça peut avoir de fâcheuses conséquences et est une source de problèmes de sécurité à cause des overflows et des optimisations. Malheureusement c'est un peu plus compliqué à expliquer de manière succinte.
Pour en revenir au int8 vs int. Si tu utilises des int8s sans padding (ce que tu sembles vouloir faire car pour pouvoir économiser de la mémoire), tu vas imposer de facto des lectures non-alignées car l'adresse de ta variable ne tombera pas toujours sur un multiple de 4 octets. Certaines archi imposent d'utiliser une instruction différente ou une série d'instructions pour cela. Grossièrement, elles vont lire la lecture du mot à l'adresse alignée inférieure et faire un shift de bit pour avoir ton octet dans la partie lsb. Encore pire, si tu lis un int32 non aligné (c.-à-d. à cheval sur deux int32 alignés), elle va devoir lire le mot d'en dessous, faire un shit, celui du dessus, faire un shift et enfin combiner les deux moitiées. x86 est "non-alignée" (excepté les instructions style mmx,sse,etc.), ce qui fait que la même instruction marche avec les deux types d'adresse, néanmoins elle reste moins performante avec des adresses non-alignées car la même partie de passe-passe va être faite par le cpu, dans ton dos.
Ceci dit, ça n'est pas pour cela que c'est une mauvaise idée ou que cela sera toujours moins performant. En effet, la mémoire sauvegardée peut servir à autre chose; par exemple dans un environement restreint type console de jeux, ça peut-être un bon calcul.
[^] # Re: Tagless final un chemin vers MetaOCaml en bibliothèque ?
Posté par benja . En réponse au journal Découvrir MetaOCaml dans son navigateur. Évalué à 1.
PS: Pour en revenir à ta question, il me semble trivialement que si tu cherches à implémenter un langage, tu auras les mêmes problèmes (inhérents à ce langage) à résoudre quel que soit la technique utilisée. Mais j'avoue avoir mal compris le cheminement de votre discussion.
[^] # Re: Tagless final un chemin vers MetaOCaml en bibliothèque ?
Posté par benja . En réponse au journal Découvrir MetaOCaml dans son navigateur. Évalué à 1. Dernière modification le 14 novembre 2016 à 14:02.
Merci pour ces contributions intéressantes. Je vais essayer de mettre mon grain de sel en espérant être à propos ;-)
Dans le cas de metaOCaml, le language est OCaml, donc tu as déjà tout ce qu'il te faut (modulo les limitations de MO). Ce que tu peux faire avec ton approche, pour être comparable en termes de performance, c'est d'utiliser ton "observateur" pour générer du code ocaml que tu vas compiler au run-time et ensuite charger dynamiquement. Si j'ai bien compris, c'est grosso-modo le comportement de MO, avec la grosse différence que la vérification de typage sera postposée au run-time avec les problèmes qui en découlent, là où MO tente de valider la génération de code de tous les stages à la première compilation, au stage 0.
[^] # Re: Cas d'utilisation ?
Posté par benja . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 6.
En faisant l'impasse sur le côté historique (rappelons que BSD fut développé dans une université), ces systèmes entretiennent néanmoins des relations privilégiées avec le milieu académique. Ils servent de terreau fertile à la recherche "pure", et cela peut découler en des avancées technologique directement utilisables dont capsicum (que vous avez justement mentionné) est un parfait exemple.
Par rapport à la question originale, il me semble que vouloir opposer une "logique de recherche" à une logique de production n'est pas nécessairement très pertinent dans toute industrie (qui par définition est technologique), et certainement pas dans le cas de l'informatique. (Btw haiku a plus à voir avec le côté hobbie-iste que celui de la recherche et le problème de plan9 était AMHA que UNIX avait déjà trop bien réussi, pas qu'il soit issu d'un département de R&D ou qu'il ne soit pas apte à être utilisé en "production").
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0. Dernière modification le 27 octobre 2016 à 21:17.
Hein ? Tu as la doc de soft A qui dit "veuillez donner ce privilège à cette application pour assurer son fonctionnement correct", tu as le soft B qui dit la même chose, tu fais quoi maintenant ? Variante : tu fais comment pour faire tourner deux instances du soft A ?
[^] # Re: gestion des supports USB (clef)
Posté par benja . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 3.
C'est un programme chrooté, n'est-ce pas ?
[^] # Re: Langages modernes
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 3. Dernière modification le 27 octobre 2016 à 15:01.
Ok merci de m'avoir corrigé ! Alors c'est effectivement du au vm.overcommit_memory = 0 mentioné par gouttegd (i.e. une "grosse" allocation est rejettée).
Si on remplace le code par le suivant qui au lieu d'allouer 32 G en un coup alloue 32 fois 1G, il n'y a pas d'erreur. De même si on met le overcommit_memory à 1.
Donc "pratiquement", on n'a pas d'erreur sous linux…
(Aussi content de savoir que numpy ne fait pas de memset par défaut, c'eût été un peu idiot).
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.
Ah cool je ne savais pas. Effectivement ça a l'air d'être ça, documenté dans vm.txt, sysctl vm.overcommit_memory.
[^] # Re: Approche hybride
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 2.
Précision: plus qu'être certain de ne pas faire d'allocation, il ne faut pas accéder à de la mémoire non précédemment accédée.
Python initialise la mémoire au moment de l'allocation (calloc()/memset) pour faire un fail-early, mais il ne règle pas le problème du path d'erreur. Est-il simplement possible d'écrire du code en ayant la certitude qu'il n'y ai pas d'allocations implicites ou "cachées" ?
[^] # Re: Approche hybride
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0. Dernière modification le 27 octobre 2016 à 13:03.
Donc python met un handler sur sigsegv et lance une MemoryError. Il ne dit pas qu'il y a une pénurie de mémoire, ça pourrait être un bug dans le runtime ou dans une bilbiothèque. C'est comme ça qu'on peut faire en C aussi hein (vu que malloc ne retourne pas NULL sous linux, bis repetita), c'est juste très difficile à faire car on doit être certain que le path d'erreur ne fera pas d'allocation et, qui plus est, on ne sait pas à quel endroit le programme se trouve au moment où ça pète. (je me demance ce qui se passerait en python si tu faisais une alloc dans ton bloque catch…)
[^] # Re: Langages modernes
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0. Dernière modification le 27 octobre 2016 à 12:49.
Tu as juste prouvé que python ou numpy retourne une erreur, pas linux ni la libc (malloc). Si tu prennais la peine de lancer ton programme avec strace ou ltrace tu ne trouverais rien.
Je te le fais en ocaml si tu veux :
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.
OK merci c'est plus clair.
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0.
Dans ce cas tous les autres logiciels vont faire pareil.
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0.
=> Cette discussion est bel et bien dans une double voie sans issue et je ne peux que remercier tous ces lecteurs perspicaces qui ont masqué cette discussion perdue car trop "exploratoire". ;-)
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0. Dernière modification le 27 octobre 2016 à 03:01.
En fait non cf. message de Cheuteumi juste au dessus … :-/
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.
D'ailleurs contrairement à un sigsegv l'application ne sait rien faire, elle ne peut pas l'intercepter pour libérer de la mémoire. Je crois qu'Android à une solution particulière à ce problème, quelqu'un pour confirmer ? Il y aussi une idée d'implémenter des allocation faibles qui pourront être libérée automatiquement par le kernel (p.e. pour faire un cache applicatif), mais ça ne change rien au problème qu'une fois toutes ces weak-allocations libérée, on se retrouve dans le même cas de figure.
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 1.
Il y a peut-ête le cas des limites dépassées (ulimit, cgroup), limites fixées par avance. Du coup ça sort du cardre de la discussion (ben oui, si on connaît d'avance la mémoire nécessaire, on n'a qu'à faire une allocation statique au début du programme…)
[^] # Re: Approche hybride
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 5.
Pas possible vu qu'il n'y a plus d'allocation possible sur tout le système.
[^] # Re: Langages modernes
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à -2.
Non ça n'est en pratique pas possible sous linux, désolé. Cf. commentaires plus haut.
[^] # Re: undefined behaviour
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à 0. Dernière modification le 27 octobre 2016 à 02:43.
Tu peux nous la refaire ? C'est un peu dur à parser car tu parles de deux choses différentes à la fois: le comportement de malloc et du segfault.
IIMNM, sous linux:
malloc (en fait l'appel système brk) ne renvois jamais null, sauf si l'espace d'adresses est épuisé. malloc renvois bien null lorsque size=0 et probablement d'autres situations exceptionnelles mais il faut aller lire le code pour savoir. En pratique on peut considérer qu'il ne renvoit jamais null.
on se chope un segfault en déférençant null, sauf si on y a mappé quelque chose de manière explicite (je pense pas que l'allocateur de la glib s'amuse à faire ça dans notre dos, enfin peut-être avec les options de debug ?).
on se chope un OOM mais ça n'a aucune relation temporelle avec un malloc ou brk.Ça arrive au moment ou linux essaye d'honnorer une page-fault, soit après un dérérencement d'une adresse non encore accédée ou lors d'un swapout. Et la victime est limite tirée au sort. On dit que linux fait de l'overcommit: on peut allouer une quantité plus importante que l'espace de mémoire virtuelle (soit RAM+SWAP), il y a un problème uniquement lorsque la mémoire est utilisée… Ça j'ai entendu que windows ne le fait pas, ce qui peut être un avantage (pas de OOM…).
Care to elaborate? savoir quoi btw ? J'ai l'impression que sous linux on est foutu, on ne sait tout simplement rien faire du tout pour récupérer une situation de pénurie. Ce qui est un argument pour ceux qui ne veulent pas s'embêter avec ça… "c'est impossible à gérer alors à quoi bon s'embêter?" Un fois qu'on est au niveau zéro de la gestion, il n'est pas trop compliqué de porter sur un autre OS vu que le comportement attendu est "quelque chose plante" :P Tu peux carrément remplacer ton code par
while (malloc()==NULL) processTerminate (GetRandomPid())pour être vraiment au niveau de linux ;-)[^] # Re: gestion des supports USB (clef)
Posté par benja . En réponse à la dépêche DragonFly BSD 4.6 et 4.6.1. Évalué à 3. Dernière modification le 26 octobre 2016 à 23:44.
Actuellement ça ne supporte pas un autre OS qu'OpenBSD, ce qui limite un peu son utilité.
Il n'y a pas non plus de virtualisateur de machine accéléré. Par contre il y a le choix entre un VKERNEL (~~ UML) et les jails.
LVM est là car quelqu'un à décidé de le porter, c'est plus un "accident" qu'une décision de design de l'OS. En ce qui concerne les capacités raid de HAMMER1/2, ça n'a pas l'air d'être une priorité ni de faire partie du design. Il y a moyen d'étendre un volume sur plusieurs périphériques, mais (corrigez moi si je me trompe) il n'y a pas de mécanisme de protection*, de redondance ou de réparation (donc à éviter je dirais) ou alors il faut s'appuyer sur une solution en dehors de HAMMER de type LVM ou matérielle. L'idée est de s'appuyer sur les mirroirs+snapshots sur un FS différent pour s'occuper de la partie redondance. Certes, ça rend difficile la création de système de fichiers très larges et c'est peut-être plus compliqué à administrer, mais dans la majorité des cas ça ne devrait pas être un obstacle (AMHA).
*: de protection répartie j'entends. Il y a un CRC data/metadata (manque juste un outil pour le scrub… en attendant tar fait l'affaire)
[^] # Re: Mélange des deux
Posté par benja . En réponse au journal Gestion des erreurs d’allocation mémoire en C. Évalué à -1.
Vous recommandez d'accepter d'avoir des crash à n'importe quel moment et de gérer correctement la remonté des erreurs seulement pour certaines allocations. Si je comprends bien votre solution permet de garder les problèmes des deux approches ?
Étant donné que le journal pose la question, je suppose qu'il cherche une solution… De plus l'objet d'un prototype peut être, aussi, de valider la gestion des erreurs.
[^] # Re: nvidia, **** ***!
Posté par benja . En réponse au message Problème avec KMS. Évalué à 1. Dernière modification le 26 octobre 2016 à 01:17.
Si tu te restreins aux pilotes libres et que tu veux jouer sur ton linux, il n'y a clairement pas photo entre amd, nvidia et intel, c'est du amd et puis c'est tout :)
[^] # Re: C++ type et performances
Posté par benja . En réponse au message pre-realease de battle-rage un jeu de combat a la street fighter.. Évalué à 2. Dernière modification le 26 octobre 2016 à 01:10.
Quand je parle d'alignement et de conception électronique, je parle au niveau des transfert vers ou depuis la mémoire centrale depuis ou vers le cpu. C'est à dire tout les instruction dont une des opérante est une adresse va faire en sorte que le cpu lise ou écrive depuis la mémoire centrale.
L'archi 64 bit étant rétro-compatible avec la 32, cela ne change rien, à taille d'opérante ou instruction identique! De plus vous comprendrez qu'il m'a bien fallut trouver un exemple et que je n'ai pas la prétention de vous faire un exposé exhaustif. Je vous renvois donc vers la section du manuel d'intel pour plus de précisions http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
note: word = 16bit, double = 32, quad = 64. On peut lire que l'alignement minimum d'un cpu 32 ou 64 bit est 16 bit en utilisant les instructions travaillant avec des opérantes de 16 bits uniquement!!! Il n'est mentionné nul part quel est l'alignement naturel des opérations qui travaillent sur un byte, genre MOVZB. On peut raisonablement penser dire que l'alignement minimum des archi Intel 32 et 64 bit est de 2 octets. Mais bon, peut-être qu'effectivement il n'y a jamais de problème d'alignement en utilisant les instruction avec une "memory operand" de 8 bits. Ensuite le manuel écrit textuellement que pour un accès non aligné le cpu doit réaliser deux accès alignés, ce que j'ai tenté de vous expliquer au moyen d'une illustration.
Par ailleurs il se peut que le compilateur s'arrange pour faire un alignement optimal tout seul. Quand vous utilisez un tableau int8[], ben il ne peut pas ajouter du padding entre chaque élément et vous êtes à peu près sûr que 1 octets sur 2 ne sera pas aligné sur 16 bit, 3/4 sur 32 et 7/8 sur 64. Dans le cas d'une structure il est très facile de "désaligner" certains membres en intercallant des membres plus petits. Une recherche sur "C structure packing alignment" vous donnera des résultats très pertinents à ce sujet. Quant à moi je m'arrête ici dans l'espoir de ne pas vous perturber d'avantage. Je voulais simplement vous donner une réponse à votre question "est-ce qu'utiliser des int8 rend mon code plus rapide", celle-ci est "non sauf si vous avez de grosses contraintes mémoire (et que vous ne faites pas de padding!!!) ou que ces int8 n'entrainent pas un désalignement d'autres variables/membres". Je vous concède que j'aurais peut-être mieux fait de m'abstenir d'entrer dans de telles considérations de micro-optimisation car il est évident que même si utiliser un int8 serait légèrement plus rapide (ce dont je doute très sincèrement mais bon je n'arrive pas à trouver la preuve alors admettons*), vous n'aller rien gagner du tout compte tenu de la complexités des bibliothèques et systèmes graphiques que vous utilisés.
PS1: J'accepte vos excuses mais tâchez quand même d'être moins abrasif envers ceux qui veulent vous faire avancer. Btw je suis aussi un autodidacte, je ne prétend pas avoir la science infuse et je me trompe naturellement assez régulièrement. Je ne vous dois rien si ce n'est le respect. Je vous souhaite donc de persévérer, et dites vous bien que ce qui ne fait pas de sens aujourd'hui en fera sûrement demain.
*: Sur ce document il est montré sur un ensemble de processeurs différents qu'un mov de 32 bit n'est pas plus rapide qu'un de 64 bit, c'est identique voire dans certains cas plus lent…: https://gmplib.org/~tege/x86-timing.pdf
[^] # Re: C++ type et performances
Posté par benja . En réponse au message pre-realease de battle-rage un jeu de combat a la street fighter.. Évalué à 3. Dernière modification le 24 octobre 2016 à 14:15.
En changeant l'ordre des questions.
Oui. L'assembleur va simplement transformer un fichier d'assembleur en un fichiers objet. Les instruction (mnemoniques) sont transformées en valeurs (opcodes) directement utilisable par le cpu. Donc ce que tu vois dans ton fichier .s correspond à un objdump -D sur ton fichier .o. À une exception près que certaines mnémoniques sont des mneoniques qui codent en fait une séquence d'autre mnémoniques, un peu comme si c'était des macros.
(C'est ensuite l'éditeur de liens (le linker) qui lors de l'assemblage des différents fichiers objet va substituer certaines valeur d'adresse par le valeur absolue (en simplifiant). C'est cette étape qui permet à ton code de faire un "jmp label_fonction". Tu peux appeller sans problème une fonction "extern" depuis du code assembleur)
Je parlais de l'alignement en mémoire des tes variable.
Si tu as:
Le mot B4B3B2B1 est à cheval sur les "mots mémoire" 0-1-2-3 et 4-5-6-7. Pour le charge dans un registre R1, tu vas d'abord le charger dans R2 le mot 0-3, R2 vaudra
--B4B3B2. ensuite tu fais un shit pour avoir R2=B4B3B200, ensuite tu charge/shift 4-7 dansR1=B1------,R1=000000B1et tu combine R1=R1 AND R2 = B4B3B2B1. Tout cela parce qu'un cpu 32 bit est éléctriquement conçu pour travailler sur des mots aligné sur 4 octes. Admettons que B3 soit un int8 que tu veuille mettre dans un registre, il vaut lire 0-3, et faire p.e. 2 shift, un à droite puis un à gauche (sur une archi petit boutant). Sur x86 c'est transparent, le cpu va le faire pour toi automatiquement, mais c'est plus lent donc vaut mieux travailler avec des variables alignées.Ne te méprends pas là n'est pas mon objectif qui est de te donner de nouvelles notions et de répondre à ta demande de feedback. Comme je t'ai dis ce n'est pas une mauvaise idée en soit car il est vrai que tu économises de la mémoire en ce faisant.
Je t'invite à faire l'expérience que je t'ai suggéré et en plus de faire un objdump -D sur les fichiers .o pour constater que tu auras strictement 2 fois la même chose. Tu peux encore utiliser le debugger gdb pour là partie "éxécution" mais tu ne verras rien de nouveau que tu n'aurais pas déjà vu dans le désassemblage par objdump.
[^] # Re: C++ type et performances
Posté par benja . En réponse au message pre-realease de battle-rage un jeu de combat a la street fighter.. Évalué à 2. Dernière modification le 23 octobre 2016 à 19:48.
Le complément à deux est simplement la représentation binaire d'un entier négatif. Le truc c'est qu'en utilisant cette représentation une addition n'a pas besoin de tester le signe des opérantes. Au niveau du cpu, cela ne change strictement rien, il n'y pas de test supplémentaire, d'ailleurs comment ferait-il pour faire la différence entre une valeur signée d'une non signée ?? Pour le prouver il suffit de créer un fichier signed.c qui contient la fonction "int monadd(int a, int b) { return a+b;}", tu fais de même avec unsigned.c "unsigned int monadd(unsigned a, unsigned b) {return a+b;}", tu compiles avec gcc -save-temps -c unsigned.c, tu regarde le fichier assembleur .s et tu verras qu'il n'y a aucune différence. Comme je l'ai dit, ce qu'il peut y avoir comme différence serait du à une décision de l'optimisateur de gcc qui pourrait supprimer du code. Donc bref, tu mets unsigned si c'est effectivement le domaine de ta variable, c'est très bien mais ça ne changera strictement rien en ce qui concerne la rapidité d'exécution.
Par contre il ne faut jamais assigner un unsigned vers un signed ou inversément. Le language C admet cela en tant que cast implicite, si tu as de la chance ton compilateur t'arvertira, ou pas… Parce ça peut avoir de fâcheuses conséquences et est une source de problèmes de sécurité à cause des overflows et des optimisations. Malheureusement c'est un peu plus compliqué à expliquer de manière succinte.
Pour en revenir au int8 vs int. Si tu utilises des int8s sans padding (ce que tu sembles vouloir faire car pour pouvoir économiser de la mémoire), tu vas imposer de facto des lectures non-alignées car l'adresse de ta variable ne tombera pas toujours sur un multiple de 4 octets. Certaines archi imposent d'utiliser une instruction différente ou une série d'instructions pour cela. Grossièrement, elles vont lire la lecture du mot à l'adresse alignée inférieure et faire un shift de bit pour avoir ton octet dans la partie lsb. Encore pire, si tu lis un int32 non aligné (c.-à-d. à cheval sur deux int32 alignés), elle va devoir lire le mot d'en dessous, faire un shit, celui du dessus, faire un shift et enfin combiner les deux moitiées. x86 est "non-alignée" (excepté les instructions style mmx,sse,etc.), ce qui fait que la même instruction marche avec les deux types d'adresse, néanmoins elle reste moins performante avec des adresses non-alignées car la même partie de passe-passe va être faite par le cpu, dans ton dos.
Ceci dit, ça n'est pas pour cela que c'est une mauvaise idée ou que cela sera toujours moins performant. En effet, la mémoire sauvegardée peut servir à autre chose; par exemple dans un environement restreint type console de jeux, ça peut-être un bon calcul.