Date: Sun, 25 Nov 2007 16:48:30 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Roman Divacky <rdivacky@freebsd.org> Cc: binto <binto@triplegate.net.id>, freebsd-hackers@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: Before & After Under The Giant Lock Message-ID: <474A17DE.7010804@FreeBSD.org> In-Reply-To: <20071125211807.GA12250@freebsd.org> References: <474830F9.90305@zirakzigil.org> <6eb82e0711240638g2cc1e54o1fb1321cafe8ff9f@mail.gmail.com> <1188.202.127.99.4.1195957922.squirrel@webmail.triplegate.net.id> <20071125110116.U63238@fledge.watson.org> <20071125143546.V6583@cauchy.math.missouri.edu> <20071125211807.GA12250@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Roman Divacky wrote:
> On Sun, Nov 25, 2007 at 02:41:35PM -0600, Stephen Montgomery-Smith wrote:
>>
>> On Sun, 25 Nov 2007, Robert Watson wrote:
>>
>>> ........................
>>> In FreeBSD 8, I expect we'll see a continued focus on both locking
>>> granularity and improving opportunities for kernel parallelism by better
>>> distributing workloads over CPU pools. This is important because the
>>> number of cores/chip is continuing to increase dramatically, so MP
>>> performance is going to be important to keep working on. That said, the
>>> results to date have been extremely promising, and I anticipate that we
>>> will continue to find ways to better exploit multiprocessor hardware,
>>> especially in the network stack.
>>>
>> I just want to add my 2 cents, that my recent experience with FreeBSD MP
>> has been extremely positive. I tend to use highly CPU bound MP programs,
>> typically lots and lots of floating point operations. It used to be that
>> Linux beat FreeBSD hands down - now FreeBSD seems to have a slight edge!
>> Basically my program runs about twice as fast when I run two threads as
>> opposed to one - I cannot see doing any better than that!
>
> pure computation does not need kernel operations most of the time.. ie.
> multi-threading kernel wont help much ;)
It has an indirect benefit by (presumably) not being in contention
with the userland process, and not needing slap Giant on the whole
system every few milliseconds.
Doug
--
This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?474A17DE.7010804>