[zeromq-dev] Stopwatch

Apps, John john.apps at hp.com
Wed Jun 9 17:18:58 CEST 2010


I really have to agree with Brian here! It has helped tremendously in past porting efforts (OpenVMS, Windows) to have the Stopwatch code there ready to go. It also helped compare fruit with same fruit.

-- John.Apps at hp.com | +491718691813 | http://twitter.com/johnapps --


-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Brian Granger
Sent: Wednesday, June 09, 2010 17:08
To: Martin Sustrik
Cc: 0MQ development list
Subject: Re: [zeromq-dev] Stopwatch

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 _______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list