[RFC] Using large pages for large hash tables
Hal Finkel via llvm-commits
llvm-commits at lists.llvm.org
Mon Oct 17 10:14:54 PDT 2016
----- Original Message -----
> From: "Michael Kruse via llvm-commits" <llvm-commits at lists.llvm.org>
> To: "Rafael Espíndola" <rafael.espindola at gmail.com>
> Cc: "Aaron Ballman" <aaron.ballman at gmail.com>, "llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Monday, October 17, 2016 10:49:29 AM
> Subject: Re: [RFC] Using large pages for large hash tables
> 2016-10-17 17:38 GMT+02:00 Rafael Espíndola via llvm-commits
> <llvm-commits at lists.llvm.org>:
> > I did a quick and dirty experiment to use large pages when a hash
> > table gets big. The results for lld are pretty impressive (see
> > attached file, but basically 1.04X faster link of files with debug
> > info).
> > I tested disabling madvise and the performance goes back to what it
> > was, so it is really the large pages that improves the performance.
> > The main question is then what the interface should look like. On
> > linux the abstraction could be
> > std::pair<void *, size_t> mallocLarge(size_t Size);
> > which return the allocated memory and how much was actually
> > allocated.
> > The pointer can be passed to free once it is no longer needed.
> > The fallback implementation just calls malloc and returns Size
> > unmodified.
> > On linux x86_64 if size is larger than 2MiB we use posix_memalign
> > and madvise.
> > Would the same interface work on windows?
> Yes, using VirtualAlloc using MEM_LARGE_PAGES flag:
> Size can be determined using GetLargePageMinimum(), or a multiple of
> Do common implementations of malloc allocate (large) pages
> automatically when the allocated size is large enough?
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-commits