Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
Je me contenterai donc pour le moment du passage du résultat en
paramètre de la fonction...
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
Je me contenterai donc pour le moment du passage du résultat en
paramètre de la fonction...
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
Je me contenterai donc pour le moment du passage du résultat en
paramètre de la fonction...
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
In article ,
Thierry Abrard wrote:Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Oui, c'est souvent necessaire, mais dans la plupart des cas ou on peut
s'en passer, s'en passer est souvent plus efficace.
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
In article <2dd29628.0312041540.5fb9eb5@posting.google.com>,
Thierry Abrard <thierryabrard@wanadoo.fr> wrote:
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Oui, c'est souvent necessaire, mais dans la plupart des cas ou on peut
s'en passer, s'en passer est souvent plus efficace.
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
In article ,
Thierry Abrard wrote:Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Oui, c'est souvent necessaire, mais dans la plupart des cas ou on peut
s'en passer, s'en passer est souvent plus efficace.
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
Tu m'expliques comment tu fais des listes chaînées sans malloc ?
Perso, je sais pas faire :/
Tu m'expliques comment tu fais des listes chaînées sans malloc ?
Perso, je sais pas faire :/
Tu m'expliques comment tu fais des listes chaînées sans malloc ?
Perso, je sais pas faire :/
In article ,
Thierry Abrard wrote:Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Je ne suis pas du tout d'accord (sauf pour les débutants qui
commencent juste à apprendre les pointeurs), mais on en a déjà un peu
discuté, et ce n'est pas le sujet du forum.
Oui, c'est souvent necessaire, mais dans la plupart des cas ou on peut
s'en passer, s'en passer est souvent plus efficace.
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
Tu m'expliques comment tu fais des listes chaînées sans malloc ?
Perso, je sais pas faire :/
In article <2dd29628.0312041540.5fb9eb5@posting.google.com>,
Thierry Abrard <thierryabrard@wanadoo.fr> wrote:
Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Je ne suis pas du tout d'accord (sauf pour les débutants qui
commencent juste à apprendre les pointeurs), mais on en a déjà un peu
discuté, et ce n'est pas le sujet du forum.
Oui, c'est souvent necessaire, mais dans la plupart des cas ou on peut
s'en passer, s'en passer est souvent plus efficace.
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
Tu m'expliques comment tu fais des listes chaînées sans malloc ?
Perso, je sais pas faire :/
In article ,
Thierry Abrard wrote:Merci beaucoup pour tout ces éléments de réponses... je devrais
maintenant sans problème trouver une solution. Même si l'affectation
dynamique avec les malloc etc n'est pas évident à comprendre (!), je
sais où chercher.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Je ne suis pas du tout d'accord (sauf pour les débutants qui
commencent juste à apprendre les pointeurs), mais on en a déjà un peu
discuté, et ce n'est pas le sujet du forum.
Oui, c'est souvent necessaire, mais dans la plupart des cas ou on peut
s'en passer, s'en passer est souvent plus efficace.
[ inserer ici un couplet standard sur les perfs respectives des tableaux
ajustes avec realloc compares aux listes chainees ]
Tu m'expliques comment tu fais des listes chaînées sans malloc ?
Perso, je sais pas faire :/
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Je ne suis pas du tout d'accord (sauf pour les débutants qui
commencent juste à apprendre les pointeurs), mais on en a déjà un peu
discuté, et ce n'est pas le sujet du forum.
Le contraire m'aurait etonne. Je pense que tu as tres fortement
tort, et les perfs mesurees sur un systeme tendent a le prouver,
par rapport a la dialectique qui sous-tend le projet Hurd.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Je ne suis pas du tout d'accord (sauf pour les débutants qui
commencent juste à apprendre les pointeurs), mais on en a déjà un peu
discuté, et ce n'est pas le sujet du forum.
Le contraire m'aurait etonne. Je pense que tu as tres fortement
tort, et les perfs mesurees sur un systeme tendent a le prouver,
par rapport a la dialectique qui sous-tend le projet Hurd.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
En fait, lorsqu'on peut eviter l'allocation dynamique avec malloc, on
s'en porte assez souvent mieux.
Je ne suis pas du tout d'accord (sauf pour les débutants qui
commencent juste à apprendre les pointeurs), mais on en a déjà un peu
discuté, et ce n'est pas le sujet du forum.
Le contraire m'aurait etonne. Je pense que tu as tres fortement
tort, et les perfs mesurees sur un systeme tendent a le prouver,
par rapport a la dialectique qui sous-tend le projet Hurd.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Euh, les perfs du Hurd n'ont rien à voir avec malloc, mais à la
vitesse des IPCs sous Mach (pour info, avec L4 les IPCs sont environ
dix fois plus rapides)
D'autre part, les perfs ne sont pas le plus important dans beaucoup de
cas, la flexibilité, la robustesse et l'absence de contraintes pour
l'utilisateur sont plus importantes dans bcp de cas.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Ah oui, je suis d'accord (sauf si on souvent à retirer des éléments en
plein milieu).
Mais la 2ème approche utilise malloc aussi, et tu semblais donner ça
comme exemple de "sans malloc on fait mieux", j'ai sans doute mal
compris.
Euh, les perfs du Hurd n'ont rien à voir avec malloc, mais à la
vitesse des IPCs sous Mach (pour info, avec L4 les IPCs sont environ
dix fois plus rapides)
D'autre part, les perfs ne sont pas le plus important dans beaucoup de
cas, la flexibilité, la robustesse et l'absence de contraintes pour
l'utilisateur sont plus importantes dans bcp de cas.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Ah oui, je suis d'accord (sauf si on souvent à retirer des éléments en
plein milieu).
Mais la 2ème approche utilise malloc aussi, et tu semblais donner ça
comme exemple de "sans malloc on fait mieux", j'ai sans doute mal
compris.
Euh, les perfs du Hurd n'ont rien à voir avec malloc, mais à la
vitesse des IPCs sous Mach (pour info, avec L4 les IPCs sont environ
dix fois plus rapides)
D'autre part, les perfs ne sont pas le plus important dans beaucoup de
cas, la flexibilité, la robustesse et l'absence de contraintes pour
l'utilisateur sont plus importantes dans bcp de cas.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Ah oui, je suis d'accord (sauf si on souvent à retirer des éléments en
plein milieu).
Mais la 2ème approche utilise malloc aussi, et tu semblais donner ça
comme exemple de "sans malloc on fait mieux", j'ai sans doute mal
compris.
Euh, les perfs du Hurd n'ont rien à voir avec malloc, mais à la
vitesse des IPCs sous Mach (pour info, avec L4 les IPCs sont environ
dix fois plus rapides)
L'évaluation probable des performances fait partie de la phase de
conception en général. Je crois que le problème des performances de Mach
était assez rapidement connu. Pourquoi ont-ils fait un tel choix ?
D'autre part, les perfs ne sont pas le plus important dans beaucoup de
cas, la flexibilité, la robustesse et l'absence de contraintes pour
l'utilisateur sont plus importantes dans bcp de cas.
Le domaine nommé "système" en informatique (qui comprend ce qui est
systèmes d'exploitation) consiste principalement à améliorer les
performances d'un système.
Il y a eu effectivement la phase micronoyau pendant laquelle les
gens ont essayé de faire quelque chose de plus modulaire mais ils
se sont rapidement aperçu que cela était au détriment des
performances et qu'une des solutions pour obtenir des performances
était d'avoir un unique serveur sur le micronoyau (Darwin (aussi
connu sous le nom de Mac OS X)). Je crois que c'était également le
cas pour OSF/1.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
cas 1 :
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
cas 2 :
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Ah oui, je suis d'accord (sauf si on souvent à retirer des éléments en
plein milieu).
ai-je mal décrit mon système de liste chaînée dans mon post précédent ?
struct cellule {
/* ... */
unsigned int suivant;
};
struct cellule liste_chainee[LISTE_TAILLE_MAX];
Mais la 2ème approche utilise malloc aussi, et tu semblais donner ça
comme exemple de "sans malloc on fait mieux", j'ai sans doute mal
compris.
alors, dans le cas où on fait un malloc par cellule,(cas 1/)
on a un nombre de malloc() en O(n).
dans le cas 2/ décrit par Marc Espié, on obtient un nombre de malloc()
en O(log(n))
dans le pire des cas, c'est-à-dire : si on n'est pas arrivé à
évalué la taille maximum de la liste, ce que l'on peut résoudre par
limiter la taille de la liste, ce qui permet dans le meilleur des
cas d'obtenir un unique malloc(), voire zéro dans le cas d'une
déclaration statique.
Euh, les perfs du Hurd n'ont rien à voir avec malloc, mais à la
vitesse des IPCs sous Mach (pour info, avec L4 les IPCs sont environ
dix fois plus rapides)
L'évaluation probable des performances fait partie de la phase de
conception en général. Je crois que le problème des performances de Mach
était assez rapidement connu. Pourquoi ont-ils fait un tel choix ?
D'autre part, les perfs ne sont pas le plus important dans beaucoup de
cas, la flexibilité, la robustesse et l'absence de contraintes pour
l'utilisateur sont plus importantes dans bcp de cas.
Le domaine nommé "système" en informatique (qui comprend ce qui est
systèmes d'exploitation) consiste principalement à améliorer les
performances d'un système.
Il y a eu effectivement la phase micronoyau pendant laquelle les
gens ont essayé de faire quelque chose de plus modulaire mais ils
se sont rapidement aperçu que cela était au détriment des
performances et qu'une des solutions pour obtenir des performances
était d'avoir un unique serveur sur le micronoyau (Darwin (aussi
connu sous le nom de Mac OS X)). Je crois que c'était également le
cas pour OSF/1.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
cas 1 :
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
cas 2 :
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Ah oui, je suis d'accord (sauf si on souvent à retirer des éléments en
plein milieu).
ai-je mal décrit mon système de liste chaînée dans mon post précédent ?
struct cellule {
/* ... */
unsigned int suivant;
};
struct cellule liste_chainee[LISTE_TAILLE_MAX];
Mais la 2ème approche utilise malloc aussi, et tu semblais donner ça
comme exemple de "sans malloc on fait mieux", j'ai sans doute mal
compris.
alors, dans le cas où on fait un malloc par cellule,(cas 1/)
on a un nombre de malloc() en O(n).
dans le cas 2/ décrit par Marc Espié, on obtient un nombre de malloc()
en O(log(n))
dans le pire des cas, c'est-à-dire : si on n'est pas arrivé à
évalué la taille maximum de la liste, ce que l'on peut résoudre par
limiter la taille de la liste, ce qui permet dans le meilleur des
cas d'obtenir un unique malloc(), voire zéro dans le cas d'une
déclaration statique.
Euh, les perfs du Hurd n'ont rien à voir avec malloc, mais à la
vitesse des IPCs sous Mach (pour info, avec L4 les IPCs sont environ
dix fois plus rapides)
L'évaluation probable des performances fait partie de la phase de
conception en général. Je crois que le problème des performances de Mach
était assez rapidement connu. Pourquoi ont-ils fait un tel choix ?
D'autre part, les perfs ne sont pas le plus important dans beaucoup de
cas, la flexibilité, la robustesse et l'absence de contraintes pour
l'utilisateur sont plus importantes dans bcp de cas.
Le domaine nommé "système" en informatique (qui comprend ce qui est
systèmes d'exploitation) consiste principalement à améliorer les
performances d'un système.
Il y a eu effectivement la phase micronoyau pendant laquelle les
gens ont essayé de faire quelque chose de plus modulaire mais ils
se sont rapidement aperçu que cela était au détriment des
performances et qu'une des solutions pour obtenir des performances
était d'avoir un unique serveur sur le micronoyau (Darwin (aussi
connu sous le nom de Mac OS X)). Je crois que c'était également le
cas pour OSF/1.
Voici donc le couplet standard, vite vu.
Supposons qu'on ait une structure de donnees a stocker en nombre
consequents, disons struct machin.
cas 1 :
- on peut faire des listes chainees avec, ce qui implique plein de
pointeurs et de malloc, et des gros problemes de localite des donnees.
cas 2 :
- on peut tout stocker dans un tableau de taille limitee, quitte a faire
un coup de realloc() lorsque le tableau deborde.
La 2e approche explose tres regulierement la premiere en termes de
performances.
Ah oui, je suis d'accord (sauf si on souvent à retirer des éléments en
plein milieu).
ai-je mal décrit mon système de liste chaînée dans mon post précédent ?
struct cellule {
/* ... */
unsigned int suivant;
};
struct cellule liste_chainee[LISTE_TAILLE_MAX];
Mais la 2ème approche utilise malloc aussi, et tu semblais donner ça
comme exemple de "sans malloc on fait mieux", j'ai sans doute mal
compris.
alors, dans le cas où on fait un malloc par cellule,(cas 1/)
on a un nombre de malloc() en O(n).
dans le cas 2/ décrit par Marc Espié, on obtient un nombre de malloc()
en O(log(n))
dans le pire des cas, c'est-à-dire : si on n'est pas arrivé à
évalué la taille maximum de la liste, ce que l'on peut résoudre par
limiter la taille de la liste, ce qui permet dans le meilleur des
cas d'obtenir un unique malloc(), voire zéro dans le cas d'une
déclaration statique.