# git and multiple cores

6 messages from 2009-06-02 to 2009-06-02. Participants: Chris Friesen, Peter Harris, Shawn O. Pearce, Nicolas Pitre.
Thread: https://gitlist.dev/t/19646

## Chris Friesen, 2009-06-02 22:40

Subject: git and multiple cores
Message-ID: <4A25AA4C.9070600@nortel.com>
URL: https://gitlist.dev/e/4A25AA4C.9070600%40nortel.com

```

I'm using git 1.6.1.3 and it seems to be limited to a single core.
Given that I've seen cases where the cpu has been basically pinned for
minutes on end (initial clone of a repository, for instance) has there
been any discussion of taking advantage of multiple cores?

Chris

```

## Peter Harris, 2009-06-02 22:55

Subject: Re: git and multiple cores
Message-ID: <eaa105840906021555w22e62341l61f250455cf8c23b@mail.gmail.com>
URL: https://gitlist.dev/e/eaa105840906021555w22e62341l61f250455cf8c23b%40mail.gmail.com
In-Reply-To: <4A25AA4C.9070600@nortel.com>

```
On Tue, Jun 2, 2009 at 6:40 PM, Chris Friesen wrote:
>
> I'm using git 1.6.1.3 and it seems to be limited to a single core.
> Given that I've seen cases where the cpu has been basically pinned for
> minutes on end (initial clone of a repository, for instance) has there
> been any discussion of taking advantage of multiple cores?

Sounds like you're mostly concerned about packing.

The good news is, your version of git already has a threaded packer.
You just need to enable it. See "pack.threads" in "git help config".

1.6.2 and newer use multiple threads by default.

Peter Harris

```

## Shawn O. Pearce, 2009-06-02 23:02

Subject: Re: git and multiple cores
Message-ID: <20090602230205.GL30527@spearce.org>
URL: https://gitlist.dev/e/20090602230205.GL30527%40spearce.org
In-Reply-To: <eaa105840906021555w22e62341l61f250455cf8c23b@mail.gmail.com>

```
Peter Harris <git@peter.is-a-geek.org> wrote:
> On Tue, Jun 2, 2009 at 6:40 PM, Chris Friesen wrote:
> >
> > I'm using git 1.6.1.3 and it seems to be limited to a single core.
> > Given that I've seen cases where the cpu has been basically pinned for
> > minutes on end (initial clone of a repository, for instance) has there
> > been any discussion of taking advantage of multiple cores?
> 
> Sounds like you're mostly concerned about packing.
> 
> The good news is, your version of git already has a threaded packer.
> You just need to enable it. See "pack.threads" in "git help config".
> 
> 1.6.2 and newer use multiple threads by default.

True, but he was talking about initial clone, which on the client
side is git-index-pack.  Which is not threaded.
 
-- 
Shawn.

```

## Peter Harris, 2009-06-02 23:12

Subject: Re: git and multiple cores
Message-ID: <eaa105840906021612y5b9e4c25o1062d7f7aecfbd16@mail.gmail.com>
URL: https://gitlist.dev/e/eaa105840906021612y5b9e4c25o1062d7f7aecfbd16%40mail.gmail.com
In-Reply-To: <20090602230205.GL30527@spearce.org>

```
On Tue, Jun 2, 2009 at 7:02 PM, Shawn O. Pearce wrote:
> Peter Harris <git@peter.is-a-geek.org> wrote:
>> On Tue, Jun 2, 2009 at 6:40 PM, Chris Friesen wrote:
>> >
>> > I'm using git 1.6.1.3 and it seems to be limited to a single core.
>> > Given that I've seen cases where the cpu has been basically pinned for
>> > minutes on end (initial clone of a repository, for instance) has there
>> > been any discussion of taking advantage of multiple cores?
>>
>> Sounds like you're mostly concerned about packing.
>>
>> The good news is, your version of git already has a threaded packer.
>> You just need to enable it. See "pack.threads" in "git help config".
>>
>> 1.6.2 and newer use multiple threads by default.
>
> True, but he was talking about initial clone, which on the client
> side is git-index-pack.  Which is not threaded.

Ah. I thought he was talking about the server side. My mistake.

Peter Harris

```

## Chris Friesen, 2009-06-02 23:29

Subject: Re: git and multiple cores
Message-ID: <4A25B5C3.40409@nortel.com>
URL: https://gitlist.dev/e/4A25B5C3.40409%40nortel.com
In-Reply-To: <eaa105840906021612y5b9e4c25o1062d7f7aecfbd16@mail.gmail.com>

```
Peter Harris wrote:
> On Tue, Jun 2, 2009 at 7:02 PM, Shawn O. Pearce wrote:
> 
>>Peter Harris <git@peter.is-a-geek.org> wrote:
>>
>>>On Tue, Jun 2, 2009 at 6:40 PM, Chris Friesen wrote:
>>>
>>>>I'm using git 1.6.1.3 and it seems to be limited to a single core.
>>>>Given that I've seen cases where the cpu has been basically pinned for
>>>>minutes on end (initial clone of a repository, for instance) has there
>>>>been any discussion of taking advantage of multiple cores?
>>>
>>>Sounds like you're mostly concerned about packing.
>>>
>>>The good news is, your version of git already has a threaded packer.
>>>You just need to enable it. See "pack.threads" in "git help config".
>>>
>>>1.6.2 and newer use multiple threads by default.
>>
>>True, but he was talking about initial clone, which on the client
>>side is git-index-pack.  Which is not threaded.
> 
> 
> Ah. I thought he was talking about the server side. My mistake.

Sorry, I wasn't clear.  I was talking about the client side, although
the server side information is useful to have.

I have a 4-way machine as a client, and it just seemed odd that git
could only use one core.

Chris

```

## Nicolas Pitre, 2009-06-02 23:54

Subject: Re: git and multiple cores
Message-ID: <alpine.LFD.2.00.0906021949410.3906@xanadu.home>
URL: https://gitlist.dev/e/alpine.LFD.2.00.0906021949410.3906%40xanadu.home
In-Reply-To: <4A25B5C3.40409@nortel.com>

```
On Tue, 2 Jun 2009, Chris Friesen wrote:

> Peter Harris wrote:
> > On Tue, Jun 2, 2009 at 7:02 PM, Shawn O. Pearce wrote:
> > 
> >>True, but he was talking about initial clone, which on the client
> >>side is git-index-pack.  Which is not threaded.
> > 
> > 
> > Ah. I thought he was talking about the server side. My mistake.
> 
> Sorry, I wasn't clear.  I was talking about the client side, although
> the server side information is useful to have.
> 
> I have a 4-way machine as a client, and it just seemed odd that git
> could only use one core.

It can use them all when repacking or pushing.  But on a clone or fetch 
your client machine deals with incoming data using index-pack which is 
much more trickier to thread.


Nicolas

```
