Post Mont Tremblant mailing

Gabriel Dos Reis

22/01/2006 à 19:59

( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis writes:
|
| > ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:
| >
| > [ ...]
| > |
| > | Je m'étonne du "only required", si on regarde l'exemple suivant :
| > |
| > | concept PostIncrementable <class T>
| > | {
| > | Var<T> v;
| > | v++;
| > | }
| > |
| > | template <class T>
| > | where PostIncrementable<T>
| > | T f( )
| > | {
| > | T t;
| > | t++;
| > | return t;
| > | }
| > |
| > | D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| > | obligatoirement fournir les operations spécifiés dans le concept
| > | PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| > | par exemple la construction par défaut d'un T.
| >
| > Oui.
|
| concept Parallelizable <class T>
| {
| T v1, v2;
| typename T::size_type i;
| v[i];
| v1 + v2;
| v1 * v2; // par exemple ...
| }
|
| template <Parallelizable T>
| void f( T const& t )
| {
| auto* x = &t[0];
| }
|
| Alors ceci ne peux pas être rejeter par le compilateur ?

Il doit l'être. Et s'il ne le peut pas alors tu as une raison de plus
d'utiliser « The Pivot ».

La raison pourquoi il doit l'être est que Parallelizable ne dit pas
que l'expression t[0] peut être l'opérande de « & ».

| Comment peut-on alors formuler, en C++0x standard, un concept
| interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
| faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
| faire du calcul à hautes performances.

Le propos de « The Pivot », c'est de faire le constat que quelque soit le
nombre d'extensions ajoutées au langage (en supposant que ce soit
facile d'ajouter une extension au langage), il y aura toujours des
zones non couvertes -- en général, ces zones sont d'ordre sémantique
-- mieux traitées par un outil spécialisé -- voir l'article «
rationale for SELL. »

| > | Les commentaires dans le squelette du concept Parallelizable sus-cité
| > | me paraisse contradictoire avec ce que je comprends.
| >
| > Je ne comprends pas.
| >
| > | Peut-être est-il envisagé une solution de ce genre (?) :
| > |
| > | template <class T>
| > | expectexactly PostIncrementable<T>
| > | T f( )
| > | {
| > | T t; // Erreur
| > | t++;
| > | return t;
| > | }
| > |
| > | qui demande au compilateur de regarder dans la scope de f (au moins
| > | ...), si chaque opération sur un T est spécifié dans sa clause
| > | "expectexactly". Cela me parait difficilement faisable non ?
| >
| > Je ne suis pas aou courant d'une proposition « expectexactly » et ce
| > qu'est sa sémantique.
|
| Non, ce n'est pas une proposition officielle ;) La clause where telle
| que je la comprend, est satisfaite/vraie lorsque T fourni *au moins*
| les operations présentes dans le concept sous-jacent.
|
| Ce qui a l'air d'être requis pour Parallelizable est : T fourni *au
| moins* les operations présentes dans le concept sous-jacent, *et pas
| une de plus*, c'est ce que je voulais dire par expectexactly.

La définition du concept Parallelizable dit que le container fournit
au moins ces opérations là. Dans la définition d'un template, son rôle
est de garantir qu'aucune autre opération n'est utilisée en déhors de
celles mentionnées dans le concept.

| > Le commentaire dans dans Parallelizable veut dire que seules les
| > opérations spécifiées seront acceptées dans le corps de la fonction
| > qui est controlée par Parallelizable.
|
| Ce qui nécessite une analyse du corp de la fonction. Je crois que
| l'origine de mon incompréhension réside dans le fait que je ne
| distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
| calcul à hautes performances.

Un SELL est une extension du langage par des bibliothèques, supportée
par un outil d'analyse. Voir l'article « A rationale for SELL. »

| En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
| effectuée pour déconsidérer une fonction lors de la résolution de
| surcharge.
| Est-ce que ça peut être le cas dans une extension SELL ?

Avec un SELL, on fait une analyse statique et des transformations de
programmes basées sur des considérations sémantiques ; en particulier,
avec un SELL on fait toute sorte de manipulation qu'un compilateur
ordinaire ne ferait pas ou ne serait pas requis de faire.

-- Gaby

fabien.chene.invalid@nospam.laposte.net ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> writes:
|
| > fabien.chene.invalid@nospam.laposte.net ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:
| >
| > [ ...]
| > |
| > | Je m'étonne du "only required", si on regarde l'exemple suivant :
| > |
| > | concept PostIncrementable <class T>
| > | {
| > | Var<T> v;
| > | v++;
| > | }
| > |
| > | template <class T>
| > | where PostIncrementable<T>
| > | T f( )
| > | {
| > | T t;
| > | t++;
| > | return t;
| > | }
| > |
| > | D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| > | obligatoirement fournir les operations spécifiés dans le concept
| > | PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| > | par exemple la construction par défaut d'un T.
| >
| > Oui.
|
| concept Parallelizable <class T>
| {
| T v1, v2;
| typename T::size_type i;
| v[i];
| v1 + v2;
| v1 * v2; // par exemple ...
| }
|
| template <Parallelizable T>
| void f( T const& t )
| {
| auto* x = &t[0];
| }
|
| Alors ceci ne peux pas être rejeter par le compilateur ?

Il doit l'être. Et s'il ne le peut pas alors tu as une raison de plus
d'utiliser « The Pivot ».

La raison pourquoi il doit l'être est que Parallelizable ne dit pas
que l'expression t[0] peut être l'opérande de « & ».

| Comment peut-on alors formuler, en C++0x standard, un concept
| interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
| faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
| faire du calcul à hautes performances.

Le propos de « The Pivot », c'est de faire le constat que quelque soit le
nombre d'extensions ajoutées au langage (en supposant que ce soit
facile d'ajouter une extension au langage), il y aura toujours des
zones non couvertes -- en général, ces zones sont d'ordre sémantique
-- mieux traitées par un outil spécialisé -- voir l'article «
rationale for SELL. »

| > | Les commentaires dans le squelette du concept Parallelizable sus-cité
| > | me paraisse contradictoire avec ce que je comprends.
| >
| > Je ne comprends pas.
| >
| > | Peut-être est-il envisagé une solution de ce genre (?) :
| > |
| > | template <class T>
| > | expectexactly PostIncrementable<T>
| > | T f( )
| > | {
| > | T t; // Erreur
| > | t++;
| > | return t;
| > | }
| > |
| > | qui demande au compilateur de regarder dans la scope de f (au moins
| > | ...), si chaque opération sur un T est spécifié dans sa clause
| > | "expectexactly". Cela me parait difficilement faisable non ?
| >
| > Je ne suis pas aou courant d'une proposition « expectexactly » et ce
| > qu'est sa sémantique.
|
| Non, ce n'est pas une proposition officielle ;) La clause where telle
| que je la comprend, est satisfaite/vraie lorsque T fourni *au moins*
| les operations présentes dans le concept sous-jacent.
|
| Ce qui a l'air d'être requis pour Parallelizable est : T fourni *au
| moins* les operations présentes dans le concept sous-jacent, *et pas
| une de plus*, c'est ce que je voulais dire par expectexactly.

La définition du concept Parallelizable dit que le container fournit
au moins ces opérations là. Dans la définition d'un template, son rôle
est de garantir qu'aucune autre opération n'est utilisée en déhors de
celles mentionnées dans le concept.

| > Le commentaire dans dans Parallelizable veut dire que seules les
| > opérations spécifiées seront acceptées dans le corps de la fonction
| > qui est controlée par Parallelizable.
|
| Ce qui nécessite une analyse du corp de la fonction. Je crois que
| l'origine de mon incompréhension réside dans le fait que je ne
| distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
| calcul à hautes performances.

Un SELL est une extension du langage par des bibliothèques, supportée
par un outil d'analyse. Voir l'article « A rationale for SELL. »

| En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
| effectuée pour déconsidérer une fonction lors de la résolution de
| surcharge.
| Est-ce que ça peut être le cas dans une extension SELL ?

Avec un SELL, on fait une analyse statique et des transformations de
programmes basées sur des considérations sémantiques ; en particulier,
avec un SELL on fait toute sorte de manipulation qu'un compilateur
ordinaire ne ferait pas ou ne serait pas requis de faire.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis writes:
|
| > ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:
| >
| > [ ...]
| > |
| > | Je m'étonne du "only required", si on regarde l'exemple suivant :
| > |
| > | concept PostIncrementable <class T>
| > | {
| > | Var<T> v;
| > | v++;
| > | }
| > |
| > | template <class T>
| > | where PostIncrementable<T>
| > | T f( )
| > | {
| > | T t;
| > | t++;
| > | return t;
| > | }
| > |
| > | D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| > | obligatoirement fournir les operations spécifiés dans le concept
| > | PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| > | par exemple la construction par défaut d'un T.
| >
| > Oui.
|
| concept Parallelizable <class T>
| {
| T v1, v2;
| typename T::size_type i;
| v[i];
| v1 + v2;
| v1 * v2; // par exemple ...
| }
|
| template <Parallelizable T>
| void f( T const& t )
| {
| auto* x = &t[0];
| }
|
| Alors ceci ne peux pas être rejeter par le compilateur ?

Il doit l'être. Et s'il ne le peut pas alors tu as une raison de plus
d'utiliser « The Pivot ».

La raison pourquoi il doit l'être est que Parallelizable ne dit pas
que l'expression t[0] peut être l'opérande de « & ».

| Comment peut-on alors formuler, en C++0x standard, un concept
| interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
| faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
| faire du calcul à hautes performances.

Le propos de « The Pivot », c'est de faire le constat que quelque soit le
nombre d'extensions ajoutées au langage (en supposant que ce soit
facile d'ajouter une extension au langage), il y aura toujours des
zones non couvertes -- en général, ces zones sont d'ordre sémantique
-- mieux traitées par un outil spécialisé -- voir l'article «
rationale for SELL. »

| > | Les commentaires dans le squelette du concept Parallelizable sus-cité
| > | me paraisse contradictoire avec ce que je comprends.
| >
| > Je ne comprends pas.
| >
| > | Peut-être est-il envisagé une solution de ce genre (?) :
| > |
| > | template <class T>
| > | expectexactly PostIncrementable<T>
| > | T f( )
| > | {
| > | T t; // Erreur
| > | t++;
| > | return t;
| > | }
| > |
| > | qui demande au compilateur de regarder dans la scope de f (au moins
| > | ...), si chaque opération sur un T est spécifié dans sa clause
| > | "expectexactly". Cela me parait difficilement faisable non ?
| >
| > Je ne suis pas aou courant d'une proposition « expectexactly » et ce
| > qu'est sa sémantique.
|
| Non, ce n'est pas une proposition officielle ;) La clause where telle
| que je la comprend, est satisfaite/vraie lorsque T fourni *au moins*
| les operations présentes dans le concept sous-jacent.
|
| Ce qui a l'air d'être requis pour Parallelizable est : T fourni *au
| moins* les operations présentes dans le concept sous-jacent, *et pas
| une de plus*, c'est ce que je voulais dire par expectexactly.

La définition du concept Parallelizable dit que le container fournit
au moins ces opérations là. Dans la définition d'un template, son rôle
est de garantir qu'aucune autre opération n'est utilisée en déhors de
celles mentionnées dans le concept.

| > Le commentaire dans dans Parallelizable veut dire que seules les
| > opérations spécifiées seront acceptées dans le corps de la fonction
| > qui est controlée par Parallelizable.
|
| Ce qui nécessite une analyse du corp de la fonction. Je crois que
| l'origine de mon incompréhension réside dans le fait que je ne
| distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
| calcul à hautes performances.

Un SELL est une extension du langage par des bibliothèques, supportée
par un outil d'analyse. Voir l'article « A rationale for SELL. »

| En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
| effectuée pour déconsidérer une fonction lors de la résolution de
| surcharge.
| Est-ce que ça peut être le cas dans une extension SELL ?

Avec un SELL, on fait une analyse statique et des transformations de
programmes basées sur des considérations sémantiques ; en particulier,
avec un SELL on fait toute sorte de manipulation qu'un compilateur
ordinaire ne ferait pas ou ne serait pas requis de faire.

-- Gaby

fabien.chene.nospam

08/02/2006 à 21:43

Gabriel Dos Reis writes:

| Comment peut-on alors formuler, en C++0x standard, un concept
| interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
| faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
| faire du calcul à hautes performances.

Le propos de « The Pivot », c'est de faire le constat que quelque soit le
nombre d'extensions ajoutées au langage (en supposant que ce soit
facile d'ajouter une extension au langage), il y aura toujours des
zones non couvertes -- en général, ces zones sont d'ordre sémantique
-- mieux traitées par un outil spécialisé -- voir l'article «
rationale for SELL. »

Que peut-on attendre d'un SELL dédié au calcul numérique ? Un support
permettant la vectorisation via absence d'alias OK. Par curiosité, y a
t'il d'autres idées ?

Gabriel Dos Reis

08/02/2006 à 22:28

(Fabien CHÊNE) writes:

| Gabriel Dos Reis writes:
|
| > | Comment peut-on alors formuler, en C++0x standard, un concept
| > | interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
| > | faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
| > | faire du calcul à hautes performances.
| >
| > Le propos de « The Pivot », c'est de faire le constat que quelque soit le
| > nombre d'extensions ajoutées au langage (en supposant que ce soit
| > facile d'ajouter une extension au langage), il y aura toujours des
| > zones non couvertes -- en général, ces zones sont d'ordre sémantique
| > -- mieux traitées par un outil spécialisé -- voir l'article «
| > rationale for SELL. »
|
| Que peut-on attendre d'un SELL dédié au calcul numérique ?

Il y a calcul numérique et calcul numérique :-)
Et un SELL (comme tout autre « DSL ») est défini par les contraintes
du domaine. Si par exemple, la chose la plus importante, c'est
d'assurer de non-aliasing, on définira le SELL en fonction. Si, par
contre, ce qui intéresse c'est le cacul distribué on fera aussi en
sorte que le programmeur n'utilise pas des constructions qui interfèrent
avec la distribution en même temps qu'on lui donne les bons moyens.
Si on veut procéder à des simplifications algébriques comme ils font
ici

