Am 10.12.2011 14:13, schrieb Pete Wyckoff:
rene.scharfe@xxxxxxxxxxxxxx wrote on Wed, 07 Dec 2011 18:00 +0100:
Am 07.12.2011 09:12, schrieb Thomas Rast:
René Scharfe wrote:
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 47ac188..e981a9b 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -228,8 +228,9 @@ OPTIONS
there is a match and with non-zero status when there isn't.
--threads<n>::
+ Run<n> search threads in parallel. Default is 8 when searching
+ the worktree and 0 otherwise. This option is ignored if git was
+ built without support for POSIX threads.
[...]
- nr_threads = (online_cpus()> 1) ? THREADS : 0;
+ nr_threads = (online_cpus()> 1&& !list.nr) ? THREADS : 0;
It would be more consistent to stick to the pack.threads convention
where 0 means "all of my cores", so to disable threading the user
would set the number of threads to 1. Or were you trying to measure
the contention between the worker thread and the add_work() thread?
Yes, indeed, the cost for the threading overhead does interest me. The
documentation should perhaps mention --no-threads explicitly to avoid
confusion.
Currently there is no way to specify "as many threads as there are
cores" here. Previous measurements indicated that it wasn't too useful,
however, because I/O parallelism was beneficial even for machines with
less than eight cores and more threads didn't pay off.
Right. Even for single CPU machines this is true, so the
nr_threads calculation above should still use all 8 THREADS
regardless of the number of online_cpus().
That makes sense. However, in a quick test with a simple regex against
a cache-warm Linux repo threading increased the runtime of git grep by
30% on a single-core virtual machine. Let's keep that check until we
understand this better..
René
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html