Thanks for the information. I didn't quite get what you meant in the
last chapter though, would you mind giving a code example?
What I meant was that since there are known to be some bugs in dynamic
dispatch (without a clear explanation for when one will/will not run into
them), rather than doing this:
class AbstractBase {
proc foo() {
writeln("In AbstractBase.foo()");
}
}
class C: AbstractBase {
proc foo() {
writeln("In C.foo()");
}
}
class D: AbstractBase {
proc foo() {
writeln("In D.foo()");
}
}
proc bar(x: AbstractBase) { x.foo(); }
bar(new C());
bar(new D());
I often do this:
class C {
proc foo() {
writeln("In C.foo()");
}
}
class D {
proc foo() {
writeln("In D.foo()");
}
}
proc bar(x) { x.foo(); }
bar(new C());
bar(new D());
The downside of course is that my bar() is so completely unconstrained
that I have no guarantees that what's sent in will support the foo()
method. The upside is that I avoid dynamic dispatch, thereby avoiding
issues in the implementation and the associated overhead at execution time
(instead, the compiler creates two instances of bar() as in a C++
template).
Checking the STATUS, the two things I found related to dynamic dispatch
are:
- Iterator methods may not obey dynamic dispatch.
- Records passed by ref intent to dynamically dispatched methods do
not work.
So it may very well be that dynamic dispatch would be sufficient for your
use (i.e., I don't want to completely scare people away from it. And
frankly, having more users complain about bugs in it would increase the
chances that someone looked into these issues).
Also would you mind giving a (very) brief explanation about the caching
system used? Or point me to a relevant paper.
I can try, but I'm not sure which caching system you're referring to
(there are a few) -- can you clarify?
Sparse domains currently are only supported for a single locale, and have
not received much attention from a performance tuning point of view. I'd
suggest, at least as a starting point if it's sufficient for your personal
needs, focusing on the dense rectangular block as a starting point.
I've made some attempts to get a block implementation working in which
each local block is a sparse array, but never got it working well enough
to merge it. I can try and dig up that code to share with you if it
becomes useful in a subsequent step.
Okay, I will use dense rectangular domains for now, that will be no
problem... At least not in this specific need.
Also, are the strided domains working well with the block dist? I ask
this because if they don't work well, I might as well get rid of them in
my implementation to make things simpler... However if their support is
good I'd like to conserve that in my implementation.
Yes, strided support is good with Block at present (so far as we are
aware). That said, starting with unstrided first always makes sense from
a simplicity perspective.
-Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
