This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About JSON output generated by "bench-malloc-thread"


Hi Siddesh,
You're right, I have to sign another copyright assignment. I will
eventually do that in the future but perhaps it does not make sense to do
it now for such a small contribution.

However that didn't stop me from approaching in a slightly different manner
my benchmarking:
I wrote a small Makefile and a couple of python scripts and uploaded them
and the benchmark I collected on 3 different machines here:
   https://github.com/f18m/malloc-benchmarks
The test compares GNU libc implementation, tcmalloc and jemalloc.
Apparently tcmalloc is the winner on the first 2 systems, having 4 and 8
cores.
GNU libc 2.26 in those 2 systems was much faster than earlier GNU libc
implementations and, although slower than tcmalloc, did good.

This 3rd machine is a dual-CPU server having a total of 40 cores and
unfortunately it runs Centos7 and I could not build GNU libc 2.26 there.
The system GNU libc there (2.17) was pretty bad w.r.t. performances if
compared against jemalloc!


Hope these results may turn useful to others...

Francesco


2018-02-01 16:55 GMT+01:00 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com>
:

> On 1 February 2018 at 20:38, Francesco <francesco.montorsi@gmail.com>
> wrote:
> > Do you think it's better to change the benchmark utility to generate a
> JSON
> > that complies with existing JSON schema or rather write a new schema for
> > that utility?
>
> The schema and parser script should change to adapt to the benchmark
> output.  If the differences between the standard benchout schema and
> malloc schema are minimal then just edit the standard schema.
> Otherwise create a new parser script and schema for malloc.
>
> > Actually I already transferred copyright to FSF for a patch I
> contributed to
> > coreutils a while ago (several years ago actually)... not sure if that's
> > enough
>
> IIRC the FSF agreement is for specific projects, so you may have
> signed the assignment only for coreutils and you may have to sign a
> separate one for glibc.  The friendly FSF clerks at assign@gnu.org
> will be able to answer that question more comprehensively.
>
> Siddhesh
> --
> http://siddhesh.in
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]