Hi Pádraig,
Pádraig Brady p...@draigbrady.com 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
Hello,
Erik Auerswald auers...@unix-ag.uni-kl.de 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
There were no further comments except Pádraig's one, so I committed the
change:
2009-11-04 Bruno Haible br...@clisp.org
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?
n is all
Bruno Haible br...@clisp.org writes:
There were no further comments except Pádraig's one, so I committed the
change:
2009-11-04 Bruno Haible br...@clisp.org
Make num_processors more flexible and consistent.
* lib/nproc.h (enum nproc_query): New type.
(num_processors):
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
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 | xargs -n4 -P2
.
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 would be an
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
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 which
case
* 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 exit.
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 my
Giuseppe Scrivano wrote:
Hi Pádraig,
Pádraig Brady p...@draigbrady.com 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
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
Also this
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
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
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 nproc
Hi Jim,
thanks for your quick review.
Jim Meyering j...@meyering.net 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
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 accepts
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 processors.
Hi Pádraig,
Pádraig Brady p...@draigbrady.com 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
Hi Bruno,
Bruno Haible br...@clisp.org 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
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
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-threaded sort, but
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
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 alternative to
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
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 processes is
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
. . . .
. . . .
. . . .
.
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
12341234123412341234123412341234 A
Then the
Bruno Haible br...@clisp.org 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
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
Jim Meyering j...@meyering.net writes:
If nobody is already working on it, I can start doing it.
What about the name? ncores or ncpus are fine?
Here are some longer candidates:
count-cores
count-cpus
cpu-count
core-count
Actually, cpu seems too ambiguous, so let's rule those
Giuseppe Scrivano wrote:
Jim Meyering j...@meyering.net writes:
If nobody is already working on it, I can start doing it.
What about the name? ncores or ncpus are fine?
Here are some longer candidates:
count-cores
count-cpus
cpu-count
core-count
Actually, cpu seems too
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
Bruno Haible br...@clisp.org 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
36 matches
Mail list logo
