This is the mail archive of the libc-alpha@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: Benchmark for sem_timedwait v1.1


On 26 February 2014 19:28, OndÅej BÃlka <neleai@seznam.cz> wrote:
> Its artificial, you could add always add additional parameter, or for
> general benchmark take a string as argument, then call system on it and
> require that string be something like "echo 'code' > test.c; gcc test.c; ./a.out"

It is not artificial and it is definitely not something that the
framework was not intended to do.  I've hacked up a quite example that
does exactly what your test does, but within the framework - see the
branch siddhesh/sem_timedwait.

It needs one additional feature to the framework, which is the ability
to define an initialization function; something that I should have
added ages ago.  Other than that it has exactly what i had mentioned -
a benchmark input file that has two variants (which is your
requirement) to the scenario being benchmarked and a source file that
has a function with the initializer and the scenario.

I've not posted these patches because I'm waiting for Mike's review of
the benchmark conversion to python.  I will post them once that is
done.

>> This particular benchmark you posted does not spawn threads; it only
>> calls a set of functions.  I agree that in most cases (not necessarily
>> all though) that involve spawning threads and measuring events across
>> threads, bench-skeleton would be a bad fit.
>>
> As that would eventually happens and even now there is notrivial code
> for setup there is no point in trying to fix a
> round cube to square holes.

I don't understand what you're trying to say.

Siddhesh
-- 
http://siddhesh.in


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