m just saying that
> it's not unheard of. And with the delta cache and the object lookup, it's
> not at _all_ impossible that we hit the "allocate in one thread, free in
> another" case!
>
> Linus
>
--
Jon Smirl
[EMAIL PROTECTED]
On 12/11/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 11 Dec 2007, Jon Smirl wrote:
> >
> > So why does our threaded code take 20 CPU minutes longer (12%) to run
> > than the same code with a single thread?
>
> Threaded code *always* takes mor
t 25% so far, but I was unable to get that far before.
>
> Well, around 55% memory usage skyrocketed to 1.6GB and the system went
> deep into swap. So I restarted it with no threads.
>
> Nicolas (even more puzzled)
On the plus side you are seeing what I see, so it proves I am not imagining it.
--
Jon Smirl
[EMAIL PROTECTED]
g the allocation types.
When a thread is created it could allocated a private 20MB (or
whatever) pool. The volatile, private objects would come from that
pool. Long term objects would stay in the global pool. Since they are
long term they will just get laid down sequentially in memory.
Separating
allocator to try? One that combines Google's
efficiency with gcc's speed?
On 12/11/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> I added the gcc people to the CC, it's their repository. Maybe they
> can help up sort this out.
>
> On 12/11/07, Jon Smirl <[EMAIL PRO
I added the gcc people to the CC, it's their repository. Maybe they
can help up sort this out.
On 12/11/07, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 12/10/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > On Mon, 10 Dec 2007, Jon Smirl wrote:
> >
> > > N
not as localized as we've tried to make things in
> the kernel, so doing the code copy detection is probably horrendously
> expensive)
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jon Smirl
[EMAIL PROTECTED]
e a copy, so we can run further tests from a known point
> cd ..
> cp -a gcc test
>
> # and test multithreaded large depth/window repacking
> cd test
> git config pack.threads 4
64 threads with 64 CPUs, if they are multicore you want even more.
you need to adjust chunk_size as mentioned in the other mail.
> time git repack -a -d -f --window=250 --depth=250
>
> -Peff
>
--
Jon Smirl
[EMAIL PROTECTED]
On 12/7/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 6 Dec 2007, Jon Smirl wrote:
> > >
> > > time git blame -C gcc/regclass.c > /dev/null
> >
> > [EMAIL PROTECTED]:/video/gcc$ time git blame -C gcc/regclass.c > /dev/n
ects: 648366, done.
Compressing objects: 100% (647457/647457), done.
Writing objects: 100% (648366/648366), done.
Total 648366 (delta 539043), reused 0 (delta 0)
real6m2.109s
user20m0.491s
sys 0m4.608s
[EMAIL PROTECTED]:/home/linux/.git$
>
>
> Nicolas
>
--
Jon Smirl
[EMAIL PROTECTED]
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
> > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > the work. I wa
On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> On Thu, 6 Dec 2007, Jon Smirl wrote:
>
> > On 12/6/07, Nicolas Pitre <[EMAIL PROTECTED]> wrote:
> > > > When I lasted looked at the code, the problem was in evenly dividing
> > > > the work. I wa
(648366/648366), done.
Total 648366 (delta 539080), reused 0 (delta 0)
real9m18.325s
user 19m14.340s
sys 0m3.996s
[EMAIL PROTECTED]:/home/linux$
--
Jon Smirl
[EMAIL PROTECTED]
mber of
threads I was able to get a 4hr pack to finished in something like
1:15.
A scheme where each core could work a minute without communicating to
the other cores would be best. It would also be more efficient if the
cores could avoid having sync points between them.
--
Jon Smirl
[EMAIL PROTECTED]
s not multi-threaded. There were a
few attempts at making it multi-threaded but none were too successful.
If I remember right, with loads of RAM, a repack on a 450MB repository
was taking about five hours on a 2.8Ghz Core2. But this is something
you only have to do once for the import. Later repacks wi
On 5/25/06, Jon Smirl <[EMAIL PROTECTED]> wrote:
I ran into another snag that taking the alternative return on a P4 has
really bad performance impacts since it messes up prefetch. This
sequence is the killer.
addl$4, %esp
ret /* Ret
On 5/25/06, Geert Bosch <[EMAIL PROTECTED]> wrote:
On May 23, 2006, at 11:21, Jon Smirl wrote:
> A new calling convention could push two return addresses for functions
> that return their status in EAX. On EAX=0 you take the first return,
> EAX != 0 you take the second.
This se
rge
program with many levels of calls would the return always be predicted
on the error path?
--
Jon Smirl
[EMAIL PROTECTED]
On 5/23/06, Gabriel Paubert <[EMAIL PROTECTED]> wrote:
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote:
> Has work been done to evaluate a calling convention that takes error
> checks like this into account? Are there size/performance wins? Or am
> I just reinventing
s shouldn't introduce another one.
change isn't a win. Some form of exception handling for truly
exceptional situations would probably be better (and might have helped
to avoid quite a few of the last CVEs 8-).
--
Jon Smirl
[EMAIL PROTECTED]
complex?
This does eliminate the test./jmp after every function call.
Further branches could be eliminated by having multiple returns from
the called function at the expense of increasing code size.
Paul
--
Jon Smirl
[EMAIL PROTECTED]
es error
checks like this into account? Are there size/performance wins? Or am
I just reinventing a variation on exception handling?
--
Jon Smirl
[EMAIL PROTECTED]
22 matches
Mail list logo