http://www.codeboost.org/

l'utilisateur définira le SELL en fonction.

-- Gaby

fabien.chene.nospam

13/02/2006 à 22:54

Gabriel Dos Reis writes:

(Fabien CHÊNE) writes:

| Gabriel Dos Reis writes:
|
| > | Comment peut-on alors formuler, en C++0x standard, un concept
| > | interdisant 3.1 #2 dans l'article sur SELL ? Si cela n'est pas
| > | faisable, je comprendrai mieux l'intérêt de passer par un SELL pour
| > | faire du calcul à hautes performances.
| >
| > Le propos de « The Pivot », c'est de faire le constat que quelque soit le
| > nombre d'extensions ajoutées au langage (en supposant que ce soit
| > facile d'ajouter une extension au langage), il y aura toujours des
| > zones non couvertes -- en général, ces zones sont d'ordre sémantique
| > -- mieux traitées par un outil spécialisé -- voir l'article «
| > rationale for SELL. »
|
| Que peut-on attendre d'un SELL dédié au calcul numérique ?

Il y a calcul numérique et calcul numérique :-)
Et un SELL (comme tout autre « DSL ») est défini par les contraintes
du domaine. Si par exemple, la chose la plus importante, c'est
d'assurer de non-aliasing, on définira le SELL en fonction. Si, par
contre, ce qui intéresse c'est le cacul distribué on fera aussi en
sorte que le programmeur n'utilise pas des constructions qui interfèrent
avec la distribution en même temps qu'on lui donne les bons moyens.
Si on veut procéder à des simplifications algébriques comme ils font
ici

