On 31/05/11 01:28, James Youngman wrote:
> [ CC += bug-findutils, += Paolo, -= bug-coreutils ]
>
> 2009/11/3 Pádraig Brady :
>> Pádraig Brady wrote:
>>> Paolo Bonzini wrote:
Maybe we want a --parallel option (too bad -p is taken) for xargs that
forces the creation of the number of proces
[ CC += bug-findutils, += Paolo, -= bug-coreutils ]
2009/11/3 Pádraig Brady :
> Pádraig Brady wrote:
>> Paolo Bonzini wrote:
>>> Maybe we want a --parallel option (too bad -p is taken) for xargs that
>>> forces the creation of the number of processes passed with -P or taken
>>> from nproc (for exa
Hello,
Erik Auerswald writes:
> Why have an option for the default operation at all? If --available is
> the same as specifying no option and the only other mode of operation is
> --all, only the --all option should be recognised. There is no need for
> --available.
it is not very common case b
Hi Pádraig,
Pádraig Brady writes:
> Well --available and --all are mutually exclusive and related.
> That fact is obvious if they're parameters to a single option.
> But I do take your point that --count is a bit redundant,
> and I don't see nproc getting many other options, so OK
> leave them a
Giuseppe Scrivano wrote:
> Subject: [PATCH] nproc: A new program to count the number of processors
s/number of/available/
>
> * AUTHORS: Add my name.
> * NEWS: Mention it.
> * README: Likewise.
> * bootstrap.conf (gnulib_modules): Add nproc.
> * doc/coreutils.texi (nproc invocation): Add nproc i
I have updated the new nproc program to use this change in gnulib.
Thanks to Bruno, now nproc has not any logic inside but it is a mere
wrapper around the gnulib module.
I used as arguments to the new program the same names used by the
`nproc_query' enum, except using --overridable instead of
Bruno Haible writes:
> There were no further comments except Pádraig's one, so I committed the
> change:
>
> 2009-11-04 Bruno Haible
>
> Make num_processors more flexible and consistent.
> * lib/nproc.h (enum nproc_query): New type.
> (num_processors): Add a 'query' argument.
Paolo Bonzini wrote:
> On 11/04/2009 01:24 AM, Pádraig Brady wrote:
>> BTW, it wouldn't be ambiguous to the program, nor would it
>> be different than the existing meaning, but as you say,
>> users could mistakenly do -P0 when they meant -0P.
>> So I'll make the arg mandatory, but what to choose?
>
There were no further comments except Pádraig's one, so I committed the
change:
2009-11-04 Bruno Haible
Make num_processors more flexible and consistent.
* lib/nproc.h (enum nproc_query): New type.
(num_processors): Add a 'query' argument.
* lib/nproc.c: Include
* Pádraig Brady wrote on Tue, Nov 03, 2009 at 12:35:05PM CET:
> --- a/doc/find.texi
> +++ b/doc/find.texi
> @@ -3521,6 +3521,15 @@ Use at most @var{max-args} arguments per command line.
> Fewer than
> option) is exceeded, unless the @samp{-x} option is given, in which
> case @code{xargs} will e
Ralf Wildenhues wrote:
> * Pádraig Brady wrote on Tue, Nov 03, 2009 at 12:35:05PM CET:
>> --- a/doc/find.texi
>> +++ b/doc/find.texi
>> @@ -3521,6 +3521,15 @@ Use at most @var{max-args} arguments per command
>> line. Fewer than
>> option) is exceeded, unless the @samp{-x} option is given, in whi
On 11/04/2009 01:24 AM, Pádraig Brady wrote:
BTW, it wouldn't be ambiguous to the program, nor would it
be different than the existing meaning, but as you say,
users could mistakenly do -P0 when they meant -0P.
So I'll make the arg mandatory, but what to choose?
"n" is all I can come up with in m
seq 1 13 | xargs --parallel -P4
1 5 9 13
2 6 10
3 7 11
4 8 12
(Note there's no -n). Same for
seq 1 13 | xargs --parallel
on a 4-core machine. This is _by design_ rearranging files, so it
requires an option.
Right, you're not auto decreasing -n, but when we read all args and
we pass argume
Pádraig Brady wrote:
> Paolo Bonzini wrote:
>> Maybe we want a --parallel option (too bad -p is taken) for xargs that
>> forces the creation of the number of processes passed with -P or taken
>> from nproc (for example by starting "md5sum $1 $5 $9 ...", "md5sum $2 $6
>> $10 ...", etc.)?
>> That wou
Paolo Bonzini wrote:
>>> I was thinking of an additional option that would automatically decrease
>>> -n so that the requested number of processes is started (then of course
>>> the load may not be well balanced).
>>
>> So you mean, rather than the current situation of:
>>
>> $ yes . | head -n13 |
Pádraig Brady wrote:
> > + while (*envvalue != '\0' && c_isspace (*envvalue))
> > + envvalue++;
>
> A pedantic comment. Could one instead assume strtoul() skips leading
> whitespace?
But then strtoul would also skip a sign, and a value of, say, "+4" is not
allowed by the OpenMP spec.
Bruno Haible wrote:
>
> Here is a proposed change to the gnulib 'nproc' module. It will
> require changes (simplification) on Giuseppe's side, of course.
Wow, this is great stuff Bruno, thanks!
> *** lib/nproc.c.orig 2009-11-01 14:55:37.0 +0100
> --- lib/nproc.c 2009-11-01 14:54:5
Pádraig Brady wrote:
> num_processors() already uses _NPROCESSORS_ONLN (online processors)
> so I then wondered how this be different to that returned by
> pthread_getaffinity_np() ?
>
> A quick google for cpuset shows:
> http://www.kernel.org/doc/man-pages/online/pages/man7/cpuset.7.html
>
> Als
Giuseppe Scrivano wrote:
> Hi Pádraig,
>
>
> Pádraig Brady writes:
>
>> I do wonder though whether it would be better
>> to have num_processors() try to return this by default?
>
> num_processors is going to be used by programs as nproc will be used by
> scripts; all considerations we made for
Hi Pádraig,
Pádraig Brady writes:
> I do wonder though whether it would be better
> to have num_processors() try to return this by default?
num_processors is going to be used by programs as nproc will be used by
scripts; all considerations we made for nproc can be applied to
num_processors.
Thanks for continuing with this.
I'm not sure we agreed on the name but I like nproc at least :)
Giuseppe Scrivano wrote:
> +...@item --available
> +...@opindex --available
> +Print the number of processors available to the current process. It
> +may be less than the number of installed processo
Giuseppe Scrivano wrote:
...
>>From d1dd83a6a4130ee8b8be47d5d5db461fc60e166a Mon Sep 17 00:00:00 2001
...
> diff --git a/NEWS b/NEWS
> index 0760775..6b8f6b3 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -60,6 +60,10 @@ GNU coreutils NEWS-*-
> outline -*-
>touch now
Hi Jim,
thanks for your quick review.
Jim Meyering writes:
> Giuseppe Scrivano wrote:
>> I included what we have discussed into my patch. I renamed the new
>> program to `nproc', now it accepts two options: --available and
>> --installed.
>> By default --available is used, if --available is n
Giuseppe Scrivano wrote:
> I included what we have discussed into my patch. I renamed the new
> program to `nproc', now it accepts two options: --available and
> --installed.
> By default --available is used, if --available is not know then
> --installed is used.
>
> I added another test to ensure
Hi,
I included what we have discussed into my patch. I renamed the new
program to `nproc', now it accepts two options: --available and
--installed.
By default --available is used, if --available is not know then
--installed is used.
I added another test to ensure nproc --available <= nproc --ins
Bruno Haible writes:
> Pádraig Brady wrote:
>> >> Of course this should only apply if its effect is not externally
>> >> observable; if I have a very small file B and a very large file A, and I
>> >> can get
>> >>
>> >> $ md5sum --threads A B
>> >> abcdabcdabcdabcdabcdabcdabcdabcd B
>> >>
Pádraig Brady wrote:
> >> Of course this should only apply if its effect is not externally
> >> observable; if I have a very small file B and a very large file A, and I
> >> can get
> >>
> >> $ md5sum --threads A B
> >> abcdabcdabcdabcdabcdabcdabcdabcd B
> >> 123412341234123412341234123
I was thinking of an additional option that would automatically decrease
-n so that the requested number of processes is started (then of course
the load may not be well balanced).
So you mean, rather than the current situation of:
$ yes . | head -n13 | xargs -n4 -P2
. . . .
. . . .
. . . .
.
Paolo Bonzini wrote:
> On 10/27/2009 01:16 PM, Pádraig Brady wrote:
>> I already suggested to the xargs maintainer that `xargs -P`
>> should be equivalent to xargs -P$(nproc).
>
> I was thinking of an additional option that would automatically decrease
> -n so that the requested number of processe
On 10/27/2009 01:16 PM, Pádraig Brady wrote:
I already suggested to the xargs maintainer that `xargs -P`
should be equivalent to xargs -P$(nproc).
I was thinking of an additional option that would automatically decrease
-n so that the requested number of processes is started (then of course
t
Paolo Bonzini wrote:
> Maybe we want a --parallel option (too bad -p is taken) for xargs that
> forces the creation of the number of processes passed with -P or taken
> from nproc (for example by starting "md5sum $1 $5 $9 ...", "md5sum $2 $6
> $10 ...", etc.)?
> That would be an interesting alterna
On 10/27/2009 11:55 AM, Pádraig Brady wrote:
$ md5sum --threads A B
abcdabcdabcdabcdabcdabcdabcdabcd B
12341234123412341234123412341234 A
Grr. An argument for_not_ splitting.
It is indeed that way.
In http://lists.gnu.org/archive/html/bug-coreutils/2009-10/msg00179.html
you say
Pádraig Brady wrote:
> Paolo Bonzini wrote:
>>
>> Of course this should only apply if its effect is not externally
>> observable; if I have a very small file B and a very large file A, and I
>> can get
>>
>> $ md5sum --threads A B
>> abcdabcdabcdabcdabcdabcdabcdabcd B
>> 123412341234123
Paolo Bonzini wrote:
>
>>> Some programs, like 'msgmerge' from GNU gettext, already pay
>>> attention to the OMP_NUM_THREADS variable - a convention shared
>>> by all programs that rely on OpenMP. Can you make the 'sort'
>>> program use the same convention?
>>
>> I am not working on the multi-thre
Some programs, like 'msgmerge' from GNU gettext, already pay
attention to the OMP_NUM_THREADS variable - a convention shared
by all programs that rely on OpenMP. Can you make the 'sort'
program use the same convention?
I am not working on the multi-threaded sort, but if somebody asks I can
mak
Hi Bruno,
Bruno Haible writes:
>> No, it should not be a hardware inspection tool but a portable
>> tool to help shell scripts to have an idea of how many
>> processes can be executed at the same time. If we get too
>> much into details then we loose portability
>
> Good. This is important info
Hi Giuseppe,
> No, it should not be a hardware inspection tool but a portable
> tool to help shell scripts to have an idea of how many
> processes can be executed at the same time. If we get too
> much into details then we loose portability
Good. This is important info; IMO it belongs in the
cor
Bruno Haible writes:
> This program (and the underlying gnulib 'nproc' module) is IMO too simplistic.
>
> First of all, is the program meant to be a hardware inspection tool (like
> "hwinfo --cpu")? Or is meant to be an auxiliary program for helping shell
> scripts that want to dispatch tasks on
Giuseppe Scrivano wrote:
> I went for `core-count'. This is the first version of the new program,
> it is a simple wrapper around the gnulib nproc module
This program (and the underlying gnulib 'nproc' module) is IMO too simplistic.
First of all, is the program meant to be a hardware inspection
39 matches
Mail list logo
