[19227] in Kerberos_V5_Development
Re: VLAs (Re: C99 Features)
daemon@ATHENA.MIT.EDU (Roland Mainz)
Thu Jul 9 11:12:45 2015
Date: Thu, 9 Jul 2015 11:12:29 -0400 (EDT)
From: Roland Mainz <rmainz@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Message-ID: <1743090904.42876883.1436454748962.JavaMail.zimbra@redhat.com>
In-Reply-To: <20150624002039.GA6117@localhost>
MIME-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
----- Original Message -----
> From: "Nico Williams" <nico@cryptonector.com>
> To: "Benjamin Kaduk" <kaduk@mit.edu>
> Cc: "krbdev@mit.edu" <krbdev@mit.edu>
> Sent: Wednesday, June 24, 2015 2:20:39 AM
> Subject: VLAs (Re: C99 Features)
>
> On Sat, Jun 20, 2015 at 03:11:03PM -0400, Benjamin Kaduk wrote:
> > On Fri, 19 Jun 2015, Nico Williams wrote:
> > > > Well, take common inner-function heap allocations and turn them into
> > > > stack allocations. That is a significant performance gain.
> > >
> > > Probably. A decent heap allocator with per-thread magazines ought to be
> > > good enough in most cases.
> >
> > I'm not sure I follow what point Nico is trying to make, here. [...]
>
> That we shouldn't be making this optimization except where it's really
> necessary. I.e., find a hotspot where VLAs or alloca() is the fix.
>
> The heap allocator ought to be good enough.
No... it is not. Sun long ago did a detailed analysis of the problem (related to libumem and the Solaris kernel memory allocator) and it was found while libumem (this applies to all normal allocator systems) is very fast&&efficient it does not distinguish between object types and object usage/lifetime.
The small/artificial testcases used to "prove" the "superiority" of a specific allocator typically do not measure effects of long-term heap thrashing/fragmentation caused by interleaving allocations and out-of-order-|free()| between threads or mixture between temporary allocations (with |malloc()|+|free()| in the same function) and long-term allocations.
One of the findings of this analysis was that if the temporary allocations come from a different memory pool (or stack via VLA/|alloca()|) then the long-term fragmentation of the global heap can be *GREATLY* reduced.
So using memory from stack to serve allocations of temporary memory still makes sense because it reduces the long-term fragmentation of the global heap a *lot*. This becomes even more important for threaded applications but still applies to single-threaded but long-running processes (like the krb5kdc), too.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) rmainz@redhat.com
\__\/\/__/ IPA/Kerberos5 team
/O /==\ O\
(;O/ \/ \O;)
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
