[zeromq-dev] Stopwatch

Brian Granger ellisonbg at gmail.com
Wed Jun 9 17:07:52 CEST 2010


Martin,

On Mon, Jun 7, 2010 at 9:24 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> Brian Granger wrote:
>>
>> Hi,
>>
>> It looks like the stopwatch API has been removed from the ZMQ API.
>> While I understand the reasoning behind this, I would like to bring up
>> some reasons we might want to leave it in.  Recently, Nicholas and I
>> were going some timing and benchmarks of the Python bindings.  We were
>> using Python's built-in timing functions and were seeing that the
>> Python bindings were *faster* than the C++.  Obviously, that was
>> silliness, so we switched to using the zmq_stopwatch stuff and got
>> more reasonable timings.  This leads me to think...
>>
>> Because performance benchmarking is such an important part of ZMQ, I
>> think having a consistent and uniform timing capability is important.
>> Otherwise I fear that we will always be comparing apples to oranges.
>> This is especially true of the different language bindings.  Thoughts?
>
> Well, we removed it because 0mq is not intended to be a portability library.

I understand that, but I think the point I am making is a different
one.  Each platform has multiple different ways of doing timing.  If
everyone writes their own timing code for benchmarking 0MQ code, the
benchmarks will be all over the place and mislead people.  Put another
way:

If 0MQ doesn't have a standardized stopwatch API I will have to do one
of the following:

* Report Python benchmarks that are *faster* than C++ (if use Python's
timing functions).
* Copy the old C++ stopwatch code from 0MQ into pyzmq itself.
* Create a new project (as you suggest) for just the stopwatch code
and have the python bindings depend on that project.
* Write my own C++ perf examples that use a timing approach that is
more comparable to what Python does.

Each language binding will be faced with the same issues.

Summary: the timing code should be in 0MQ itself, not for portability,
but for timing uniformity and consistency.  This is why MPI, for
example, includes timing features in its core API.

Cheers,

Brian

> Maybe creating a separate stopwatch project (libzmqstopwatch) would make
> sense?
>
> Martin
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list