[system][timer] CPU timer first draft
After years of procrastination, I've finally put together the CPU timer I've always wanted. It provides wall-clock time, user CPU time, and system CPU time. A time reporter class handles the details of display. Typical output would be: wall 0.50 s, user 0.03 s, system 0.05 s, total cpu 0.08 s, 15.6% The percentage is CPU utilization relative to wall clock. Note that I see a CPU timer as complementary rather than competitive to the high-precision timer component others are working on. I'm all for their effort to continue. My plan is to submit the CPU timer stuff as part of a Boost.System library, which packages small operating system dependent components together for convenience. There is an early version of Boost.System stuff in the vault. Go to the System directory at http://boost-consulting.com/vault/ to download system-0.1.zip. The preliminary CPU timer docs can be viewed online at http://mysite.verizon.net/beman/cpu_timer.html. Note that I did use Boost.Date_Time components. That was because I'm not very familiar with Boost.Date_Time, and wanted to initially concentrate on getting the desired results. Advice on how to best make use of Boost.Date_Time would be appreciated. Likewise, any other comments are welcome. --Beman
Beman Dawes wrote:
After years of procrastination, I've finally put together the CPU timer I've always wanted. It provides wall-clock time, user CPU time, and
A few thoughts: 1) long long isn't portable -- use boost::int64_t instead 2) get_process_times compile fails on Linux -- fairly obvious issue here...I'm guessing you are testing on Windows :-) cpu_timer.cpp:86: error: ‘m_wall’ was not declared in this scope cpu_timer.cpp:87: error: ‘m_user’ was not declared in this scope cpu_timer.cpp:88: error: ‘m_system’ was not declared in this scope cpu_timer.cpp:90: error: ‘m_wall’ was not declared in this scope cpu_timer.cpp:90: error: ‘m_user’ was not declared in this scope cpu_timer.cpp:90: error: ‘m_system’ was not declared in this scope cpu_timer.cpp: At global scope: # if defined(BOOST_WINDOWS_API) //...snip.... # else tms tm; clock_t c = ::times( &tm ); if ( c == -1 ) // error { wall = system = user = -1; } else { wall = c; system = tm.tms_stime + tm.tms_cstime; user = tm.tms_utime + tm.tms_cutime; if ( tick_factor() != -1 ) { wall -= m_wall; wall *= tick_factor(); user -= m_user; user *= tick_factor(); system -= m_system; system *= tick_factor(); } else { m_wall = m_user = m_system = -1; } } } # endif } 3) I see some major overlap in your plans with Boost.Process. You are providing what amounts to a a simplified form of what I what Julio is doing in his SOC project. You might have a look at Julio's current design page and provide feedback: https://boost-consulting.com:8443/trac/soc/wiki/process/DesignThoughts I believe he would treat the various times you are measuring as attributes of the process class. So the code would be something like: bp::cmdline cl("...do something..."); bp::generic_attributes attrs(cl); bp::launcher l(attrs); bp::child c = l.start(); while (!c.exited()) { time_duration wall = attrs.wall; time_duration user = attrs.user; ... }; 4) Eating exceptions: I don't like this code. I've been burned a few times by code that does eats exceptions.... // A) Throwing an exception from a destructor is a Bad Thing, // and report() will often be called from destructors // B) The destructor does output, and that may throw. // C) A cpu_time_reporter is usually not critical to the application. // Therefore, wrap the I/O in a try block, catch and ignore all exceptions. try { show_time( m_format.empty() ? "\nwall %w s, user %u s, system %s s, total cpu %t s, %p%\n" : m_format.c_str(), m_places, m_os, this->wall(), this->user(), this->system() ); } catch (...) {} // eat any exceptions }
system CPU time. A time reporter class handles the details of display. Typical output would be:
wall 0.50 s, user 0.03 s, system 0.05 s, total cpu 0.08 s, 15.6%
The percentage is CPU utilization relative to wall clock.
Note that I see a CPU timer as complementary rather than competitive to the high-precision timer component others are working on. I'm all for their effort to continue.
I'm not so sure, but I agree we should continue on both tracks for awhile.
My plan is to submit the CPU timer stuff as part of a Boost.System library, which packages small operating system dependent components together for convenience.
For the moment, I mostly see things that overlap other current library efforts -- error codes excepted. That said, I really applaud the effort. In my view, Boost has being a piecemeal design OS api portability -- as an example, we have 3 libraries that retrieve clock time values from the system clock (thread, date-time, timer). I really think we would make a major advance if Boost.system would be focused on providing a 'low-level' portable API and then all the 'higher layer' libraries could use the elements of Boost.system that they need. This would be kinda like Boost.Config at the system api level. Then Boost.system would be the first point of porting Boost to new platforms. There are some issues. Some libraries need their portability functions to be all header -- others might prefer a library based approach. At what point do we add to Boost.system as opposed to providing the function in the the library -- like the filesystem code? And, of course, code gets more scattered around in the boost tree.
Note that I did use Boost.Date_Time components. That was because I'm not ^^^^ missing a not very familiar with Boost.Date_Time, and wanted to initially concentrate on getting the desired results. Advice on how to best make use of Boost.Date_Time would be appreciated.
Overall, the intent of the Boost.date_time types is to be efficient wrappers around core types (eg: integers) that provide the additional functions you would expect in a time representation. You could probably replace your microseconds_t type with boost::posix_time::microseconds with little or no loss of efficiency. By returning a microseconds from functions like wall() the user can use the date-time streaming operators directly including the output formatting strings associated with time duration. I believe this would also eliminate the the double-based precision issues in the I/O code. One problem I see is that date-time doesn't have an easy way to do set-precision on i/o...something it probably needs. Anyway, once you have a version that compiles on Linux I can take a shot at replacing this and seeing what happens... Jeff
Jeff Garland wrote:
Beman Dawes wrote:
After years of procrastination, I've finally put together the CPU timer I've always wanted. It provides wall-clock time, user CPU time, and
A few thoughts:
1) long long isn't portable -- use boost::int64_t instead
OK, changed in my copy.
2) get_process_times compile fails on Linux -- fairly obvious issue here...I'm guessing you are testing on Windows :-)
Fixed. Vault .zip updated. Yes, I was testing mostly on Windows. I tested on a Mac, and then forgot to retest after making some changes. It is working now on my Mac, but I don't have a running Linux system to test on.
3) I see some major overlap in your plans with Boost.Process. You are providing what amounts to a a simplified form of what I what Julio is doing in his SOC project. You might have a look at Julio's current design page and provide feedback:
https://boost-consulting.com:8443/trac/soc/wiki/process/DesignThoughts
I believe he would treat the various times you are measuring as attributes of the process class. So the code would be something like:
bp::cmdline cl("...do something..."); bp::generic_attributes attrs(cl);
bp::launcher l(attrs); bp::child c = l.start();
while (!c.exited()) { time_duration wall = attrs.wall; time_duration user = attrs.user; ... };
The interface for my example is one line of code: boost::system::cpu_time_reporter tr; So while it might be implemented using Julio's process design, cpu_time_reporter provides a completely packaged solution. Unless I missed something (always possible!), I don't see process as providing the same thing.
4) Eating exceptions:
I don't like this code. I've been burned a few times by code that does eats exceptions....
Throwing exceptions from destructors is usually considered a no-no. Note that it is possible to use explicit calls to stop() etc., and detect that an error occurred. I guess someone could make a case that exceptions should be thrown except in the destructor. I'll have to think about that.
system CPU time. A time reporter class handles the details of display. Typical output would be:
wall 0.50 s, user 0.03 s, system 0.05 s, total cpu 0.08 s, 15.6%
The percentage is CPU utilization relative to wall clock.
Note that I see a CPU timer as complementary rather than competitive to the high-precision timer component others are working on. I'm all for their effort to continue.
I'm not so sure, but I agree we should continue on both tracks for awhile.
My plan is to submit the CPU timer stuff as part of a Boost.System library, which packages small operating system dependent components together for convenience.
For the moment, I mostly see things that overlap other current library efforts -- error codes excepted. That said, I really applaud the effort. In my view, Boost has being a piecemeal design OS api portability -- as an example, we have 3 libraries that retrieve clock time values from the system clock (thread, date-time, timer).
timer should be retired. threads should use date-time facilities. If cpu_timer is better implemented by calling date-time or process, that is OK with me, but I really like the simple cpu_timer and cpu_time_reporter interfaces. A user should not have to master a complex library just to write what amounts to one line of code.
I really think we would make a major advance if Boost.system would be focused on providing a 'low-level' portable API and then all the 'higher layer' libraries could use the elements of Boost.system that they need. This would be kinda like Boost.Config at the system api level. Then Boost.system would be the first point of porting Boost to new platforms.
There are some issues. Some libraries need their portability functions to be all header -- others might prefer a library based approach. At what point do we add to Boost.system as opposed to providing the function in the the library -- like the filesystem code? And, of course, code gets more scattered around in the boost tree.
Well, the error encapsulation really doesn't fit in any other single library, so at that point the camel's nose is under the tent and so we might as well acknowledge "system" as a small library and see what else fits into it, I think.
Note that I did use Boost.Date_Time components. That was because I'm not ^^^^ missing a not very familiar with Boost.Date_Time, and wanted to initially concentrate on getting the desired results. Advice on how to best make use of Boost.Date_Time would be appreciated.
Overall, the intent of the Boost.date_time types is to be efficient wrappers around core types (eg: integers) that provide the additional functions you would expect in a time representation. You could probably replace your microseconds_t type with boost::posix_time::microseconds with little or no loss of efficiency. By returning a microseconds from functions like wall() the user can use the date-time streaming operators directly including the output formatting strings associated with time duration. I believe this would also eliminate the the double-based precision issues in the I/O code.
That sounds like an improved way to implement cpu_time_reporter, and offers other user benefits too, I would guess.
One problem I see is that date-time doesn't have an easy way to do set-precision on i/o...something it probably needs.
My guess is that control over precision is something users really will want.
Anyway, once you have a version that compiles on Linux I can take a shot at replacing this and seeing what happens...
That would be great! The refreshed .zip should work for Linux; if not let me know. Thanks, --Beman
Beman Dawes wrote:
Jeff Garland wrote:
Beman Dawes wrote:
2) get_process_times compile fails on Linux -- fairly obvious issue here...I'm guessing you are testing on Windows :-)
Fixed. Vault .zip updated.
Yes, I was testing mostly on Windows. I tested on a Mac, and then forgot to retest after making some changes. It is working now on my Mac, but I don't have a running Linux system to test on.
I've posted a couple other changes in a new thread.
3) I see some major overlap in your plans with Boost.Process. You are providing what amounts to a a simplified form of what I what
...snip details...
The interface for my example is one line of code:
boost::system::cpu_time_reporter tr;
So while it might be implemented using Julio's process design, cpu_time_reporter provides a completely packaged solution. Unless I missed something (always possible!), I don't see process as providing the same thing.
No it doesn't. Are you saying the process_exec isn't going to be part of the system api? That's the part the overlaps..
4) Eating exceptions:
I don't like this code. I've been burned a few times by code that does eats exceptions....
Throwing exceptions from destructors is usually considered a no-no. Note that it is possible to use explicit calls to stop() etc., and detect that an error occurred.
I guess someone could make a case that exceptions should be thrown except in the destructor. I'll have to think about that.
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions: void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
My plan is to submit the CPU timer stuff as part of a Boost.System library, which packages small operating system dependent components together for convenience. For the moment, I mostly see things that overlap other current library efforts -- error codes excepted. That said, I really applaud the effort. In my view, Boost has being a piecemeal design OS api portability -- as an example, we have 3 libraries that retrieve clock time values from the system clock (thread, date-time, timer).
timer should be retired. threads should use date-time facilities. If cpu_timer is better implemented by calling date-time or process, that is OK with me, but I really like the simple cpu_timer and cpu_time_reporter interfaces. A user should not have to master a complex library just to write what amounts to one line of code.
I guess I should have made it clear that I like the cpu timer interface -- it's certainly valuable. And I totally agree that we want simple things to be simple. I'm mostly commenting on the broader purpose of System and what should be contained in it. See below for more...
Well, the error encapsulation really doesn't fit in any other single library, so at that point the camel's nose is under the tent and so we might as well acknowledge "system" as a small library and see what else fits into it, I think.
Yep. Again my thought is that it would be the collector for an OS portability layer. So you might have something like: system/time.hpp system/process.hpp system/thread.hpp system/file.hpp system/posix_impl/time.hpp system/win32_impl/time.hpp .... Of course, that make cpu timer somewhat questionable as an element of the system library -- it would need to be an add-on.
By returning a microseconds from functions like wall() the user can use the date-time streaming operators directly including the output formatting strings associated with time duration. I believe this would also eliminate the the double-based precision issues in the I/O code.
That sounds like an improved way to implement cpu_time_reporter, and offers other user benefits too, I would guess.
I think so.
One problem I see is that date-time doesn't have an easy way to do set-precision on i/o...something it probably needs.
My guess is that control over precision is something users really will want.
It hasn't come up yet, but I've been expecting it to.... Jeff
Jeff Garland wrote:
Beman Dawes wrote:
Jeff Garland wrote:
Beman Dawes wrote: 2) get_process_times compile fails on Linux -- fairly obvious issue here...I'm guessing you are testing on Windows :-) Fixed. Vault .zip updated.
Yes, I was testing mostly on Windows. I tested on a Mac, and then forgot to retest after making some changes. It is working now on my Mac, but I don't have a running Linux system to test on.
I've posted a couple other changes in a new thread.
Thanks! I've applied those fixes. ... Are you saying the process_exec isn't going to be part of the
system api? That's the part the overlaps..
process_exec? That wasn't supposed to be included in the .zip file. It was an experiment that failed. Sorry it slipped in.
4) Eating exceptions:
I don't like this code. I've been burned a few times by code that does eats exceptions.... Throwing exceptions from destructors is usually considered a no-no. Note that it is possible to use explicit calls to stop() etc., and detect that an error occurred.
I guess someone could make a case that exceptions should be thrown except in the destructor. I'll have to think about that.
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions:
void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
Yes, that's the idea, although the actual implementation might differ. For the functions that where changed to possibly throw, there should also be non-throwing versions available. Good. That will be another use case for system_error etc.
...
I guess I should have made it clear that I like the cpu timer interface -- it's certainly valuable. And I totally agree that we want simple things to be simple. I'm mostly commenting on the broader purpose of System and what should be contained in it. See below for more...
Well, the error encapsulation really doesn't fit in any other single library, so at that point the camel's nose is under the tent and so we might as well acknowledge "system" as a small library and see what else fits into it, I think.
Yep. Again my thought is that it would be the collector for an OS portability layer. So you might have something like:
system/time.hpp system/process.hpp system/thread.hpp system/file.hpp system/posix_impl/time.hpp system/win32_impl/time.hpp ....
Interesting. I want to come back to this in another post. The question is one of degree. I think that is important, but don't have time to delve into it now.
Of course, that make cpu timer somewhat questionable as an element of the system library -- it would need to be an add-on.
Just because a library is primarily aimed as OS portability, that doesn't mean it can't have convenience functions or classes layered on top of the lower-level stuff.
By returning a microseconds from functions like wall() the user can use the date-time streaming operators directly including the output formatting strings associated with time duration. I believe this would also eliminate the the double-based precision issues in the I/O code. That sounds like an improved way to implement cpu_time_reporter, and offers other user benefits too, I would guess.
I think so.
One problem I see is that date-time doesn't have an easy way to do set-precision on i/o...something it probably needs. My guess is that control over precision is something users really will want.
It hasn't come up yet, but I've been expecting it to....
I really think that being able to control precision is important. For many platforms and applications, anything more that one or two decimal places is misleading, unnecessary, and unwanted. OTOH, some platforms and/or applications may benefit from more decimal places, and I'd like to allow that sort of control if the user desires. Thanks, --Beman
Jeff Garland wrote:
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions:
void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
Or how about: void cpu_time_reporter::report(std::nothrow_t)throw() ? It's situations like this that we have std::nothrow for isn't it? Just a thought. John.
John Maddock wrote:
Jeff Garland wrote:
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions:
void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
Or how about:
void cpu_time_reporter::report(std::nothrow_t)throw() ?
It's situations like this that we have std::nothrow for isn't it?
Just a thought.
Yeah, that's a good idea :-) Jeff
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:012c01c69900$308fd4a0$b10d1452@fuji...
Jeff Garland wrote:
Well, you're assuming that report will be called in a destructor. If it isn't and some sort of exception is thrown then the application can't handle it because you've eaten it. You could always have 2 versions:
void cpu_time_reporter::report_no_exceptions() throws() void cpu_time_reporter::report()
Or how about:
void cpu_time_reporter::report(std::nothrow_t)throw() ?
It's situations like this that we have std::nothrow for isn't it?
Just a thought.
I'm going to refine and apply the error handling guidelines I posted a while ago to cpu_timer/cpu_timer_reporter. Your post gives me an idea for a further refinement: There are three useful behaviors, depending on the app, for functions that may encounter an operating system API error: 1. Throw an exception. 2. Report the error by setting a error_code & argument to the error code. 3. Ignore the error. I suggest folding 2 and 3 into a single case by just proving (2), since the caller is free to ignore whatever the error_code & gets set to, and that effectively is the same as (3). It is a bit inconvenient to use, because the users has to declare an otherwise unneeded variable as the target for returning the error_code. But suppose we provided: namespace boost { extern error_code nothrow; } Then the user can get the effect of (3) by writing: boost::system::cpu_time_reporter tr( boost::nothrow ); --Beman
Beman Dawes wrote:
That would be great! The refreshed .zip should work for Linux; if not let me know.
Couple last issues. Compiling error_code.cpp although it's apparently not actually needed for the cpu_timer test: ../../../boost/system/error_code.hpp:152: error: no ‘boost::system::errno_t boost::system::error_code::erno_value() const’ member function declared in class ‘boost::system::error_code’ inline errno_t error_code::erno_value() const ^^^^^^^ inline errno_t error_code::errno_value() const error_code.cpp: In function ‘void boost::system::system_message(boost::system::error_code, std::string&)’: error_code.cpp:234: error: ‘sys_err_code’ was not declared in this scope Change error_code.cpp::235 to target += std::strerror( ec.sysno_value() ); Jeff
Beman Dawes wrote:
Jeff Garland wrote:
Beman Dawes wrote:
Anyway, once you have a version that compiles on Linux I can take a shot at replacing this and seeing what happens...
That would be great! The refreshed .zip should work for Linux; if not let me know.
I've uploaded a quickly done version using date-time types to the vault under System: http://boost-consulting.com/vault/index.php?direction=0&order=&directory=System& I mostly did the minimal set of changes, but if I was doing a complete job I would want to change some of the implementation. For example, I wouldn't want to handle an error in the call to the clock by setting the elapsed to -1. Also, I'd probably redo the interfaces all in terms of time_duration and then use milliseconds when I know the time base is actually in terms of milliseconds (I did that sortof half way). As for i/o, I just did the expedient thing and used the operator<< for time duration which prints in the form: HH::MM::SS.ffffffff Oh and I didn't even mess with the windows side of things. I'm out of time for now, but hopefully this will provide some food for thought and discussion. Jeff
On 6/25/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
3) I see some major overlap in your plans with Boost.Process. You are providing what amounts to a a simplified form of what I what Julio is doing in his SOC project. You might have a look at Julio's current design page and provide feedback:
https://boost-consulting.com:8443/trac/soc/wiki/process/DesignThoughts
I believe he would treat the various times you are measuring as attributes of the process class. So the code would be something like:
bp::cmdline cl("...do something..."); bp::generic_attributes attrs(cl);
bp::launcher l(attrs); bp::child c = l.start();
while (!c.exited()) { time_duration wall = attrs.wall; time_duration user = attrs.user; ... };
With the current design, one'd even do something like the following to measure the run time of the current process (as the original proposal does if I understood it correctly): bp::process p = bp::process.self(); // Or something like that; you get the idea. bp::attributes a = p.get_attributes(); // Now deal with the time attributes in a. Cheers, -- Julio M. Merino Vidal <jmmv84@gmail.com> The Julipedia - http://julipedia.blogspot.com/
On Sun, 25 Jun 2006 10:00:46 -0400, Beman Dawes <bdawes@acm.org> wrote:
After years of procrastination, I've finally put together the CPU timer I've always wanted. It provides wall-clock time, user CPU time, and system CPU time. A time reporter class handles the details of display. Typical output would be:
wall 0.50 s, user 0.03 s, system 0.05 s, total cpu 0.08 s, 15.6%
The percentage is CPU utilization relative to wall clock.
Note that I see a CPU timer as complementary rather than competitive to the high-precision timer component others are working on. I'm all for their effort to continue.
My plan is to submit the CPU timer stuff as part of a Boost.System library, which packages small operating system dependent components together for convenience.
It seems that everyone is writing timers in this period :) I've my implementation too, resulting from preliminary off-list discussion with Pavel Vozenilek. It's similar to yours but I was not happy with the interface, and also wanted to make it interoperable with Boost.Date_Time without actually coupling with it. I appreciate a lot the enormous amount of work you are doing on this and other proposals (and it seems you are writing code faster than I can even comment on it :)) but I'm afraid this time we should refrain from submitting a component for which there's no existing practice. It can always be included later, even if criteria for inclusion will be much stricter. --Gennaro.
Gennaro Prota wrote:
On Sun, 25 Jun 2006 10:00:46 -0400, Beman Dawes <bdawes@acm.org> wrote:
It seems that everyone is writing timers in this period :) I've my implementation too, resulting from preliminary off-list discussion with Pavel Vozenilek. It's similar to yours but I was not happy with the interface,
Which interface?
and also wanted to make it interoperable with Boost.Date_Time without actually coupling with it.
Well, this can certainly be done but is it really worth it? From what I can see you basically end up with something requiring 3 template parameters instead of one (time type, duration type, clock type). Clock type is the one that's really necessary to allow for different implementations of time measurement. Is the coupling with date-time really so extreme? Everything you need for the timers is all header inline. Have you looked at: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=date_time As for the interface, I'm almost amused that this pretty much trivial interface continues to bring discussion. The timer proposal that's in the vault now had the interface discussed at some length (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer) for some links. The sketch for this is: class timer { timer(time_duration initial_duration = time_duration(0,0,0), START_OPTION start_op = AUTO_START); void start(); void restart() ; time_duration elapsed() const; void pause(); void resume(); void reset(); }; Now I appreciate that what Beman is trying to do is slightly different so what he wants from the elapsed call doesn't match up. That said, I'm not sure that there needs to be so much variation in the rest of the interface. Jeff
"Jeff Garland" wrote
As for the interface, I'm almost amused that this pretty much trivial interface continues to bring discussion. The timer proposal that's in the vault now had the interface discussed at some length (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer) for some links. The sketch for this is:
class timer { timer(time_duration initial_duration = time_duration(0,0,0), START_OPTION start_op = AUTO_START);
void start(); void restart() ; time_duration elapsed() const; void pause(); void resume(); void reset(); };
FWIW I thought I should add my own timer efforts. None too serious, but the unique (AFAICS) feature is that you can select different time units: Its in <boost/pqs/utility/timer.hpp> and looks like this( This version moved to quan namespace) : amespace quan{ template <typename TimeType = quan::time::ms> class timer{ public: timer(); void restart(); void stop() ; TimeType operator ()()const; bool is_running() const ; bool is_stopped() const; }; }//quan int main() { int const num_loops=10; quan::timer<quan::time::ms> t; // construction starts timing for(int j = 0; j < num_loops; ++j){ /*...*/ } t.stop(); std::cout << t() << "\n"; } regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:e7o8mn$2pn$1@sea.gmane.org...
"Jeff Garland" wrote
As for the interface, I'm almost amused that this pretty much trivial interface continues to bring discussion. The timer proposal that's in the vault now had the interface discussed at some length (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?GDTL/Timer) for some links. The sketch for this is:
class timer { timer(time_duration initial_duration = time_duration(0,0,0), START_OPTION start_op = AUTO_START);
void start(); void restart() ; time_duration elapsed() const; void pause(); void resume(); void reset(); };
Is their any reason that one couldnt allow different implementations? timer<time_duration> garland_timer; timer<boost::system::microsends_t> dawes_timer; timer<pqs::time::ms> andy_timer; timer<my::time_type> my_timer; regards Andy Little
Andy Little wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:e7o8mn$2pn$1@sea.gmane.org...
Is their any reason that one couldnt allow different implementations?
timer<time_duration> garland_timer; timer<boost::system::microsends_t> dawes_timer; timer<pqs::time::ms> andy_timer; timer<my::time_type> my_timer;
No, I'm certain I can make a policy based timer 'swiss army knife' timer that would allow you to swap out the guts with whatever you want. But, honestly, I think it's not worth the time it would take. But if you're moved to write it, be my guest. Jeff
"Jeff Garland" wrote
Andy Little wrote:
"Andy Little" wrote
Is their any reason that one couldnt allow different implementations?
timer<time_duration> garland_timer; timer<boost::system::microsends_t> dawes_timer; timer<pqs::time::ms> andy_timer; timer<my::time_type> my_timer;
No, I'm certain I can make a policy based timer 'swiss army knife' timer that would allow you to swap out the guts with whatever you want. But, honestly, I think it's not worth the time it would take. But if you're moved to write it, be my guest.
Not really, but I hope I can make this work sometime (nb:quan was boost::pqs) : quan::timer<quan::time::us> timer; boost::posix_time::time_duration td = timer(); regards Andy Little
On Sun, 25 Jun 2006 17:11:19 -0700, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Gennaro Prota wrote:
On Sun, 25 Jun 2006 10:00:46 -0400, Beman Dawes <bdawes@acm.org> wrote:
It seems that everyone is writing timers in this period :) I've my implementation too, resulting from preliminary off-list discussion with Pavel Vozenilek. It's similar to yours but I was not happy with the interface,
Which interface?
Mine.
and also wanted to make it interoperable with Boost.Date_Time without actually coupling with it.
Well, this can certainly be done but is it really worth it?
I don't know. I'm not very knowledgeable about the date_time library, which is one of the reasons why I postponed the issue.
[...]
As for the trivial interface bringing discussion, due to reasons absolutely beyond me I've been away from this list for two years. You may have noticed that I'm reproposing things which were preliminarily submitted in 2004, for instance. Hoping next time I'll amuse you with a quip rather than supposedly technical discussion. --Gennaro.
Gennaro Prota wrote:
On Sun, 25 Jun 2006 17:11:19 -0700, Jeff Garland
and also wanted to make it interoperable with Boost.Date_Time without actually coupling with it. Well, this can certainly be done but is it really worth it?
I don't know. I'm not very knowledgeable about the date_time library, which is one of the reasons why I postponed the issue.
Ok, well there's been 'a strategy' that we should do some minor interface upgrades and add some higher resolution timers to the timer library. The strategy was to incorporate into date-time using date-time types. It's been on my todo list, for well, too long. Then others started working on this in seemingly divergent directions...
[...]
As for the trivial interface bringing discussion, due to reasons absolutely beyond me I've been away from this list for two years. You may have noticed that I'm reproposing things which were preliminarily submitted in 2004, for instance. Hoping next time I'll amuse you with a quip rather than supposedly technical discussion.
Sounds good ;-) Jeff
Gennaro Prota wrote:
On Sun, 25 Jun 2006 10:00:46 -0400, Beman Dawes <bdawes@acm.org> wrote:
After years of procrastination, I've finally put together the CPU timer I've always wanted. It provides wall-clock time, user CPU time, and system CPU time. A time reporter class handles the details of display. Typical output would be:
wall 0.50 s, user 0.03 s, system 0.05 s, total cpu 0.08 s, 15.6%
The percentage is CPU utilization relative to wall clock.
Note that I see a CPU timer as complementary rather than competitive to the high-precision timer component others are working on. I'm all for their effort to continue.
My plan is to submit the CPU timer stuff as part of a Boost.System library, which packages small operating system dependent components together for convenience.
It seems that everyone is writing timers in this period :) I've my implementation too, resulting from preliminary off-list discussion with Pavel Vozenilek. It's similar to yours but I was not happy with the interface, and also wanted to make it interoperable with Boost.Date_Time without actually coupling with it.
I appreciate a lot the enormous amount of work you are doing on this and other proposals (and it seems you are writing code faster than I can even comment on it :)) but I'm afraid this time we should refrain from submitting a component for which there's no existing practice. It can always be included later, even if criteria for inclusion will be much stricter.
I'm not sure if we are talking about the same thing. The cpu_timer proposal is just for Boost, and Boost often is well ahead of existing practice. That was part of the rationale for starting Boost. The process is to first get informal comments (which is what this thread is all about), make revisions based on those comments, and then submit the library to Boost for formal review. Nothing unusual there. Put another way, cpu_timer is just a wrapper around POSIX times() or Windows GetProcessTimes(). cpu_time_reporter is a convenience wrapper around cpu_timer. These underlying functions have been existing practice for decades. All we are talking about here is the most appropriate way to interface to them in a portable way. There is no intent to try to meet other timer needs. There is also discussion going on about more general questions regarding a "system" or portability library. Having specific proposals for such a library gives the discussion real library use cases to focus the discussion. --Beman
On Sun, 25 Jun 2006 21:41:17 -0400, Beman Dawes <bdawes@acm.org> wrote:
I'm not sure if we are talking about the same thing. The cpu_timer proposal is just for Boost
Sorry Beman, I guess my mind has had some issue with all the context switching required by ongoing discussions: I thought it was for TR2. My bad. --Gennaro.
participants (6)
-
Andy Little -
Beman Dawes -
Gennaro Prota -
Jeff Garland -
John Maddock -
Julio M. Merino Vidal