Re: git bisect on multiple cores
- From
Matthieu Moy <matthieu.moy@imag.fr>
- Date
- Apr 9, 2008, 08:07 UTC
- Message-ID
- <vpq63ure9j6.fsf@bauges.imag.fr>
- In-Reply-To
- <20080409071750.GA23211@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
Show 13 quoted lines
> On 2008-04-08 12:58:47 +0200, A B wrote: > >> git bisect is really cool. I use it for the first time. Just a >> thought, if you have a multiple core computer, can't you make git >> build new versions in the background while testing the previuos >> version? Alright, if you build 2 versions, one of them will never be >> tested, but you will perhaps save some time by letting it build in >> the background? > > Adding parallelism to a binary search scales very badly -- I'd say > about logarithmically, but I haven't thought hard about it. If it's > possible to use the extra cores to speed up the build+test cycle, > that's vastly preferable.
Probably logarithmically with the number of cores. But for reasonable machines, this number is relatively low, so the log is not so costly. For a binary search, using just 2 cores, you can try the next in the list in case of a "git bisect good" for example, and if the hypothesis is true, you've just gained a factor 2 (assuming it happens 50% of times, that should be a 50% speedup). Similarly, you should get a factor 2 with 3 cores.
And as said before, you can also try trisection or N-section. But no, I won't claim this is simple to implement ;-).
-- Matthieu