Re: fdesc allocation optimization

From: Matthew Dillon (dillon_at_apollo.backplane.com)
Date: 08/22/05

  • Next message: Matthew Reimer: "Re: [CFR] reflect resolv.conf update to running application"
    Date: Mon, 22 Aug 2005 10:46:41 -0700 (PDT)
    To: des@des.no (Dag-Erling Smørgrav)
    
    

    :Alexey Dokuchaev <danfe@FreeBSD.org> writes:
    :> i've been browsing some of dfbsd resources recently, and found this one
    :> being pretty interesting:
    :>
    :> http://leaf.dragonflybsd.org/mailarchive/commits/2005-06/msg00526.html
    :>
    :> however, it seemingly did not get attention in our lists. so i am
    :> wondering if there are work/plans on porting hsu@'s work? i remember
    :> that at some point we adopted some openbsd-derived algorithm, but since
    :> matt states that this is "far better algorithm then anything we or
    :> freebsd thought up before", i figured it worth a look.
    :
    :Bollocks. Our current algorithm (which I wrote) is so fast you don't
    :even notice it's there. It's actually simpler than the OpenBSD code
    :from which it was inspired, and in theory it should be slower, but I
    :discovered that the overhead of the "better" algorithm was so high
    :that it consistently lost to the simpler one for reasonable amounts of
    :file descriptors (up to about 100,000 per process).
    :
    :The source code for the microbenchmark I used, and selected graphs
    :comparing my code to the previous implementation, are available at
    :<URL:http://people.freebsd.org/~des/fdbench/>.
    :
    :(the strange artifacts you see on the red graphs are the result of the
    :file descriptor table overrunning the CPU cache)
    :
    :DES
    :--
    :Dag-Erling Smørgrav - des@des.no
        
        Well, I expect that once you get past a pure linear search any algorithm
        will fast enough that it probably doesn't matter in real life. But I
        would not pooh-pooh Jeff's implementation of the Solaris algorithm so
        quickly. It is the fastest, cleanest, most elegant implementation of
        a file descriptor handling algorithm that I've ever seen in my life.
        Anyone who actually reads the code will come away wondering why FreeBSD
        is still screwing around with linear bitmaps.

                                            -Matt
                                            Matthew Dillon
                                            <dillon@backplane.com>
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"


  • Next message: Matthew Reimer: "Re: [CFR] reflect resolv.conf update to running application"

    Relevant Pages

    • Re: initialization time?
      ... complex algorithm for sorting very large numbers of strings. ... sort after sort, that may be irrelevant, but if it's going to sort a ... > times slower in the first 2. ... > algorithm unless in real life you run this code 20+ times per run? ...
      (comp.lang.java.help)
    • Re: Crouts Algorithm
      ... Jakub Rabiega wrote: ... > about Crouts Algorithm. ... > algorithm used in real life. ... I doubt if there are any "real life" examples of its use today. ...
      (sci.math.num-analysis)