[hwloc-devel] Create success (hwloc r1.7a1r5235)

2013-01-07 Thread MPI Team 
Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.7a1r5235
Start time: Mon Jan  7 21:01:01 EST 2013
End time:   Mon Jan  7 21:05:10 EST 2013

Your friendly daemon,
Cyrador

Re: [hwloc-devel] v1.7

2013-01-07 Thread Paul Hargrove 
On Mon, Jan 7, 2013 at 11:00 AM, Jeff Squyres (jsquyres)  wrote:

> On Jan 7, 2013, at 1:42 PM, Brice Goglin 
>  wrote:
>
> > My first code did that (with "all" instead of "*" because come shells
> > don't like * :)
>
> Oh, right -- duh!  :-)
>
> > But my testing told me that there were many more cases where we want
> > everything ("all") than nothing else ("stop"), so changed to "nothing
> else".
> > But users are not going to play with the list of components very often
> > anyway, so I think that'd be ok too.
>
>
> Fair enough.
>
> So if you don't know the list of available components, is it not possible
> to specify *only* foo and bar should be used?
>
>

That's where one should use "!", to indicate that we are being emphatic:
   COMPONENTS=!foo,bar
No chance of confusion there, right?


Seriously, I think "COMPONENTS=foo,bar,stop" was the syntax mentioned
earlier in this thread.

-Paul


-- 
Paul H. Hargrove  phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [hwloc-devel] v1.7

2013-01-07 Thread Samuel Thibault 
Jeff Squyres (jsquyres), le Mon 07 Jan 2013 20:01:44 +0100, a écrit :
> So if you don't know the list of available components, is it not possible to 
> specify *only* foo and bar should be used?

foo,bar,stop

will do it.

Samuel

Re: [hwloc-devel] v1.7

2013-01-07 Thread Brice Goglin 
Le 07/01/2013 19:18, Jeff Squyres (jsquyres) a écrit :
> On Jan 7, 2013, at 12:59 PM, Samuel Thibault 
>  wrote:
>
>> Because I may not know *everything* that I want. Who knows what
>> proprietary plugin I need to use to discover CPUs, while I know that for
>> GPUs I can use cuda, but I don't want to use nvml.
>>
>>> Taking your example: HWLOC_COMPONENTS=foo,^bar,^baz,yow
>>> Is the same as:  HWLOC_COMPONENTS=foo,yow
>> No, because there is also the implicit "and the default plugins" after
>> that.
> So you're really saying "not bar and baz, but I do want everything else."
>
> OMPI's intent was to be simple: specify what you want to *exclude* or what 
> you want to *include*, but you'd never do *both*.
>

Another difference with OMPI is that OMPI has many different frameworks
with usually few components in each of them. And OMPI can exclude in
some framework and include in some others.

hwloc doesn't have multiple frameworks (actually, there's another one
for libxml/nolibxml2 XML backends). All discovery components are at the
same level (and I don't think we want to split the list into multiple
frameworks).

Brice

Re: [hwloc-devel] v1.7

2013-01-07 Thread Samuel Thibault 
Brice Goglin, le Mon 07 Jan 2013 19:11:02 +0100, a écrit :
> BTW, if we change the hwloc syntax, we may want to not use ^ to avoid
> confusion with OMPI. ~ and ! could work but some shells may not like them?

How about '-'? I doubt anybody would want a plugin name starting with
it.

Samuel

Re: [hwloc-devel] v1.7

2013-01-07 Thread Samuel Thibault 
Jeff Squyres (jsquyres), le Mon 07 Jan 2013 19:19:15 +0100, a écrit :
> On Jan 7, 2013, at 12:59 PM, Samuel Thibault 
> > Because I may not know *everything* that I want. Who knows what
> > proprietary plugin I need to use to discover CPUs, while I know that for
> > GPUs I can use cuda, but I don't want to use nvml.
> > 
> >> Taking your example: HWLOC_COMPONENTS=foo,^bar,^baz,yow
> >> Is the same as:  HWLOC_COMPONENTS=foo,yow
> > 
> > No, because there is also the implicit "and the default plugins" after
> > that.
> 
> So you're really saying "not bar and baz, but I do want everything else."

I'm also saying "foo and yow before everything else", which as Brice
mentioned, does matter.

> - if foo doesn't load / isn't used, it's an error
> - don't load bar
> - don't load baz
> - if yow doesn't load / isn't used, it's an error
> - try to load all other components, but don't warn/error if they don't load / 
> aren't used

We don't imply erroring out. Components never error out, they just don't
discover anything :)

What we however have is the ordering.

Samuel

Re: [hwloc-devel] v1.7

2013-01-07 Thread Jeff Squyres (jsquyres) 
On Jan 7, 2013, at 1:18 PM, "Jeff Squyres (jsquyres)" 
 wrote:

> So you're really saying "not bar and baz, but I do want everything else."


With Brice's clarification (that there's an implicit "...and all the rest" at 
the end of the specification), I see that my interpretation is wrong.

But the rest of my suggestions stand.  :-)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] v1.7