http://www.codeboost.org/

l'utilisateur définira le SELL en fonction.

Tant de choses à découvir ... (Dommage qu'il n'y ait pas d'ebuild sous
gentoo, malgré qu'un des créateurs de codeboost fasse parti de
l'équipe Gentoo).

Dans ton livre en préparation, y aura t'il un chapitre traitant des
différents sujets que tu viens d'évoquer ?

-- Fab --

fabien.chene.nospam

13/02/2006 à 23:31

Gabriel Dos Reis writes:

( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis writes:
|
| > ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:
| >
| > [ ...]
| > |
| > | Je m'étonne du "only required", si on regarde l'exemple suivant :
| > |
| > | concept PostIncrementable <class T>
| > | {
| > | Var<T> v;
| > | v++;
| > | }
| > |
| > | template <class T>
| > | where PostIncrementable<T>
| > | T f( )
| > | {
| > | T t;
| > | t++;
| > | return t;
| > | }
| > |
| > | D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| > | obligatoirement fournir les operations spécifiés dans le concept
| > | PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| > | par exemple la construction par défaut d'un T.
| >
| > Oui.

J'étais d'abord rassuré par cette réponse, puis confus. Je pense la
comprendre maintant : T doit obligatoirement fournir les opérations
spécifiés dans le concept, peut fournir d'autres opérations, pourvu
qu'on y fasse pas appel dans la définition de la fonction.
En l'occurence, f() fait appel au constructeut par défaut, ce que le
compilateur devrait refuser ... non ?

| concept Parallelizable <class T>
| {
| T v1, v2;
| typename T::size_type i;
| v[i];
| v1 + v2;
| v1 * v2; // par exemple ...
| }
|
| template <Parallelizable T>
| void f( T const& t )
| {
| auto* x = &t[0];
| }
|
| Alors ceci ne peux pas être rejeter par le compilateur ?

Il doit l'être. Et s'il ne le peut pas alors tu as une raison de plus
d'utiliser « The Pivot ».

La raison pourquoi il doit l'être est que Parallelizable ne dit pas
que l'expression t[0] peut être l'opérande de « & ».

cf ci-dessus, tout comme PostIncrementable ne dit pas qu'un T peut
être construit par défaut.

[...]
La définition du concept Parallelizable dit que le container fournit
au moins ces opérations là. Dans la définition d'un template, son rôle
est de garantir qu'aucune autre opération n'est utilisée en déhors de
celles mentionnées dans le concept.

| > Le commentaire dans dans Parallelizable veut dire que seules les
| > opérations spécifiées seront acceptées dans le corps de la fonction
| > qui est controlée par Parallelizable.
|
| Ce qui nécessite une analyse du corp de la fonction. Je crois que
| l'origine de mon incompréhension réside dans le fait que je ne
| distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
| calcul à hautes performances.

Un SELL est une extension du langage par des bibliothèques, supportée
par un outil d'analyse. Voir l'article « A rationale for SELL. »

| En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
| effectuée pour déconsidérer une fonction lors de la résolution de
| surcharge.
| Est-ce que ça peut être le cas dans une extension SELL ?

Avec un SELL, on fait une analyse statique et des transformations de
programmes basées sur des considérations sémantiques ; en particulier,
avec un SELL on fait toute sorte de manipulation qu'un compilateur
ordinaire ne ferait pas ou ne serait pas requis de faire.

En fait, je pensais à un cas où on était en présence d'une résolution
de surcharge impliquant des fonctions contraintes par concepts, qu'une
fonction était élue (en ne regardant que sa signature), puis recalée
lors de l'analyse du corp de la fonction.

Je me demandais alors s'il n'y avait pas un risque d'oublier une
fonction, qui était un moins bon match certes, mais dont le corps
respectait les contraintes exprimées par le concept.

C'est pourquoi je m'interrogeais sur la manière dont était effectuée
la résolution de surcharge, et si l'analyse du corps de la fonction
était faite après la résolution de surcharge, ou avant. La lecture des
2 papiers sur les concepts (première lecture, d'autres seront
nécessaires) que tu m'as conseillé ne m'a pas renseigné sur ce point.

-- Fab --

Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> writes:

fabien.chene.invalid@nospam.laposte.net ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> writes:
|
| > fabien.chene.invalid@nospam.laposte.net ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:
| >
| > [ ...]
| > |
| > | Je m'étonne du "only required", si on regarde l'exemple suivant :
| > |
| > | concept PostIncrementable <class T>
| > | {
| > | Var<T> v;
| > | v++;
| > | }
| > |
| > | template <class T>
| > | where PostIncrementable<T>
| > | T f( )
| > | {
| > | T t;
| > | t++;
| > | return t;
| > | }
| > |
| > | D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| > | obligatoirement fournir les operations spécifiés dans le concept
| > | PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| > | par exemple la construction par défaut d'un T.
| >
| > Oui.

J'étais d'abord rassuré par cette réponse, puis confus. Je pense la
comprendre maintant : T doit obligatoirement fournir les opérations
spécifiés dans le concept, peut fournir d'autres opérations, pourvu
qu'on y fasse pas appel dans la définition de la fonction.
En l'occurence, f() fait appel au constructeut par défaut, ce que le
compilateur devrait refuser ... non ?

| concept Parallelizable <class T>
| {
| T v1, v2;
| typename T::size_type i;
| v[i];
| v1 + v2;
| v1 * v2; // par exemple ...
| }
|
| template <Parallelizable T>
| void f( T const& t )
| {
| auto* x = &t[0];
| }
|
| Alors ceci ne peux pas être rejeter par le compilateur ?

Il doit l'être. Et s'il ne le peut pas alors tu as une raison de plus
d'utiliser « The Pivot ».

La raison pourquoi il doit l'être est que Parallelizable ne dit pas
que l'expression t[0] peut être l'opérande de « & ».

cf ci-dessus, tout comme PostIncrementable ne dit pas qu'un T peut
être construit par défaut.

[...]
La définition du concept Parallelizable dit que le container fournit
au moins ces opérations là. Dans la définition d'un template, son rôle
est de garantir qu'aucune autre opération n'est utilisée en déhors de
celles mentionnées dans le concept.

| > Le commentaire dans dans Parallelizable veut dire que seules les
| > opérations spécifiées seront acceptées dans le corps de la fonction
| > qui est controlée par Parallelizable.
|
| Ce qui nécessite une analyse du corp de la fonction. Je crois que
| l'origine de mon incompréhension réside dans le fait que je ne
| distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
| calcul à hautes performances.

Un SELL est une extension du langage par des bibliothèques, supportée
par un outil d'analyse. Voir l'article « A rationale for SELL. »

| En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
| effectuée pour déconsidérer une fonction lors de la résolution de
| surcharge.
| Est-ce que ça peut être le cas dans une extension SELL ?

Avec un SELL, on fait une analyse statique et des transformations de
programmes basées sur des considérations sémantiques ; en particulier,
avec un SELL on fait toute sorte de manipulation qu'un compilateur
ordinaire ne ferait pas ou ne serait pas requis de faire.

En fait, je pensais à un cas où on était en présence d'une résolution
de surcharge impliquant des fonctions contraintes par concepts, qu'une
fonction était élue (en ne regardant que sa signature), puis recalée
lors de l'analyse du corp de la fonction.

Je me demandais alors s'il n'y avait pas un risque d'oublier une
fonction, qui était un moins bon match certes, mais dont le corps
respectait les contraintes exprimées par le concept.

C'est pourquoi je m'interrogeais sur la manière dont était effectuée
la résolution de surcharge, et si l'analyse du corps de la fonction
était faite après la résolution de surcharge, ou avant. La lecture des
2 papiers sur les concepts (première lecture, d'autres seront
nécessaires) que tu m'as conseillé ne m'a pas renseigné sur ce point.

-- Fab --

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis writes:

( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:

| Gabriel Dos Reis writes:
|
| > ( =?iso-8859-15?q?Fabien_CHÊNE?=) writes:
| >
| > [ ...]
| > |
| > | Je m'étonne du "only required", si on regarde l'exemple suivant :
| > |
| > | concept PostIncrementable <class T>
| > | {
| > | Var<T> v;
| > | v++;
| > | }
| > |
| > | template <class T>
| > | where PostIncrementable<T>
| > | T f( )
| > | {
| > | T t;
| > | t++;
| > | return t;
| > | }
| > |
| > | D'après ce que j'ai lu dans le dernier papier sur les concepts, T doit
| > | obligatoirement fournir les operations spécifiés dans le concept
| > | PostIncrementable, mais peut aussi fournir d'autres opérations, comme
| > | par exemple la construction par défaut d'un T.
| >
| > Oui.

J'étais d'abord rassuré par cette réponse, puis confus. Je pense la
comprendre maintant : T doit obligatoirement fournir les opérations
spécifiés dans le concept, peut fournir d'autres opérations, pourvu
qu'on y fasse pas appel dans la définition de la fonction.
En l'occurence, f() fait appel au constructeut par défaut, ce que le
compilateur devrait refuser ... non ?

| concept Parallelizable <class T>
| {
| T v1, v2;
| typename T::size_type i;
| v[i];
| v1 + v2;
| v1 * v2; // par exemple ...
| }
|
| template <Parallelizable T>
| void f( T const& t )
| {
| auto* x = &t[0];
| }
|
| Alors ceci ne peux pas être rejeter par le compilateur ?

Il doit l'être. Et s'il ne le peut pas alors tu as une raison de plus
d'utiliser « The Pivot ».

La raison pourquoi il doit l'être est que Parallelizable ne dit pas
que l'expression t[0] peut être l'opérande de « & ».

cf ci-dessus, tout comme PostIncrementable ne dit pas qu'un T peut
être construit par défaut.

[...]
La définition du concept Parallelizable dit que le container fournit
au moins ces opérations là. Dans la définition d'un template, son rôle
est de garantir qu'aucune autre opération n'est utilisée en déhors de
celles mentionnées dans le concept.

| > Le commentaire dans dans Parallelizable veut dire que seules les
| > opérations spécifiées seront acceptées dans le corps de la fonction
| > qui est controlée par Parallelizable.
|
| Ce qui nécessite une analyse du corp de la fonction. Je crois que
| l'origine de mon incompréhension réside dans le fait que je ne
| distingue pas ce qui est C++0x de ce qui est "SELL" appliquée au
| calcul à hautes performances.

Un SELL est une extension du langage par des bibliothèques, supportée
par un outil d'analyse. Voir l'article « A rationale for SELL. »

| En C++0x, l'analyse du corp de la fonction n'est (sauf erreur) pas
| effectuée pour déconsidérer une fonction lors de la résolution de
| surcharge.
| Est-ce que ça peut être le cas dans une extension SELL ?

Avec un SELL, on fait une analyse statique et des transformations de
programmes basées sur des considérations sémantiques ; en particulier,
avec un SELL on fait toute sorte de manipulation qu'un compilateur
ordinaire ne ferait pas ou ne serait pas requis de faire.

En fait, je pensais à un cas où on était en présence d'une résolution
de surcharge impliquant des fonctions contraintes par concepts, qu'une
fonction était élue (en ne regardant que sa signature), puis recalée
lors de l'analyse du corp de la fonction.

Je me demandais alors s'il n'y avait pas un risque d'oublier une
fonction, qui était un moins bon match certes, mais dont le corps
respectait les contraintes exprimées par le concept.

C'est pourquoi je m'interrogeais sur la manière dont était effectuée
la résolution de surcharge, et si l'analyse du corps de la fonction
était faite après la résolution de surcharge, ou avant. La lecture des
2 papiers sur les concepts (première lecture, d'autres seront
nécessaires) que tu m'as conseillé ne m'a pas renseigné sur ce point.

-- Fab --

Gabriel Dos Reis

14/02/2006 à 20:48

(Fabien CHÊNE) writes:

[...]

| Dans ton livre en préparation, y aura t'il un chapitre traitant des
| différents sujets que tu viens d'évoquer ?

oui; il a déjà subi beaucoup de changements; et très certainement il
contiendra certaines choses que j'aborderai ici :

http://www-rocq.inria.fr/MACS/article.php3?id_article

-- Gaby

fabien.chene.nospam

26/02/2006 à 23:22

Gabriel Dos Reis writes:

(Fabien CHÊNE) writes:

[...]

| Dans ton livre en préparation, y aura t'il un chapitre traitant des
| différents sujets que tu viens d'évoquer ?

oui; il a déjà subi beaucoup de changements; et très certainement il
contiendra certaines choses que j'aborderai ici :

http://www-rocq.inria.fr/MACS/article.php3?id_article

Et ... ahhemm ... bientôt dans les bacs ? :)

J'en suis resté au Barton & Nackman. J'aime beaucoup ce livre, mais je
crois qu'il n'est aujourd'hui plus que d'intérêt historique -- je
l'aurai lu rien que pour ça -- par rapport aux progrès du calcul
scientifique, et à l'évolution du C++. Je suis à la recherche d'un
livre de référence plus actuel, je pense que le tien me conviendra
très bien.

Sinon, il y a une gamme de questions pour lesquelles j'ai du mal à
trouver des réponses : ce qui concerne la génération de code pour du
hardware (+-) spécialisé.

Par exemple : Comment un compilateur/SELL pourra-t'il bénéficier d'une
information de non aliasing ? Sur du hardware inadapté ? Sur du
hardware spécialisé ? Est-ce que ça favorisera sous certaines
conditions la vectorisation ? la localité en cache ? etc.

Une idée où trouver de la documentation pour cela ?

-- Fab --

Post Mont Tremblant mailing

7 réponses

Veuillez sélectionner un problème