This is the mail archive of the 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: [PATCH v2] benchtests: Add malloc microbenchmark

On Tue, Jun 10, 2014 at 02:25:39AM +0200, OndÅej BÃlka wrote:
> > It does that in bench-malloc.  Or maybe I don't understand what you
> > mean.
> >
> Thread A allocates memory, thread B deallocates. In current
> implementation both will contend same lock.

OK, yes this is not measured, but it could be added on top of the
current benchmark.

> > > Running threads and measuring time after you join them measures a
> > > slowest thread so at end some cores are idle.
> > 
> > How does that matter?
> >
> Because scheduling could make difference. Simple case, you have three
> threads and two cores each takes unit time. If you run two threads in
> parallel then total time is two units. If you run half of A and B then
> half of B and C and then half of A and C then you could finish in 1.5
> units.

OK, measuring at individual threads should alleviate this.

> No, there is simple reason for that. If you run a multithread program
> you need to take number of cores into account?

Yes, the number of cores is in fact very important, thanks for pointing
out.  Simply recording it in the results should be a good start.

> > It would be a concern if we were measuring memory usage over time.
> > Looking at just maximum usage does not have that problem.
> >
> No, its problem even with maximum usage, why do you thing it is
> different?
> When you do hundred allocations of size A, then hundred of size B, then
> free all A and do hundred allocations of size C it is more memory
> friendly than if you mixed allocations of A, B with frees from A.

OK, I misunderstood your point again, or maybe you can tell me if I
did.  I was referring to maximum usage as a general measure given that
allocation pattern is fixed while you're referring to comparison of
maximum usage given different allocation patterns.  Given that the
random number is not seeded, the test should create a constant
allocation pattern.


Attachment: pgppV7tRajxcd.pgp
Description: PGP signature

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