From cantao at ime.unicamp.br Mon Sep 2 22:08:49 2002 From: cantao at ime.unicamp.br (Renato Fernandes =?ISO-8859-1?Q?Cant=E3o?=) Date: 02 Sep 2002 19:08:49 -0300 Subject: UserFunction question Message-ID: <1031004532.2478.31.camel@lei061.lei.ime.unicamp.br> Hello Guys! I've been dealing with UserFunction, but I have a question: suppose I'm using a UserFunction to manipulate Array's of big elements, like that: typedef Array< 2 > InnerType_t; typedef Array< 1, InnerType_t > BigType_t; class Operation { public: // returning reference to avoid construction/destruction // repetition inline InnerType_t& operator( const InnerType_t& t ) const { p = t * t; // stupid example... return p; } private: InnerType_t p; // initialized in some manner in the constructor }; And then: main() { BigType_t Big1( 1000 ), Big2( 1000 ); for( int i = 0; i < 1000; i++ ) { Big1( i ).initialize( 100, 100 ); Big2( i ).initialize( 100, 100 ); } // fill the array's here... UserFunction< Operation > F; Big2 = F( Big1 ); } F runs through Big1, applies Operation.operator() in each Big1( i ) -- 2D Array's with 10000 elements each -- and finally *copies* the result to Big2( i ). Correct? I'm interested on this subject cause I do lots of operations with Arrays of Arrays, usually through loops. Loops are faster, cause -- I guess -- UserFunction has to copy the InnerType_t's between Big1 and Big2. An approach like: void operation( const InnerType_t& t, InnerType_t& p ) { p = t * t; } void applyOperation( const BigType_t& Big1, BigType_t& Big2 ) { const int n = Big1.length( 0 ); for( int i = 0; i < n; i++ ) { operation( Big1( i ), Big2( i ) ); } } is faster. So the question: is there a way to avoid this copying behavior, and so mimic the loop above, but still using UserFunction? Thanks a lot, Cantao! -- ''' (o o) +--------------oOOO--(_)----------------------+ | Renato F. Cantao! | | Depto. de Matematica Aplicada | | IMECC - UNICAMP | | Sala 215 - Predio da Pos-graduacao - Lado B | +--------------------------OOOo---------------+ |__|__| || || ooO Ooo Linux User #207462 From rguenth at tat.physik.uni-tuebingen.de Tue Sep 3 08:39:00 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 3 Sep 2002 10:39:00 +0200 (CEST) Subject: [pooma-dev] UserFunction question In-Reply-To: <1031004532.2478.31.camel@lei061.lei.ime.unicamp.br> Message-ID: On 2 Sep 2002, Renato Fernandes Cant?o wrote: > Hello Guys! > > I've been dealing with UserFunction, but I have a question: suppose I'm > using a UserFunction to manipulate Array's of big elements, like that: > > inline InnerType_t& operator( const InnerType_t& t ) const > { > p = t * t; // stupid example... > > return p; > } > > private: > InnerType_t p; // initialized in some manner in the constructor > > UserFunction< Operation > F; As you just default construct the user function, the InnerType_t is also default constructed. So in principle the compiler should be able to do return value optimization if you write inline InnerType& operator(const InnerType& t) const { return t*t; } But of course a operator(lhs, rhs) type UserFunction could be implemented, if you can prove the compiler does not do return value optimization properly for expression templates. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From nobbi at theorie3.physik.uni-erlangen.de Tue Sep 3 09:49:30 2002 From: nobbi at theorie3.physik.uni-erlangen.de (Norbert Nemec) Date: Tue, 3 Sep 2002 11:49:30 +0200 Subject: Some special needs for Lattice Gauge Theory Message-ID: <20020903094930.GB31998@theorie3.physik.uni-erlangen.de> Hi there, I'm just starting with my physics diploma which is about numerical lattice gauge theory (some pretty fundamental stuff) So far I have started looking into POOMA as a tool and it seems to fit my needs extremely well. Anyhow, there are a few special things I could not find so far. I'm willing and capable to implement them myself and I'm also willing to contribute to the POOMA project. Still, before I start digging into the matters, I'd like to know whether there already are people who have experience in that field or might even have done some work on it. The things I need are: * 4 dimensional fields in euclidean space-time (I assume that's just gonna be some copy-and-paste work) * extensive use of random-number-generators (RNGComponent fits most of my needs) * some kind of stencils with more than one input field (to allow the use of per-site-RNG within the stencil) Much of the stuff would probably be implementable without any changes to the POOMA sources, but the kind of work I'm preparing for demands some kind of abstraction of different field types (U(1), SU(N), gaugefields, scalar fields, vector fields) and algorithms (Metropolis, and more specialized Monte Carlo methods) Any ideas and cooperation are very welcome. I'm pretty serious about investing some time and others will hopefully have some profit from it, too. Ciao, Nobbi -- -- _____________________________________Norbert "Nobbi" Nemec -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany -- eMail: Tel: +49-(0)-9131-204180 From rguenth at tat.physik.uni-tuebingen.de Tue Sep 3 10:00:11 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 3 Sep 2002 12:00:11 +0200 (CEST) Subject: [pooma-dev] Some special needs for Lattice Gauge Theory In-Reply-To: <20020903094930.GB31998@theorie3.physik.uni-erlangen.de> Message-ID: On Tue, 3 Sep 2002, Norbert Nemec wrote: > Hi there, > > I'm just starting with my physics diploma which is about numerical > lattice gauge theory (some pretty fundamental stuff) > > So far I have started looking into POOMA as a tool and it seems to fit > my needs extremely well. Anyhow, there are a few special things I could > not find so far. I'm willing and capable to implement them myself and > I'm also willing to contribute to the POOMA project. Still, before I > start digging into the matters, I'd like to know whether there already > are people who have experience in that field or might even have done > some work on it. > > The things I need are: > * 4 dimensional fields in euclidean space-time (I assume that's just gonna > be some copy-and-paste work) This should be supported by POOMA already. > * extensive use of random-number-generators (RNGComponent fits most of my needs) Didnt look into the RNGComponent class yet. > * some kind of stencils with more than one input field (to allow the use of > per-site-RNG within the stencil) You mean a stencil that has an operator() like A& operator()(const B&, const C&) const; this would be useful for me, too. It seems the FieldStencil(Simple) needs some work - at least in documentation. But multi-input stencils are possible. > Much of the stuff would probably be implementable without any changes to the > POOMA sources, but the kind of work I'm preparing for demands some kind of abstraction > of different field types (U(1), SU(N), gaugefields, scalar fields, vector fields) and > algorithms (Metropolis, and more specialized Monte Carlo methods) Hmm - can you elaborate more on these "field types"? What fundamental properties do they share/differ in? How would you use them? > Any ideas and cooperation are very welcome. I'm pretty serious about investing some > time and others will hopefully have some profit from it, too. Contributing is very well needed. I'm trying to do this myself, but be prepared to be confronted with some legal issues from the CodeSourcery if you want to contribute. I hope I get positive feedback from our local legal department after I return from vacation. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From nobbi at theorie3.physik.uni-erlangen.de Tue Sep 3 10:31:29 2002 From: nobbi at theorie3.physik.uni-erlangen.de (Norbert Nemec) Date: Tue, 3 Sep 2002 12:31:29 +0200 Subject: [pooma-dev] Some special needs for Lattice Gauge Theory In-Reply-To: References: <20020903094930.GB31998@theorie3.physik.uni-erlangen.de> Message-ID: <20020903103129.GA32520@theorie3.physik.uni-erlangen.de> On Tue, Sep 03, 2002 at 12:00:11PM +0200, Richard Guenther wrote: > On Tue, 3 Sep 2002, Norbert Nemec wrote: > > The things I need are: > > * 4 dimensional fields in euclidean space-time (I assume that's just gonna > > be some copy-and-paste work) > > This should be supported by POOMA already. In 2.4.0, fields are limited to 3 dimensions. Necessary changes are spread over a number of spots in the sources. > > * extensive use of random-number-generators (RNGComponent fits most of my needs) > > Didnt look into the RNGComponent class yet. It is quite straigtforward and simple. Anyhow, there is only one very simple RNG to use. Shouldn't be a problem though to add more elaborate ones. > > * some kind of stencils with more than one input field (to allow the use of > > per-site-RNG within the stencil) > > You mean a stencil that has an operator() like > > A& operator()(const B&, const C&) const; > > this would be useful for me, too. It seems the FieldStencil(Simple) needs > some work - at least in documentation. Well, yes, documentation is somewhat minimalistic in some areas, but that's ok. I have no idea how much time I'm can spend on that. I know that many of my own troubles would have been solved by adequate documentation, but since I'm not a very literate programmer myself I'm not in the position to criticise... > But multi-input stencils are possible. ??? Could you give details on that? What do you mean with "multi-input" if not one with an "A& operator()(const B&, const C&) const;" ? > > > Much of the stuff would probably be implementable without any changes to the > > POOMA sources, but the kind of work I'm preparing for demands some kind of abstraction > > of different field types (U(1), SU(N), gaugefields, scalar fields, vector fields) and > > algorithms (Metropolis, and more specialized Monte Carlo methods) > > Hmm - can you elaborate more on these "field types"? What fundamental > properties do they share/differ in? How would you use them? Well, in general I'm focusing on Monte-Carlo simulations. I'm pretty new to that area myself, so my ideas are still somewhat vague. Anyhow, there are several kinds of particle fields (real, complex, scalar, multi-component, and so on) as well as their gauge fields. Some having several ways for discretization. On the other hand, there are several methods for Monte Carlo simulation (Metropolis, Langevin, Molecular Dynamics and hybrid types) I still have some way to go before I understand all the details, and especially how they can be implemented and how their common properties can be pulled together and abstracted. There is a long way to go, but I know it will be more revarding to go that way instead of implementing each combination from scratch... > > Any ideas and cooperation are very welcome. I'm pretty serious about investing some > > time and others will hopefully have some profit from it, too. > > Contributing is very well needed. I'm trying to do this myself, but be > prepared to be confronted with some legal issues from the CodeSourcery if > you want to contribute. I hope I get positive feedback from our local > legal department after I return from vacation. Thanks for the hint. Haven't sent much thought on that, yet, but I guess, it might be a good idea... Ciao, Nobbi -- -- _____________________________________Norbert "Nobbi" Nemec -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany -- eMail: Tel: +49-(0)-9131-204180 From rguenth at tat.physik.uni-tuebingen.de Tue Sep 3 10:58:30 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Tue, 3 Sep 2002 12:58:30 +0200 (CEST) Subject: [pooma-dev] Some special needs for Lattice Gauge Theory In-Reply-To: <20020903103129.GA32520@theorie3.physik.uni-erlangen.de> Message-ID: On Tue, 3 Sep 2002, Norbert Nemec wrote: > On Tue, Sep 03, 2002 at 12:00:11PM +0200, Richard Guenther wrote: > > On Tue, 3 Sep 2002, Norbert Nemec wrote: > > > The things I need are: > > > * 4 dimensional fields in euclidean space-time (I assume that's just gonna > > > be some copy-and-paste work) > > > > This should be supported by POOMA already. > > In 2.4.0, fields are limited to 3 dimensions. Necessary changes are spread over > a number of spots in the sources. Oh - didnt notice that. But its probably only missing 4 argument methods and classes for the views, the engines seem to support up to 7d. And maybe 4d centering support. > > > * some kind of stencils with more than one input field (to allow the use of > > > per-site-RNG within the stencil) > > > > You mean a stencil that has an operator() like > > > > A& operator()(const B&, const C&) const; > > > > this would be useful for me, too. It seems the FieldStencil(Simple) needs > > some work - at least in documentation. > > Well, yes, documentation is somewhat minimalistic in some areas, but that's ok. > I have no idea how much time I'm can spend on that. I know that many of my own troubles > would have been solved by adequate documentation, but since I'm not a very literate > programmer myself I'm not in the position to criticise... > > > But multi-input stencils are possible. > > ??? Could you give details on that? What do you mean with "multi-input" if not one > with an "A& operator()(const B&, const C&) const;" ? I just meant it is certainly possible to implement multi-input stencils (like the prototype above) - they're not supported at the moment, though. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From nobbi at theorie3.physik.uni-erlangen.de Tue Sep 3 15:02:06 2002 From: nobbi at theorie3.physik.uni-erlangen.de (Norbert Nemec) Date: Tue, 3 Sep 2002 17:02:06 +0200 Subject: Cooperation between FieldStencil and Range? Message-ID: <20020903150206.GA2112@theorie3.physik.uni-erlangen.de> Hi there, it seems like FieldStencil does not work together with Range domains? Is there a deep reason to that? I tried to look into the matter, but the problem definitely seems to be more than just a few specializations missing. The whole Engine > has Interval hardcoded. I need to do red-black updates on a field using a FieldStencil and I really have no idea how I should do that now. Ciao, Nobbi -- -- _____________________________________Norbert "Nobbi" Nemec -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany -- eMail: Tel: +49-(0)-9131-204180 From jcrotinger at proximation.com Tue Sep 3 15:14:15 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Tue, 3 Sep 2002 09:14:15 -0600 Subject: [pooma-dev] Cooperation between FieldStencil and Range? Message-ID: The problem is that one can not, in general, deduce geometry information on a red-black type subgrid from the information on the underlying grid. Thus only Interval views of a Field yield a Field with geometry information. RB type calculations can be done on arrays, so you might want to change some of the calculations to be array-centric. Jim > -----Original Message----- > From: Norbert Nemec [mailto:nobbi at theorie3.physik.uni-erlangen.de] > Sent: Tuesday, September 03, 2002 9:02 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] Cooperation between FieldStencil and Range? > > > Hi there, > > it seems like FieldStencil does not work together with > Range domains? Is there a deep reason to that? I tried to > look into the matter, but the problem definitely seems to be > more than just a few specializations missing. The whole > Engine > has > Interval hardcoded. > > I need to do red-black updates on a field using a > FieldStencil and I really have no idea how I should do that now. > > Ciao, > Nobbi > > -- > -- _____________________________________Norbert "Nobbi" Nemec > -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany > -- eMail: Tel: +49-(0)-9131-204180 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephens at proximation.com Tue Sep 3 15:25:36 2002 From: stephens at proximation.com (Stephen Smith) Date: Tue, 3 Sep 2002 09:25:36 -0600 Subject: [pooma-dev] UserFunction question Message-ID: Actually, no. The expression below will be evaluated with a loop: for(i = ... Big2(i) = F.operator()(Big1(i)); UserFunction was create to work within expressions efficiently. As the other response pointed out, it's more efficient to just return the result: inline InnerType_t& operator( const InnerType_t& t ) const { return t * t; } (You can have local data in the functor, but it might not do what you want in parallel. If the arrays are multipatch, then each piece of the expression has its own copy of the user's functor object.) Stephen -----Original Message----- From: Renato Fernandes Cant?o [mailto:cantao at ime.unicamp.br] Sent: Monday, September 02, 2002 4:09 PM To: Pooma Dev List Subject: [pooma-dev] UserFunction question Big2 = F( Big1 ); } F runs through Big1, applies Operation.operator() in each Big1( i ) -- 2D Array's with 10000 elements each -- and finally *copies* the result to Big2( i ). Correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobbi at theorie3.physik.uni-erlangen.de Tue Sep 3 15:46:07 2002 From: nobbi at theorie3.physik.uni-erlangen.de (Norbert Nemec) Date: Tue, 3 Sep 2002 17:46:07 +0200 Subject: [pooma-dev] Cooperation between FieldStencil and Range? In-Reply-To: ; from jcrotinger@proximation.com on Tue, Sep 03, 2002 at 09:14:15AM -0600 References: Message-ID: <20020903174607.A17301@theorie3.physik.uni-erlangen.de> Actually, I would love to forget about the whole "Field" stuff altogether, since I do not need that whole overhead of geometry information. Only reason I switched to field instead of array is that I need periodic boundary conditions and I would really love to use the mechanisms built into field instead of doing all the copying by hand. Why is it, that automatic boundary conditions are not part of Array, even though the concept is completely independant from geometry information? On Tue, Sep 03, 2002 at 09:14:15AM -0600, James Crotinger wrote: > The problem is that one can not, in general, deduce geometry information on > a red-black type subgrid from the information on the underlying grid. Thus > only Interval views of a Field yield a Field with geometry information. RB > type calculations can be done on arrays, so you might want to change some of > the calculations to be array-centric. > > Jim > > > -----Original Message----- > > From: Norbert Nemec [mailto:nobbi at theorie3.physik.uni-erlangen.de] > > Sent: Tuesday, September 03, 2002 9:02 AM > > To: pooma-dev at pooma.codesourcery.com > > Subject: [pooma-dev] Cooperation between FieldStencil and Range? > > > > > > Hi there, > > > > it seems like FieldStencil does not work together with > > Range domains? Is there a deep reason to that? I tried to > > look into the matter, but the problem definitely seems to be > > more than just a few specializations missing. The whole > > Engine > has > > Interval hardcoded. > > > > I need to do red-black updates on a field using a > > FieldStencil and I really have no idea how I should do that now. > > > > Ciao, > > Nobbi > > > > -- > > -- _____________________________________Norbert "Nobbi" Nemec > > -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany > > -- eMail: Tel: +49-(0)-9131-204180 > > -- -- _____________________________________Norbert "Nobbi" Nemec -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany -- eMail: Tel: +49-(0)-9131-204180 From jcrotinger at proximation.com Tue Sep 3 16:09:20 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Tue, 3 Sep 2002 10:09:20 -0600 Subject: [pooma-dev] Cooperation between FieldStencil and Range? Message-ID: We went around and around on adding this sort of functionality to Array. We wanted Array to be as lean and fast as possible, but the functionality is nice to have. I wasn't sure where we ended up. For periodic BCs, one possibility would be to implement a new MP engine that basically handles the boundaries as "internal" guards (which is really what they are in a periodic system). Jim > -----Original Message----- > From: Norbert Nemec [mailto:nobbi at theorie3.physik.uni-erlangen.de] > Sent: Tuesday, September 03, 2002 9:46 AM > To: 'pooma-dev at pooma.codesourcery.com' > Subject: Re: [pooma-dev] Cooperation between FieldStencil and Range? > > > Actually, I would love to forget about the whole "Field" > stuff altogether, since I do not need that whole overhead of > geometry information. > > Only reason I switched to field instead of array is that I > need periodic boundary conditions and I would really love to > use the mechanisms built into field instead of doing all the > copying by hand. > > Why is it, that automatic boundary conditions are not part of > Array, even though the concept is completely independant from > geometry information? > > > On Tue, Sep 03, 2002 at 09:14:15AM -0600, James Crotinger wrote: > > The problem is that one can not, in general, deduce geometry > > information on a red-black type subgrid from the information on the > > underlying grid. Thus only Interval views of a Field yield a Field > > with geometry information. RB type calculations can be done > on arrays, > > so you might want to change some of the calculations to be > > array-centric. > > > > Jim > > > > > -----Original Message----- > > > From: Norbert Nemec [mailto:nobbi at theorie3.physik.uni-erlangen.de] > > > Sent: Tuesday, September 03, 2002 9:02 AM > > > To: pooma-dev at pooma.codesourcery.com > > > Subject: [pooma-dev] Cooperation between FieldStencil and Range? > > > > > > > > > Hi there, > > > > > > it seems like FieldStencil does not work together with > > > Range domains? Is there a deep reason to that? I tried to > > > look into the matter, but the problem definitely seems to be > > > more than just a few specializations missing. The whole > > > Engine > has > > > Interval hardcoded. > > > > > > I need to do red-black updates on a field using a > > > FieldStencil and I really have no idea how I should do that now. > > > > > > Ciao, > > > Nobbi > > > > > > -- > > > -- _____________________________________Norbert "Nobbi" Nemec > > > -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany > > > -- eMail: Tel: +49-(0)-9131-204180 > > > > > -- > -- _____________________________________Norbert "Nobbi" Nemec > -- Hindenburgstr. 44 ... D-91054 Erlangen ... Germany > -- eMail: Tel: +49-(0)-9131-204180 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cantao at ime.unicamp.br Tue Sep 3 19:45:23 2002 From: cantao at ime.unicamp.br (Renato Fernandes =?ISO-8859-1?Q?Cant=E3o?=) Date: 03 Sep 2002 16:45:23 -0300 Subject: UserFunction yet... Message-ID: <1031082323.7394.25.camel@lei061.lei.ime.unicamp.br> Hello Guys! Ok, I think I've got the point with UserFunction. So, I tried to write my stuff in a way that I could return just references to something being calculated, so the expression template machinery could take care of it, as pointed out by Richard and Stephen. The underlying structure I'm working with is Array< 1, Array< 2, Vector< 2 > > > It's a long list of 2D points stored in a 2D Array (it really makes sense to me :). I'm trying something: struct SmallOperation { // makes some operation on Vector<2> inline const Vector< 2 >& operator()( const Vector< 2 >& in ) const { return in / norm( in ); } }; struct BigOperation { // here I want to be able to address each Vector<2> using // the above SmallOperation inline Array< 2, Vector< 2 > > // no reference here yet... operator()( const Array< 2, Vector< 2 > >& in ) const { return UserFunction< SmallOperation >()( in ); } }; In the MAIN program... UserFunction< BigOperation > F; Array< 1, Array< 2, Vector< 2 > > > V( 10 ); for( int ii = 0; ii < 10; ii++ ) { V( ii ).initialize( 3, 3 ); V( ii ) = Vector< 2 >( 1.0, 2.0 ); // stupid initial value } cout << V << endl; cout << F( V ) << endl; What I expected to happen is: F will be applied to each V element (Array<2,...>), calling BigOperation::operator( ... ), that calls SmallOperation::operator( ... ). But, it simply does not compile, complaining it's impossible to convert Array<2, Vector<2>, UserFunctionEngine<...> > to Array<2, Vector<2>, Brick> Strangely, if I change BigOperation::operator( ... ) to inline Array< 2, Vector< 2 > > operator()( const Array< 2, Vector< 2 > >& in ) const { Array< 2, Vector< 2 > > out( in.domain() ); out = F( in ); return out; } everything works fine, BUT, I still have to make a copy... The question is: 1. Some constructor is missing? 2. There is some obscure traits class that fix it all? 3. It's really impossible inside Pooma's expression engine? Thanks a lot, Cantao! -- ''' (o o) +--------------oOOO--(_)----------------------+ | Renato F. Cantao! | | Depto. de Matematica Aplicada | | IMECC - UNICAMP | | Sala 215 - Predio da Pos-graduacao - Lado B | +--------------------------OOOo---------------+ |__|__| || || ooO Ooo Linux User #207462 From oldham at codesourcery.com Tue Sep 3 20:31:49 2002 From: oldham at codesourcery.com (Jeffrey Oldham) Date: Tue, 3 Sep 2002 13:31:49 -0700 Subject: [pooma-dev] UserFunction yet... In-Reply-To: <1031082323.7394.25.camel@lei061.lei.ime.unicamp.br>; from cantao@ime.unicamp.br on Tue, Sep 03, 2002 at 04:45:23PM -0300 References: <1031082323.7394.25.camel@lei061.lei.ime.unicamp.br> Message-ID: <20020903133149.A25330@codesourcery.com> On Tue, Sep 03, 2002 at 04:45:23PM -0300, Renato Fernandes Cant?o wrote: > > struct BigOperation > { > // here I want to be able to address each Vector<2> using > // the above SmallOperation > > inline Array< 2, Vector< 2 > > // no reference here yet... > operator()( const Array< 2, Vector< 2 > >& in ) const > { > return UserFunction< SmallOperation >()( in ); > } > }; > > > In the MAIN program... > > UserFunction< BigOperation > F; > > Array< 1, Array< 2, Vector< 2 > > > V( 10 ); > > for( int ii = 0; ii < 10; ii++ ) > { > V( ii ).initialize( 3, 3 ); > > V( ii ) = Vector< 2 >( 1.0, 2.0 ); // stupid initial value > } > > cout << V << endl; > cout << F( V ) << endl; > > > What I expected to happen is: F will be applied to each V element > (Array<2,...>), calling BigOperation::operator( ... ), that calls > SmallOperation::operator( ... ). > > But, it simply does not compile, complaining it's impossible to convert > > Array<2, Vector<2>, UserFunctionEngine<...> > > > to > > Array<2, Vector<2>, Brick> > > Strangely, if I change BigOperation::operator( ... ) to > > inline Array< 2, Vector< 2 > > > operator()( const Array< 2, Vector< 2 > >& in ) const > { > Array< 2, Vector< 2 > > out( in.domain() ); > > out = F( in ); > > return out; > } > > everything works fine, BUT, I still have to make a copy... > > The question is: > > 1. Some constructor is missing? > 2. There is some obscure traits class that fix it all? > 3. It's really impossible inside Pooma's expression engine? Because of default template parameters, the return type of BigOperation::operator() is listed as Array< 2, Vector< 2 > > which is equivalent to Array< 2, Vector< 2 >, Brick>. A UserFunction returns a UserFunction engine, not a Brick engine, so the compiler complains. One solution is to make BigOperation::operator()'s engine type explicit: Copy the engine type from the error message: Array< 2, Vector< 2 >, UserFunction< ... > > Perhaps others know better solutions? Thanks, Jeffrey D. Oldham oldham at codesourcery.com From cantao at ime.unicamp.br Tue Sep 3 21:01:22 2002 From: cantao at ime.unicamp.br (Renato Fernandes =?ISO-8859-1?Q?Cant=E3o?=) Date: 03 Sep 2002 18:01:22 -0300 Subject: [pooma-dev] UserFunction yet... In-Reply-To: <20020903133149.A25330@codesourcery.com> References: <1031082323.7394.25.camel@lei061.lei.ime.unicamp.br> <20020903133149.A25330@codesourcery.com> Message-ID: <1031086882.7394.36.camel@lei061.lei.ime.unicamp.br> Hi Jeffrey! Yes, I've tried that too, but it just throws the problem ahead. Applying the change you sugested: typedef UserFunctionEngine< SmallOperation, Array< 2, Vector< 2 > > > UF_Engine_t; struct BigOperation { inline Array< 2, Vector< 2 >, UF_Engine_t > operator()( const Array< 2, Vector< 2 > >& in ) const { ... } }; the problem appears at cout << F( V ) << endl; I'm gonna check the template instantiations of UserFunction to see if I figure out what's going on. I guess that some specialization of FunctorResult could help, but I really don't know... Again, thanks a lot, Cantao! > > Because of default template parameters, the return type of > BigOperation::operator() is listed as > > Array< 2, Vector< 2 > > > > which is equivalent to > > Array< 2, Vector< 2 >, Brick>. > > A UserFunction returns a UserFunction engine, not a Brick engine, so > the compiler complains. One solution is to make > BigOperation::operator()'s engine type explicit: Copy the engine type > from the error message: > > Array< 2, Vector< 2 >, UserFunction< ... > > > > Perhaps others know better solutions? > > Thanks, > Jeffrey D. Oldham > oldham at codesourcery.com -- ''' (o o) +--------------oOOO--(_)----------------------+ | Renato F. Cantao! | | Depto. de Matematica Aplicada | | IMECC - UNICAMP | | Sala 215 - Predio da Pos-graduacao - Lado B | +--------------------------OOOo---------------+ |__|__| || || ooO Ooo Linux User #207462 From rguenth at tat.physik.uni-tuebingen.de Wed Sep 4 13:32:43 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 4 Sep 2002 15:32:43 +0200 (CEST) Subject: [RFC] Infrastructure Message-ID: Hi! I think we need some more infrastructure (from CodeSourcery) for POOMA development and support. Few things come into my mind that are essentially: - a bugtracker Other things may be useful as of the current contribution policy: - a wiki (mainly for interactively contributing documentation) - things such like a patch-manager or a feature request tracker, but those can maybe unified with the bugtracker - pooma-user/pooma-cvs/pooma-patches mailinglists I think CodeSourcery needs to address some of these to make development easier. Maybe POOMA could move to some open source hosting site such as SourceForge (but then POOMA is not OpenSource), BerliOS (a SF clone), or others? Now well, I'm off for vacation the next two-and-a-half weeks. Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From rguenth at tat.physik.uni-tuebingen.de Wed Sep 25 09:50:36 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Wed, 25 Sep 2002 11:50:36 +0200 (CEST) Subject: Assigning to internal guards Message-ID: Hi! I'd like to have internal guards computated rather than communicated in simple cases like x.all() = 1.0; or even x(I) = a(I) + b(I); so after the operation a x.fillGuards() will do nothing (is this equivalent to having the dirty flag cleared after the operation or is the dirty flag overloaded as I think with the handling of relations?). I can achieve at least the assignment by creating a special layout for x which contains overlapping patches with no guards, but I get extra communication of guards at other places then which I dont really understand. The layout is created using a custom partition based on grid partition OGridPartition<1>: blocks_m = [4] internalGuards_m: upper 1 lower 1 num_m = 4 grid_m = (empty) the resulting layout is GridLayout 1 on global domain [-1:65:1]: Total subdomains: 4 Local subdomains: 2 Remote subdomains: 2 Grid blocks: [4] Global subdomain = {[-1:16:1]: allocated=[-1:16:1], con=0, aff=0, gid=0, lid=0} Global subdomain = {[15:32:1]: allocated=[15:32:1], con=0, aff=0, gid=1, lid=1} Global subdomain = {[31:48:1]: allocated=[31:48:1], con=1, aff=-1, gid=2, lid=-1} Global subdomain = {[47:65:1]: allocated=[47:65:1], con=1, aff=-1, gid=3, lid=-1} Local subdomain = {[-1:16:1]: allocated=[-1:16:1], con=0, aff=0, gid=0, lid=0} Local subdomain = {[15:32:1]: allocated=[15:32:1], con=0, aff=0, gid=1, lid=1} Remote subdomain = {[31:48:1]: allocated=[31:48:1], con=1, aff=-1, gid=2, lid=-1} Remote subdomain = {[47:65:1]: allocated=[47:65:1], con=1, aff=-1, gid=3, lid=-1} hasInternalGuards_m, hasExternalGuards_m 0 0 internalGuards_m 0-0 externalGuards_m 0-0 gcFillList_m Anyone with other/better ideas to reduce communication? I'm still unable to find where the computation domain for the patches is computed and the dirty flag is handled - it semms to be spread over the whole code... Any hints? Thanks, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From jcrotinger at proximation.com Wed Sep 25 16:29:35 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Wed, 25 Sep 2002 10:29:35 -0600 Subject: [pooma-dev] Assigning to internal guards Message-ID: We considered this and it was on the list of things to work on someday. If I remember correctly, we were going to try to figure out if the layouts all matched, including the numbers of internal guards, and if so, generate patch iterates that performed the operations on the entire domains, not just the physical domains. We already figure out if the layouts match at the physical-domain basis, I believe, so this didn't sound like a big extension. Indeed, the simplest form of this would be to check that everyone has exactly the same layout. Of course, in multiple dimensions you generally don't want internal guards on anything that you're not going to stencil, so in practice it isn't clear how often this practice will really pay off. (Internal guards can consume a lot of memory in 3D.) Jim -----Original Message----- From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] Sent: Wednesday, September 25, 2002 3:51 AM To: pooma-dev at pooma.codesourcery.com Subject: [pooma-dev] Assigning to internal guards Hi! I'd like to have internal guards computated rather than communicated in simple cases like x.all() = 1.0; or even x(I) = a(I) + b(I); so after the operation a x.fillGuards() will do nothing (is this equivalent to having the dirty flag cleared after the operation or is the dirty flag overloaded as I think with the handling of relations?). I can achieve at least the assignment by creating a special layout for x which contains overlapping patches with no guards, but I get extra communication of guards at other places then which I dont really understand. The layout is created using a custom partition based on grid partition OGridPartition<1>: blocks_m = [4] internalGuards_m: upper 1 lower 1 num_m = 4 grid_m = (empty) the resulting layout is GridLayout 1 on global domain [-1:65:1]: Total subdomains: 4 Local subdomains: 2 Remote subdomains: 2 Grid blocks: [4] Global subdomain = {[-1:16:1]: allocated=[-1:16:1], con=0, aff=0, gid=0, lid=0} Global subdomain = {[15:32:1]: allocated=[15:32:1], con=0, aff=0, gid=1, lid=1} Global subdomain = {[31:48:1]: allocated=[31:48:1], con=1, aff=-1, gid=2, lid=-1} Global subdomain = {[47:65:1]: allocated=[47:65:1], con=1, aff=-1, gid=3, lid=-1} Local subdomain = {[-1:16:1]: allocated=[-1:16:1], con=0, aff=0, gid=0, lid=0} Local subdomain = {[15:32:1]: allocated=[15:32:1], con=0, aff=0, gid=1, lid=1} Remote subdomain = {[31:48:1]: allocated=[31:48:1], con=1, aff=-1, gid=2, lid=-1} Remote subdomain = {[47:65:1]: allocated=[47:65:1], con=1, aff=-1, gid=3, lid=-1} hasInternalGuards_m, hasExternalGuards_m 0 0 internalGuards_m 0-0 externalGuards_m 0-0 gcFillList_m Anyone with other/better ideas to reduce communication? I'm still unable to find where the computation domain for the patches is computed and the dirty flag is handled - it semms to be spread over the whole code... Any hints? Thanks, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jxyh at lanl.gov Wed Sep 25 17:23:30 2002 From: jxyh at lanl.gov (John H. Hall) Date: Wed, 25 Sep 2002 11:23:30 -0600 Subject: [pooma-dev] Assigning to internal guards In-Reply-To: Message-ID: <82CA6D23-D0AB-11D6-923F-000A27AF286E@lanl.gov> > > Of course, in multiple dimensions you generally don't want internal > guards on anything that you're not going to stencil, so in practice it > isn't clear how often this practice will really pay off. (Internal > guards can consume a lot of memory in 3D.) > > ??????? Jim Jim, et. al.: In practice, this (calculating internal/external guard cells instead of communicating) would be one of the biggest optimizations possible. Especially when you introduce the concept of dependent and independent fields. Usually only the independent fields need to communicate to fill their guard cells. The dependent fields can just calculate their guards and move on as pretty as you please. Because of the limitations on scalar coding right now, once you start using guard cells, pretty much every field ends up requiring them also (this has to do with alignment issues and all patches starting their coordinate indexing at (0,0,0)). The devil is of course in the details, but, you can't generally get away with mixing and matching fields with and without guard cells right now except in the simple case of all SIMD syntax (which of course is what you were referring to). I've got the GCC work back online. Mark's contract is extended through next year. Hopefully, we can soon get back to thinking about these other exciting issues. Regards, John -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1396 bytes Desc: not available URL: From mhelal at aucegypt.edu Wed Sep 25 18:06:23 2002 From: mhelal at aucegypt.edu (Manal E. Helal) Date: Wed, 25 Sep 2002 20:06:23 +0200 Subject: POOMA under Windows environment and MS VC++ Message-ID: <3D91D654@mail.aucegypt.edu> Hello, Can any body help with starting issues: 1. can POOMA work under windows environment as the pooma.pdf file states, 2. if yes, where can I get installation and configuration steps for that, 3. then, does it work with MS VC++ v.6 or any other windows C++ compiler?!! so far I see that it world for unix/linux/... etc environments and only it mentions windows but deosn't details the steps for that, nor the configuration directory "config/arch/" after unzipping the pooma package, contains a file for windows and MS VC++, thanks a lot, Manal From mark at codesourcery.com Wed Sep 25 19:15:25 2002 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 25 Sep 2002 12:15:25 -0700 Subject: [RFC] Infrastructure In-Reply-To: Message-ID: <10440000.1032981325@warlock.codesourcery.com> --On Wednesday, September 04, 2002 03:32:43 PM +0200 Richard Guenther wrote: > Hi! > > I think we need some more infrastructure (from CodeSourcery) for > POOMA development and support. I'd be happy for us to add these kinds of things, but it will probably happen slowly. (At present, we have no POOMA customers; we are simply maintaining the site as best we can.) Jeffrey Oldham is writing a book about POOMA, which will help with some of the documentation issues. I'm not sure when that book will be completed; it's Jeffrey's personal project. Let's make a list of top priorities, and see what we can do to address them. -- Mark Mitchell mark at codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From cummings at linkline.com Thu Sep 26 17:32:50 2002 From: cummings at linkline.com (Julian C. Cummings) Date: Thu, 26 Sep 2002 10:32:50 -0700 Subject: [pooma-dev] POOMA under Windows environment and MS VC++ In-Reply-To: <3D91D654@mail.aucegypt.edu> Message-ID: Hi Manal, Within the ide subdirectory of the POOMA source tree is a VisualC++ directory with VC++ 6.0 workspace and project files for building the Pooma library and the test and example codes. I am not sure that these files were completely updated between the Pooma 2.3 and 2.4 releases, so some project files may require updating. However, the VC++ 6.0 compiler did not have the necessary compliance with the ANSI/ISO C++ standard to compile Pooma code. Therefore, we had been using the Intel VTune C++ compiler within the VC++ IDE as our compiler. In the src/arch/Intel subdirectory, you will see a PoomaConfiguration.h file provided for use with the Intel C++ compiler. You don't need to run a configuration script to produce this file. If you have the Intel C++ compiler, you can select this compiler within the VC++ IDE, load the VisualC++ workspace files for the Pooma library and test codes, and build them straightforwardly using the VC++ IDE. If you don't have the Intel C++ compiler, another Windows option is to use the CodeWarrior compiler from Metrowerks. There are ide files for this compiler available as well. I am currently participating in beta testing of the upcoming MS Visual Studio .NET compilers. The version of VC++ in this package appears to have the necessary ANSI/ISO C++ standard compliance required for Pooma. I plan to make available an updated set of VisualC++ ide files for Pooma 2.4 and this new compiler when the compiler is released (later this year?). So that is the current Windows status. Regards, Julian C. Dr. Julian C. Cummings Staff Scientist, CACR/Caltech (626) 395-2543 cummings at cacr.caltech.edu > -----Original Message----- > From: Manal E. Helal [mailto:mhelal at aucegypt.edu] > Sent: Wednesday, September 25, 2002 11:06 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] POOMA under Windows environment and MS VC++ > > > Hello, > > Can any body help with starting issues: > > 1. can POOMA work under windows environment as the pooma.pdf file states, > 2. if yes, where can I get installation and configuration steps for that, > 3. then, does it work with MS VC++ v.6 or any other windows C++ > compiler?!! > > so far I see that it world for unix/linux/... etc environments > and only it > mentions windows but deosn't details the steps for that, nor the > configuration directory "config/arch/" after unzipping the pooma package, > contains a file for windows and MS VC++, > > thanks a lot, > > Manal > > From jcrotinger at proximation.com Thu Sep 26 19:49:15 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Thu, 26 Sep 2002 13:49:15 -0600 Subject: [pooma-dev] POOMA under Windows environment and MS VC++ Message-ID: Right. It should be mentioned, however, that it is unclear if any of these Win32 compilers do sufficient inlining for production-level code. We used VTune along with CodeWarrior to ease development, but they didn't used to be good enough to optimize away all the garbage and make the expression-templates work efficiently. Jim -----Original Message----- From: Julian C. Cummings [mailto:cummings at linkline.com] Sent: Thursday, September 26, 2002 11:33 AM To: Manal E. Helal; pooma-dev at pooma.codesourcery.com Subject: RE: [pooma-dev] POOMA under Windows environment and MS VC++ Hi Manal, Within the ide subdirectory of the POOMA source tree is a VisualC++ directory with VC++ 6.0 workspace and project files for building the Pooma library and the test and example codes. I am not sure that these files were completely updated between the Pooma 2.3 and 2.4 releases, so some project files may require updating. However, the VC++ 6.0 compiler did not have the necessary compliance with the ANSI/ISO C++ standard to compile Pooma code. Therefore, we had been using the Intel VTune C++ compiler within the VC++ IDE as our compiler. In the src/arch/Intel subdirectory, you will see a PoomaConfiguration.h file provided for use with the Intel C++ compiler. You don't need to run a configuration script to produce this file. If you have the Intel C++ compiler, you can select this compiler within the VC++ IDE, load the VisualC++ workspace files for the Pooma library and test codes, and build them straightforwardly using the VC++ IDE. If you don't have the Intel C++ compiler, another Windows option is to use the CodeWarrior compiler from Metrowerks. There are ide files for this compiler available as well. I am currently participating in beta testing of the upcoming MS Visual Studio .NET compilers. The version of VC++ in this package appears to have the necessary ANSI/ISO C++ standard compliance required for Pooma. I plan to make available an updated set of VisualC++ ide files for Pooma 2.4 and this new compiler when the compiler is released (later this year?). So that is the current Windows status. Regards, Julian C. Dr. Julian C. Cummings Staff Scientist, CACR/Caltech (626) 395-2543 cummings at cacr.caltech.edu > -----Original Message----- > From: Manal E. Helal [mailto:mhelal at aucegypt.edu] > Sent: Wednesday, September 25, 2002 11:06 AM > To: pooma-dev at pooma.codesourcery.com > Subject: [pooma-dev] POOMA under Windows environment and MS VC++ > > > Hello, > > Can any body help with starting issues: > > 1. can POOMA work under windows environment as the pooma.pdf file states, > 2. if yes, where can I get installation and configuration steps for that, > 3. then, does it work with MS VC++ v.6 or any other windows C++ > compiler?!! > > so far I see that it world for unix/linux/... etc environments > and only it > mentions windows but deosn't details the steps for that, nor the > configuration directory "config/arch/" after unzipping the pooma package, > contains a file for windows and MS VC++, > > thanks a lot, > > Manal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rguenth at tat.physik.uni-tuebingen.de Fri Sep 27 19:57:25 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 27 Sep 2002 21:57:25 +0200 (CEST) Subject: [pooma-dev] Assigning to internal guards Message-ID: On Wed, 25 Sep 2002, James Crotinger wrote: > We considered this and it was on the list of things to work on someday. If I > remember correctly, we were going to try to figure out if the layouts all > matched, including the numbers of internal guards, and if so, generate patch > iterates that performed the operations on the entire domains, not just the > physical domains. We already figure out if the layouts match at the > physical-domain basis, I believe, so this didn't sound like a big extension. > Indeed, the simplest form of this would be to check that everyone has > exactly the same layout. > > Of course, in multiple dimensions you generally don't want internal guards > on anything that you're not going to stencil, so in practice it isn't clear > how often this practice will really pay off. (Internal guards can consume a > lot of memory in 3D.) We encounter this mainly with using temporaries (to do CSE). So f.i. temp(I) = a(I) + b(I); c(I) = temp(I-1) + temp(I+1); or when using in-place stencils which need a temporary, too, like temp(I) = a(I) + b(I); a(I) = temp(I-1) + temp(I+1); Oh - and this happens quite often so that for our local testing cluster 3d simulations are unusable without this optimization (maybe a SCore bug with extreme load, too, though). Do you have any starting hints where to look at to implement what you suggested? I.e. where is the layout matching done (f.e. for a multipatch engine)? Thanks, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From rguenth at tat.physik.uni-tuebingen.de Fri Sep 27 19:57:46 2002 From: rguenth at tat.physik.uni-tuebingen.de (Richard Guenther) Date: Fri, 27 Sep 2002 21:57:46 +0200 (CEST) Subject: [pooma-dev] Assigning to internal guards Message-ID: On Wed, 25 Sep 2002, John H. Hall wrote: > I've got the GCC work back online. Mark's contract is extended through > next year. Hopefully, we can soon get back to thinking about these > other exciting issues. As you speak of GCC - is someone currently working on leightweight object optimizations KAI CC was so good at? Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ From jcrotinger at proximation.com Fri Sep 27 20:12:06 2002 From: jcrotinger at proximation.com (James Crotinger) Date: Fri, 27 Sep 2002 14:12:06 -0600 Subject: [pooma-dev] Assigning to internal guards Message-ID: A good starting point would be Engine/Intersector.h. You might want to step through the MultiPatch evaluation to see how this all flows. I think it currently just bails out of the process of accumulating intersected patches if its already seem the same layout ID (not the same layout - we want this bail-out even if different layouts have differing numbers of internal guards). I think you'll have to change this by building a new PETE functor that just gets you the layout reference (this may already exist) and then you'll have to do a ForEach that checks if all layouts have the same address. Hmmm. Layouts have shallow copy semantics, so what you'd really like is an operator== on layouts that just compared object identity. I'm not sure if that is there. Anyway, if all the layouts are the same, then you'd want to generate a list of patches that was the total-domain of each underlying patch. If any layout was different, then you'd have to branch to the existing intersector code. Doesn't really sound all that hard. You probably want to protect the new code with a configuration flag and maybe even a runtime flag to allow comparisons. In your example: temp(I) = a(I) + b(I); c(I) = temp(I-1) + temp(I+1); you should also compare with doing a and b with no guards, which they don't need in this expression. If your stuff is 1D, the memory is probably not an issue, but in multiple dimensions it can be a big problem - when the difference is "runs, but communicates a lot" and "doesn't run because it won't fit into memory", people tend to choose the first. :) Jim -----Original Message----- From: Richard Guenther [mailto:rguenth at tat.physik.uni-tuebingen.de] Sent: Friday, September 27, 2002 1:57 PM To: James Crotinger Cc: pooma-dev at pooma.codesourcery.com Subject: RE: [pooma-dev] Assigning to internal guards On Wed, 25 Sep 2002, James Crotinger wrote: > We considered this and it was on the list of things to work on someday. If I > remember correctly, we were going to try to figure out if the layouts all > matched, including the numbers of internal guards, and if so, generate patch > iterates that performed the operations on the entire domains, not just the > physical domains. We already figure out if the layouts match at the > physical-domain basis, I believe, so this didn't sound like a big extension. > Indeed, the simplest form of this would be to check that everyone has > exactly the same layout. > > Of course, in multiple dimensions you generally don't want internal guards > on anything that you're not going to stencil, so in practice it isn't clear > how often this practice will really pay off. (Internal guards can consume a > lot of memory in 3D.) We encounter this mainly with using temporaries (to do CSE). So f.i. temp(I) = a(I) + b(I); c(I) = temp(I-1) + temp(I+1); or when using in-place stencils which need a temporary, too, like temp(I) = a(I) + b(I); a(I) = temp(I-1) + temp(I+1); Oh - and this happens quite often so that for our local testing cluster 3d simulations are unusable without this optimization (maybe a SCore bug with extreme load, too, though). Do you have any starting hints where to look at to implement what you suggested? I.e. where is the layout matching done (f.e. for a multipatch engine)? Thanks, Richard. -- Richard Guenther WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cantao at ime.unicamp.br Fri Sep 27 21:17:26 2002 From: cantao at ime.unicamp.br (Renato F. Cantao) Date: Fri, 27 Sep 2002 18:17:26 -0300 (EST) Subject: [pooma-dev] POOMA under Windows environment and MS VC++ In-Reply-To: Message-ID: Hi! Anyone tried GCC on Windows? There's a project called DJGPP that is a port of GCC to the DOS/Windows environmente. It comes with all GNU tools, like make, bison, emacs, etc... It's on version 3.1 and can be found at: http://www.delorie.com For those working with Pooma on Windows it worth a look! []'s, Cantao! On Thu, 26 Sep 2002, James Crotinger wrote: > Right. It should be mentioned, however, that it is unclear if any of these > Win32 compilers do sufficient inlining for production-level code. We used > VTune along with CodeWarrior to ease development, but they didn't used to be > good enough to optimize away all the garbage and make the > expression-templates work efficiently. > > Jim > > -----Original Message----- > From: Julian C. Cummings [mailto:cummings at linkline.com] > Sent: Thursday, September 26, 2002 11:33 AM > To: Manal E. Helal; pooma-dev at pooma.codesourcery.com > Subject: RE: [pooma-dev] POOMA under Windows environment and MS VC++ > > Hi Manal, > > Within the ide subdirectory of the POOMA source tree is > a VisualC++ directory with VC++ 6.0 workspace and project > files for building the Pooma library and the test and > example codes. I am not sure that these files were > completely updated between the Pooma 2.3 and 2.4 releases, > so some project files may require updating. However, the > VC++ 6.0 compiler did not have the necessary compliance > with the ANSI/ISO C++ standard to compile Pooma code. > Therefore, we had been using the Intel VTune C++ compiler > within the VC++ IDE as our compiler. In the src/arch/Intel > subdirectory, you will see a PoomaConfiguration.h file > provided for use with the Intel C++ compiler. You don't > need to run a configuration script to produce this file. > > If you have the Intel C++ compiler, you can select this > compiler within the VC++ IDE, load the VisualC++ workspace > files for the Pooma library and test codes, and build them > straightforwardly using the VC++ IDE. If you don't have > the Intel C++ compiler, another Windows option is to use > the CodeWarrior compiler from Metrowerks. There are ide > files for this compiler available as well. > > I am currently participating in beta testing of the upcoming > MS Visual Studio .NET compilers. The version of VC++ in > this package appears to have the necessary ANSI/ISO C++ > standard compliance required for Pooma. I plan to make > available an updated set of VisualC++ ide files for Pooma 2.4 > and this new compiler when the compiler is released (later > this year?). So that is the current Windows status. > > Regards, Julian C. > > > Dr. Julian C. Cummings > Staff Scientist, CACR/Caltech > (626) 395-2543 > cummings at cacr.caltech.edu > > > > -----Original Message----- > > From: Manal E. Helal [mailto:mhelal at aucegypt.edu] > > Sent: Wednesday, September 25, 2002 11:06 AM > > To: pooma-dev at pooma.codesourcery.com > > Subject: [pooma-dev] POOMA under Windows environment and MS VC++ > > > > > > Hello, > > > > Can any body help with starting issues: > > > > 1. can POOMA work under windows environment as the pooma.pdf file states, > > 2. if yes, where can I get installation and configuration steps for that, > > 3. then, does it work with MS VC++ v.6 or any other windows C++ > > compiler?!! > > > > so far I see that it world for unix/linux/... etc environments > > and only it > > mentions windows but deosn't details the steps for that, nor the > > configuration directory "config/arch/" after unzipping the pooma package, > > contains a file for windows and MS VC++, > > > > thanks a lot, > > > > Manal > > > > > ''' (o o) +--------------oOOO--(_)----------------------+ | Renato F. Cantao! | | Depto. de Matematica Aplicada | | IMECC - UNICAMP | | Sala 215 - Predio da Pos-graduacao - Lado B | +--------------------------OOOo---------------+ |__|__| || || ooO Ooo Linux User #207462 From jxyh at lanl.gov Sat Sep 28 19:49:32 2002 From: jxyh at lanl.gov (John H. Hall) Date: Sat, 28 Sep 2002 13:49:32 -0600 Subject: [pooma-dev] Assigning to internal guards In-Reply-To: Message-ID: <68B7393D-D31B-11D6-B179-000A27AF286E@lanl.gov> Richard: KCC patented those optimizations. That is apparently a significant part of the intellectual property Intel wanted from KCC, although apparently not to implement it themselves, but, just to make sure no one had it, as far as I can tell. Maybe I'm getting a little too cynical in my old age. John On Friday, September 27, 2002, at 01:57 PM, Richard Guenther wrote: > On Wed, 25 Sep 2002, John H. Hall wrote: > >> I've got the GCC work back online. Mark's contract is extended through >> next year. Hopefully, we can soon get back to thinking about these >> other exciting issues. > > As you speak of GCC - is someone currently working on leightweight > object > optimizations KAI CC was so good at? > > Richard. > > -- > Richard Guenther > WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ > The GLAME Project: http://www.glame.de/ > >