2013-01-07 Thread Jeff Squyres (jsquyres) 
On Jan 7, 2013, at 1:09 PM, Brice Goglin 
 wrote:

> Your argument works for selecting among I/O components like
> cuda/nvml/opencl that are all independent (like several components in
> the same framework in OMPI). But it doesn't work when the order matters
> between components that discover the same things. Like "I want x86 first
> because it works better than the solaris component on my machine, and
> then the other usual components for to discover everything else".
> 
> Remember that HWLOC_COMPONENTS="foo" means "foo first and then all the
> usual ones that do not conflict". It's not "only foo", which should be
> written as "foo,stop" (should be rare since the core excludes all
> conflicting components automatically).

Gotcha.  I missed those two subtleties:

1. order matters
2. there's an implicit "...and all the rest" at the end of the specification

BTW, don't get me wrong -- I'm not against a different meaning than OMPI's.  I 
was just trying to explain what OMPI uses an why.

But that being said, having a "...and all the rest" implicitly implied at the 
end of the COMPONENTS specification is a little surprising (to me, IMHO).  
Perhaps you could have a special token that means "...and all the rest"?  
Perhaps:

COMPONENTS=foo,bar,*

Which means "try foo first, then try bar, and then try all the rest in whatever 
order you want".  Because then a user could specify:

COMPONENTS=foo,bar

if they *didn't* want all the others to be used.

Just a thought.

> BTW, if we change the hwloc syntax, we may want to not use ^ to avoid
> confusion with OMPI. ~ and ! could work but some shells may not like them?


Hah.  Our mails crossed in the ether.  :-)

Short version: I agree.  ~ and ! have the drawback of requiring escaping, which 
is kind of a pain (and everyone will get it wrong).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] v1.7

2013-01-07 Thread Jeff Squyres (jsquyres) 
On Jan 7, 2013, at 12:59 PM, Samuel Thibault 
 wrote:

> Because I may not know *everything* that I want. Who knows what
> proprietary plugin I need to use to discover CPUs, while I know that for
> GPUs I can use cuda, but I don't want to use nvml.
> 
>> Taking your example: HWLOC_COMPONENTS=foo,^bar,^baz,yow
>> Is the same as:  HWLOC_COMPONENTS=foo,yow
> 
> No, because there is also the implicit "and the default plugins" after
> that.

So you're really saying "not bar and baz, but I do want everything else."

OMPI's intent was to be simple: specify what you want to *exclude* or what you 
want to *include*, but you'd never do *both*.

But maybe you're looking for some additional semantic meaning to your 
specification, above...?

COMPONENTS=foo,^bar,^baz,yow

Could mean:

- if foo doesn't load / isn't used, it's an error
- don't load bar
- don't load baz
- if yow doesn't load / isn't used, it's an error
- try to load all other components, but don't warn/error if they don't load / 
aren't used

which is more of a tri-state philosophy (yes/no/maybe), rather than a binary 
philosophy like OMPI's (yes/no).  And that would be fine, if that's what you 
want (or perhaps you want something different than that).  My point is that the 
OMPI include/exclude philosophy is quite simple to explain, and it was enough 
for us.  If something more than that is desired here, then go for it -- but you 
might want to use something other than ^ so that it's not confused with OMPI's 
syntax.

(BTW, we chose to use ^ instead of ! because with !, you'd have to escape it on 
the command line, e.g., "COMPONENTS=\!foo", which seemed like a pain, and 
everyone would get it wrong -- so we went with ^, instead)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] v1.7

2013-01-07 Thread Brice Goglin 
Le 07/01/2013 17:59, Jeff Squyres (jsquyres) a écrit :
> On Jan 7, 2013, at 9:05 AM, Samuel Thibault  wrote:
>
>> HWLOC_COMPONENTS=^cuda,opencl
>>
>> disables cuda *and* opencl, while intuition would have told me that it
>> disables cuda but enables opencl.
>>
>> Also, one would for instance want to be able to do this:
>>
>> HWLOC_COMPONENTS=x86,^cuda,^opencl,nvml
>
> (Sorry -- am just returning today from winter vacation...)
>
> FWIW: in OMPI, way back when we implemented this, we considered supporting 
> what you describe.  But then we thought -- wait, why would I ever do that?
>
> More specifically: you only ever want to specify exactly what you *do* or *do 
> not* want to be loaded.  Why would you ever list both?
>
> Taking your example: HWLOC_COMPONENTS=foo,^bar,^baz,^yow
> Is the same as:  HWLOC_COMPONENTS=foo,yow
>
> So why bother listing ^bar and ^baz?
>
> Generalizing that, why would you ever specify *some* components to exclude 
> and *some* components to exclude?  It seems much cleaner to either exclude 
> some (and therefore include the rest), or include some (and exclude the rest).
>

Your argument works for selecting among I/O components like
cuda/nvml/opencl that are all independent (like several components in
the same framework in OMPI). But it doesn't work when the order matters
between components that discover the same things. Like "I want x86 first
because it works better than the solaris component on my machine, and
then the other usual components for to discover everything else".

