As part of a shameless advertising move I suggest this patch.
While it won't make autogen.sh exactly fast, for me it shaves
half a minute off its runtime.
Cheers,
Ralf
HACKING: recommend parallel automake 1.11 execution.
Index: HACKING
About performance, I may miss something, but our first goal was to track
already slow pathes.
We imagined that it could be possible to add at the beginning (or end) of
this "bad path" just one line that would basically do an atomic inc. So,
in terms of CPU cycles, something like 1 for the inc
Yes it is - so I'll have to change all the platform files, and alert people
here as they will no longer be backwards compatible with the 1.3 series.
This will cause some bookkeeping headaches, so I do hope the change was
worth something and not just a "tomato" versus "tomahto" issue.
On Tue, May
Hi Jeff, all,
would you mind sharing this patch? We'd like to test our current VT version with
some MPI RMA code :)
Does anyone know of some (small) code/benchmark that uses all available MPI RMA
functionality? As far as I see, IMB only uses fence and put/get/accumulate. No
locks or post/wait/sta
While that is a good way of minimizing the impact of the counter, you still
have to do an "if-then" to check if the counter exceeds the threshold. This
"if-then" also has to get executed every time, and generally consumes more
than a few cycles.
To be clear: it isn't the output that is the concern
I thought an if-then was 1 cycle. I mean, if you don't break the pipeline,
i.e. use likely() or builtin_expect() or something like that to be sure
that the compiler will generate assembly in the right way, it shouldn't be
more than 1 cycle, perhaps less on some architectures like Itanium. But my
It seems that the MPI Extensions commit broke that tarball
(distcheckclean) last night. This shouldn't effect too many people,
but I am working on a solution so hopefully everything is better
tonight.
-- Josh
On May 26, 2009, at 9:53 PM, MPI Team wrote:
ERROR: Command returned a non-zer
On May 27, 2009, at 6:49 AM, Holger Mickler wrote:
would you mind sharing this patch? We'd like to test our current VT
version with
some MPI RMA code :)
No problem-o. I've submitted this patch upstream to Intel as well.
Note that the patch slightly changed between 3.1 and 3.2; this is t
Close, but no banana!
Can you add a semicolon to the end of each? So "<" should be replaced
by "<", etc.
Thanks,
Greg
On May 26, 2009, at 8:45 PM, Ralph Castain wrote:
Guess I had just never seen that format before - thanks for
clarifying!
I committed the revisions to the trunk in r212
Note that this is a trunk change; no need or desire to bring it over
to the v1.3 branch. It's intended to be for v1.5.
FWIW, this type of flag probably should have been --enable to begin
with (not --with), because it's a boolean.
Will this cause significant headaches if the name changes in
One thing to note about this change is that it will break binary
compatibility between 1.3/1.4 and the 1.5/1.6 series (since these
values are #define's, and therefore are resolved at compile time --
not run-time).
While I agree that reducing the memory footprint is a good thing, do
we wan
This all sounds reasonable.
If these are, indeed, on already-slow code paths, I doubt there will
be much of an issue.
If you want to talk about this higher bandwidth, let us know -- I can
setup a Webex call pretty easily.
On May 27, 2009, at 8:21 AM, Sylvain Jeaugey wrote:
I thought an
Hi Jeff,
On Wednesday 27 May 2009 09:28:28 am Jeff Squyres wrote:
> One thing to note about this change is that it will break binary
> compatibility between 1.3/1.4 and the 1.5/1.6 series (since these
> values are #define's, and therefore are resolved at compile time --
> not run-time).
Wait a minu
This should be fixed in r21293.
Sorry about that.
On May 27, 2009, at 9:10 AM, Josh Hursey wrote:
It seems that the MPI Extensions commit broke that tarball
(distcheckclean) last night. This shouldn't effect too many people,
but I am working on a solution so hopefully everything is better
On May 27, 2009, at 9:54 AM, Rainer Keller wrote:
> One thing to note about this change is that it will break binary
> compatibility between 1.3/1.4 and the 1.5/1.6 series (since these
> values are #define's, and therefore are resolved at compile time --
> not run-time).
Where's the break??
M
Done -- thanks!
On May 27, 2009, at 12:11 AM, Ralf Wildenhues wrote:
As part of a shameless advertising move I suggest this patch.
While it won't make autogen.sh exactly fast, for me it shaves
half a minute off its runtime.
Cheers,
Ralf
HACKING: recommend parallel automake 1.11 execution.
In
How about using WSAStringToAddress instead? This function exist on all
versions of Windows, and do exactly what you expect convert a string
to an address.
george.
On May 27, 2009, at 10:32 , shiq...@osl.iu.edu wrote:
Author: shiqing
Date: 2009-05-27 10:32:30 EDT (Wed, 27 May 2009)
New Re
FYI, I moved the opal-sos repo this morning to bitbucket.org:
http://bitbucket.org/jsquyres/opal-sos/overview/
If you already pulled from the old www.open-mpi.org copy, you can just
edit your .hg/hgrc to set the new bitbucket URL and continue pulling /
etc. (no need to get a new checkou
What is a generic threshold? And what is a counter? We have a policy
against such coding standards, and to be honest I would like to stick
to it. The reason is that the PML is a very complex piece of code, and
I would like to keep it as easy to understand as possible. If people
start adding
Ralph,
This patch is not correct. First it adds a significant overhead in
terms of if in the critical path (3 more ifs per char in the output
stream), and second it will generate random segfaults.
The test for the orte_xml_output can be centralized in just one if,
reducing the overhead to
Dear all,
i think i found a bug in the ob1 level, while using a multi-segment frag
on receive side. I found that the unpack function add the offset of the
mca_pml_ob1_frag_hdr_t header in every segment, while only the first one
should have. Is that correct?
That's the very simple correction:
---
You're absolutely right. The patch is already in the trunk (commit
r21300), and will be in the next release.
Thanks,
george.
On May 27, 2009, at 11:55 , Roberto Ammendola wrote:
Dear all,
i think i found a bug in the ob1 level, while using a multi-segment
frag
on receive side. I fou
Does this need to go to v1.3?
On May 27, 2009, at 12:12 PM, wrote:
Author: bosilca
Date: 2009-05-27 12:12:18 EDT (Wed, 27 May 2009)
New Revision: 21300
URL: https://svn.open-mpi.org/trac/ompi/changeset/21300
Log:
Don't add the offset to all segments, only the first one should be
affected.
Never mind, I see CMR #1934.
Is this a critical update?
On May 27, 2009, at 12:29 PM, Jeff Squyres wrote:
Does this need to go to v1.3?
On May 27, 2009, at 12:12 PM, wrote:
Author: bosilca
Date: 2009-05-27 12:12:18 EDT (Wed, 27 May 2009)
New Revision: 21300
URL: https://svn.open-mpi.org/
Depend on how we evaluate the fact that we can deliver wrong (and
truncated) data. From my perspective it is a blocker, and reflected
this on the CMR.
george.
On May 27, 2009, at 12:29 , Jeff Squyres wrote:
Never mind, I see CMR #1934.
Is this a critical update?
On May 27, 2009, at 12
On May 27, 2009, at 12:38 PM, George Bosilca wrote:
Depend on how we evaluate the fact that we can deliver wrong (and
truncated) data. From my perspective it is a blocker, and reflected
this on the CMR.
Correctness, schmorectness... who cares?
;-)
What I meant was: do we need to alert user
I don't think we need to enable the panic mode. This problem only
happens on a *very* limited number of scenarios, basically when the
BTL return a fragment in several iovecs. Few BTLs have this
capability, and even if they have it most of the time they prefer to
avoid it. Moreover, we never
Excellent points; Ralph and I chatted about this on the phone today --
we concur with George.
Bull -- would peruse work for you? I think you mentioned before that
it didn't seem attractive to you. I think George's point is that we
already have lots of hooks in place in the PML -- and they
Per our chat - we can manage it. My concern went to the "why" more than
anything else. The rationale for booleans to be --enable is fine, just not
widely known when I added this option.
On Wed, May 27, 2009 at 7:19 AM, Jeff Squyres wrote:
> Note that this is a trunk change; no need or desire to
I can't find that max hostname constraint in the above commit (probably just
tired eyes). However, note that ORTE doesn't have any hostname length
constraint, so if we are now adding one to the OMPI layer, we have a
problem.
For example, in the ompi_proc_t struct, we simply point it at the ORTE na
First, this is in the code path where mpirun outputs to stdout/stderr.
Hardly a "critical path". :-)
Second, I know about the overwrite problem, but wanted to first see if this
met Greg's needs. If you look, you will see that the overwrite problem has
-always- been there in the code, but we didn't
I think it depends upon what is being monitored. As I understand it, we
could use the peruse link to generate notifications based on the number of
times someone calls "MPI_Send", for example. I concur with George's concerns
about performance in this area and would agree that using the peruse hooks
No there is no such constraint. Rainer's commit only changed the
hardcoded value to another define, which this time can be set by the
user at configure time. However, the default value is exactly the same
as before (for MPI hostnames is set to 256).
george.
On May 27, 2009, at 20:02 , Ra
I think Ralph was asking "where is this value used?"
This particular value is one of the constants defined in mpi.h, and
it's used in some of the public MPI data structures (the length of
some strings returned by MPI to the application).
On May 27, 2009, at 8:40 PM, George Bosilca wrote:
Yep! Thanks!
On Wed, May 27, 2009 at 6:43 PM, Jeff Squyres wrote:
> I think Ralph was asking "where is this value used?"
>
> This particular value is one of the constants defined in mpi.h, and it's
> used in some of the public MPI data structures (the length of some strings
> returned by MPI to
Okay, should be there with r21309...let me know!
Ralph
On Wed, May 27, 2009 at 7:19 AM, Greg Watson wrote:
> Close, but no banana!
> Can you add a semicolon to the end of each? So "<" should be replaced by
> "<", etc.
>
> Thanks,
>
> Greg
>
> On May 26, 2009, at 8:45 PM, Ralph Castain wrote:
>
36 matches
Mail list logo
