All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andi Kleen <andi@firstfloor.org>, Chris Snook <csnook@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Slightly off topic] A question about R/B trees.
Date: Mon, 20 Oct 2008 17:57:01 +0200	[thread overview]
Message-ID: <48FCAA4D.3030802@gmail.com> (raw)
In-Reply-To: <84144f020810180145p68a89d17y7609644f7b9d21bf@mail.gmail.com>

Pekka Enberg wrote:
> Hi Andi,
> 
> On Sat, Oct 18, 2008 at 10:53 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> The problem with hash tables is that if they're big enough
>> or if the rest of the workload is memory intensive
>> each hit will be a cache miss. And you can do a lot of branch
>> mispredicts in the time of a single cache miss.
>>
>> In general trees can be much better for cache usage, although
>> it's generally better to use some tree that has nodes near
>> the cache line size. Binary trees like RB are too small for that.
> 
> Right, but even for binary trees, you can get some of the benefits by
> packing all the nodes in a slab cache of their own. That way many of
> the neighboring nodes will share the same cache line if you're
> allocating memory for the nodes in a top-down order. Of course, you
> lose the benefits if the tree is updated a lot because you're back to
> worst case allocation again.
> 
>                        Pekka

Thank you very much.

Best regards,
	Maxim Levitsky

      reply	other threads:[~2008-10-20 15:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-17 21:34 [Slightly off topic] A question about R/B trees Maxim Levitsky
2008-10-17 22:15 ` Chris Snook
2008-10-17 22:47   ` Maxim Levitsky
2008-10-20 14:54     ` Chris Friesen
2008-10-18  7:53   ` Andi Kleen
2008-10-18  8:45     ` Pekka Enberg
2008-10-20 15:57       ` Maxim Levitsky [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48FCAA4D.3030802@gmail.com \
    --to=maximlevitsky@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=csnook@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@cs.helsinki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.