Remember that HWLOC_COMPONENTS="foo" means "foo first and then all the
usual ones that do not conflict". It's not "only foo", which should be
written as "foo,stop" (should be rare since the core excludes all
conflicting components automatically).

BTW, if we change the hwloc syntax, we may want to not use ^ to avoid
confusion with OMPI. ~ and ! could work but some shells may not like them?

Brice

Re: [hwloc-devel] v1.7

2013-01-07 Thread Jeff Squyres (jsquyres) 
On Jan 7, 2013, at 9:05 AM, Samuel Thibault  wrote:

> HWLOC_COMPONENTS=^cuda,opencl
> 
> disables cuda *and* opencl, while intuition would have told me that it
> disables cuda but enables opencl.
> 
> Also, one would for instance want to be able to do this:
> 
> HWLOC_COMPONENTS=x86,^cuda,^opencl,nvml


(Sorry -- am just returning today from winter vacation...)

FWIW: in OMPI, way back when we implemented this, we considered supporting what 
you describe.  But then we thought -- wait, why would I ever do that?

More specifically: you only ever want to specify exactly what you *do* or *do 
not* want to be loaded.  Why would you ever list both?

Taking your example: HWLOC_COMPONENTS=foo,^bar,^baz,^yow
Is the same as:  HWLOC_COMPONENTS=foo,yow

So why bother listing ^bar and ^baz?

Generalizing that, why would you ever specify *some* components to exclude and 
*some* components to exclude?  It seems much cleaner to either exclude some 
(and therefore include the rest), or include some (and exclude the rest).

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [hwloc-devel] v1.7

2013-01-07 Thread Ralph Castain 

On Jan 7, 2013, at 6:05 AM, Samuel Thibault  wrote:

> Hello,
> 
> Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
>> + The HWLOC_COMPONENTS may now start with '^' to only define a list of
>>   components to exclude.
> 
> I'm finding it not intuitive and not generic enough, I'm wondering how
> that didn't affect Open-MPI, which as IUI uses this convention.
> 
> It means that
> 
> HWLOC_COMPONENTS=^cuda,opencl
> 
> disables cuda *and* opencl,

FWIW: that is the OMPI convention


> while intuition would have told me that it
> disables cuda but enables opencl.
> 
> Also, one would for instance want to be able to do this:
> 
> HWLOC_COMPONENTS=x86,^cuda,^opencl,nvml
> 
> To be able to enable x86 before the default linux, but disable cuda and
> opencl, but enable nvml, as well as all the other usual plugins (without
> having to know the list, which is important for future extensions).
> 
> Samuel
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

Re: [hwloc-devel] v1.7

2013-01-07 Thread Samuel Thibault 
Brice Goglin, le Mon 07 Jan 2013 17:33:47 +0100, a écrit :
> Ideally, we could even have a OS device for each OpenCL platform, each
> containing OS devices for devices of the platform. But I'd rather keep a
> single level to match other OS devices.

In most cases the platform object wouldn't bring much information to
the topology anyway. Or worse, make it impossible, e.g. when the NVIDIA
OpenCL platform drives several GPUs on different PCI cards or even NUMA
nodes.

Samuel

Re: [hwloc-devel] v1.7

2013-01-07 Thread Brice Goglin 
Le 07/01/2013 14:35, Samuel Thibault a écrit :
> Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
>> - They add OS devices such as opencl0p0,
> I see that platform 0 device 3 would be called opencl3p0. I find it
> counterintuitive, and would have rather called it opencl0d3, along the
> line of sda3, eth0:3, socket:2.core:0, etc.
>

I don't have any strong opinion here. I wasn't convinced by any of my
ideas when I committed this.

It looks like most OpenCL machines will have multiple platforms (one for
CPU and one for GPU/accelerator) so we have to always keep the platform
in the name. I'll be ok with whichever of XpY or YdX or pYdX or anything
better.

Ideally, we could even have a OS device for each OpenCL platform, each
containing OS devices for devices of the platform. But I'd rather keep a
single level to match other OS devices.

Brice

Re: [hwloc-devel] v1.7

2013-01-07 Thread Samuel Thibault 
Hello,

Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
>   + The HWLOC_COMPONENTS may now start with '^' to only define a list of
> components to exclude.

I'm finding it not intuitive and not generic enough, I'm wondering how
that didn't affect Open-MPI, which as IUI uses this convention.

It means that

HWLOC_COMPONENTS=^cuda,opencl

disables cuda *and* opencl, while intuition would have told me that it
disables cuda but enables opencl.

Also, one would for instance want to be able to do this:

HWLOC_COMPONENTS=x86,^cuda,^opencl,nvml

To be able to enable x86 before the default linux, but disable cuda and
opencl, but enable nvml, as well as all the other usual plugins (without
having to know the list, which is important for future extensions).

Samuel

Re: [hwloc-devel] v1.7

2013-01-07 Thread Samuel Thibault 
Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit :
> - They add OS devices such as opencl0p0,

I see that platform 0 device 3 would be called opencl3p0. I find it
counterintuitive, and would have rather called it opencl0d3, along the
line of sda3, eth0:3, socket:2.core:0, etc.

What do people think?

Samuel