On Tuesday, August 17, 2010 07:19:32 SHOO wrote:
> (2010/08/17 20:33), Lars Tandle Kyllingstad wrote:
> > Looks good!
> > 
> > I just have a few small suggestions:
> > 
> > 
> > 1. I'd replace fromMseconds and fromUseconds with fromMilliseconds and fromMicroseconds.  (Mseconds is, strictly speaking, megaseconds...)  And mseconds->milliseconds, useconds->microseconds, etc.

I probably would have just done fromMS() and fromUS() personally. In all the code that I've generally seen, ms is milliseconds, us is microseconds, and ns is nanoseconds. I've never even heard of a megasecond (though I can easily believe that such exists since mega is often used as a unit). But if we're looking for something with clearer names, then I'd argue for fromMilliSec() and from fromMicroSec(). Long function names aren't necessarily a big deal IMHO, but if we can reasonably make them shorter, then we generally should.

- Jonathan M Davis

Looks good.  One small convenience feature I'd like, though, is the ability to do simple microbenchmarks with less boilerplate, something like:

import std.stopwatch, std.stdio;

void main() {
    writeln(timeMillisecond({
        // Do stuff.
    });
}

timeMilliseconds would simply take a void delegate(), time its execution and return the time it takes in milliseconds.  Similar things could be done for timeMicroseconds and timeSeconds.

On Tue, Aug 17, 2010 at 6:43 AM, SHOO <zan77137 at nifty.com> wrote:

> I made the module of the stopwatch, so I suggest it again here.
>
> I suggested a time handling module that I called std.time before. Unfortunately itself was not able to contribute to Phobos for the issue of license. But, an important function was included in it. It is what is the StopWatch suggested this time.
>
> I have some knowledge about machine control engineering. In the field of
> the machine control engineering, the high accuracy time measurement
> often plays an important role.
> For example, the case wants to perform the measurement of the voltage
> with time by millisecond order for feedback control. When it looks like
> it, resolution power is not enough by time acquisition such as C's time
> function in many cases.
>
> Or the high accuracy time measurement is important in the game programming, too. Or in benchmark testing, too.
>
> There is std.perf in Phobos as a module with this role now.
> However, the module is unlisted, and a license doesn't seem to be a
> Boost license, too.
> I did not refer Tango at all about this class and examined and made it
> in my own hand completely.
>
> Here is the module to suggest this time:
>    http://ideone.com/TVw1P
>
> # This module is tested by Windows (real) and Ubuntu (virtual PC).
>
> Please look at it once by all means, and review it.
> I think that I will commit it at 2010-08-22T15:00Z as far as there is
> not serious dissenting opinion.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100817/9164b93e/attachment.html>

Would be great to integrate StopWatch with the hastily written std.date.benchmark.

Andrei

On 08/17/2010 01:19 PM, David Simcha wrote:
> Looks good.  One small convenience feature I'd like, though, is the ability to do simple microbenchmarks with less boilerplate, something like:
>
> import std.stopwatch, std.stdio;
>
> void main() {
>      writeln(timeMillisecond({
>          // Do stuff.
>      });
> }
>
> timeMilliseconds would simply take a void delegate(), time its execution and return the time it takes in milliseconds.  Similar things could be done for timeMicroseconds and timeSeconds.
>
> On Tue, Aug 17, 2010 at 6:43 AM, SHOO <zan77137 at nifty.com <mailto:zan77137 at nifty.com>> wrote:
>
>     I made the module of the stopwatch, so I suggest it again here.
>
>     I suggested a time handling module that I called std.time before.
>     Unfortunately itself was not able to contribute to Phobos for the issue
>     of license. But, an important function was included in it. It is what is
>     the StopWatch suggested this time.
>
>     I have some knowledge about machine control engineering. In the field of
>     the machine control engineering, the high accuracy time measurement
>     often plays an important role.
>     For example, the case wants to perform the measurement of the voltage
>     with time by millisecond order for feedback control. When it looks like
>     it, resolution power is not enough by time acquisition such as C's time
>     function in many cases.
>
>     Or the high accuracy time measurement is important in the game
>     programming, too. Or in benchmark testing, too.
>
>     There is std.perf in Phobos as a module with this role now.
>     However, the module is unlisted, and a license doesn't seem to be a
>     Boost license, too.
>     I did not refer Tango at all about this class and examined and made it
>     in my own hand completely.
>
>     Here is the module to suggest this time:
>     http://ideone.com/TVw1P
>
>     # This module is tested by Windows (real) and Ubuntu (virtual PC).
>
>     Please look at it once by all means, and review it.
>     I think that I will commit it at 2010-08-22T15:00Z as far as there is
>     not serious dissenting opinion.
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

(2010/08/18 3:19), David Simcha wrote:
> Looks good.  One small convenience feature I'd like, though, is the ability to do simple microbenchmarks with less boilerplate, something like:
>
> import std.stopwatch, std.stdio;
>
> void main() {
>      writeln(timeMillisecond({
>          // Do stuff.
>      });
> }
>
> timeMilliseconds would simply take a void delegate(), time its execution and return the time it takes in milliseconds.  Similar things could be done for timeMicroseconds and timeSeconds.
>

I think that it is not the function of the stopwatch.
How about making std.benchmark? :)
There seems to be room for some arguments about the interface.

What else might std.benchmark contain?  I assume the main point of stopwatch will be benchmarking, and I really despise ridiculously fine grained imports like Tango, gtkD or the Tango standard library, where I have to import 30 different modules to accomplish anything useful.

On Tue, Aug 17, 2010 at 3:37 PM, SHOO <zan77137 at nifty.com> wrote:

> (2010/08/18 3:19), David Simcha wrote:
>
>> Looks good.  One small convenience feature I'd like, though, is the ability to do simple microbenchmarks with less boilerplate, something like:
>>
>> import std.stopwatch, std.stdio;
>>
>> void main() {
>>     writeln(timeMillisecond({
>>         // Do stuff.
>>     });
>> }
>>
>> timeMilliseconds would simply take a void delegate(), time its execution and return the time it takes in milliseconds.  Similar things could be done for timeMicroseconds and timeSeconds.
>>
>>
> I think that it is not the function of the stopwatch.
> How about making std.benchmark? :)
> There seems to be room for some arguments about the interface.
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20100817/07b99a10/attachment.html>

The google unittest library largely considers benchmarking as part of unittesting, so if we have some other ideas for unittest tools the benchmark could be bundled with them in e.g. std.unittesting.

Otherwise, I'd rather try to integrate new stuff within existing modules. That's why I put benchmark in std.date.


Andrei

On 08/17/2010 02:47 PM, David Simcha wrote:
> What else might std.benchmark contain?  I assume the main point of stopwatch will be benchmarking, and I really despise ridiculously fine grained imports like Tango, gtkD or the Tango standard library, where I have to import 30 different modules to accomplish anything useful.
>
> On Tue, Aug 17, 2010 at 3:37 PM, SHOO <zan77137 at nifty.com <mailto:zan77137 at nifty.com>> wrote:
>
>     (2010/08/18 3:19), David Simcha wrote:
>
>         Looks good.  One small convenience feature I'd like, though, is the
>         ability to do simple microbenchmarks with less boilerplate,
>         something like:
>
>         import std.stopwatch, std.stdio;
>
>         void main() {
>              writeln(timeMillisecond({
>                  // Do stuff.
>              });
>         }
>
>         timeMilliseconds would simply take a void delegate(), time its
>         execution
>         and return the time it takes in milliseconds.  Similar things
>         could be
>         done for timeMicroseconds and timeSeconds.
>
>
>     I think that it is not the function of the stopwatch.
>     How about making std.benchmark? :)
>     There seems to be room for some arguments about the interface.
>
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

A suggestion for an enhancement would be to have a separate struct which uses RAII to start and stop the stop watch with that struct taking a delegate/function pointer that runs when the stop watch stops. That way, you get properly matched stops automatically, and you can just get it to automatically do whatever it is you want it to do when it's done - like print out the time elapsed. The result is that you can turn the whole usage of the stop watch into a single line of code. I've done similar stuff with stop watch code that I've written in the past, and I found it to be extremely useful.

- Jonathan M Davis

(2010/08/18 5:06), Andrei Alexandrescu wrote:
> The google unittest library largely considers benchmarking as part of unittesting, so if we have some other ideas for unittest tools the benchmark could be bundled with them in e.g. std.unittesting.
>
> Otherwise, I'd rather try to integrate new stuff within existing modules. That's why I put benchmark in std.date.
>
>
> Andrei
>
> On 08/17/2010 02:47 PM, David Simcha wrote:
>> What else might std.benchmark contain? I assume the main point of stopwatch will be benchmarking, and I really despise ridiculously fine grained imports like Tango, gtkD or the Tango standard library, where I have to import 30 different modules to accomplish anything useful.
>>
>> On Tue, Aug 17, 2010 at 3:37 PM, SHOO <zan77137 at nifty.com <mailto:zan77137 at nifty.com>> wrote:
>>
>> (2010/08/18 3:19), David Simcha wrote:
>>
>> Looks good. One small convenience feature I'd like, though, is the ability to do simple microbenchmarks with less boilerplate, something like:
>>
>> import std.stopwatch, std.stdio;
>>
>> void main() {
>> writeln(timeMillisecond({
>> // Do stuff.
>> });
>> }
>>
>> timeMilliseconds would simply take a void delegate(), time its
>> execution
>> and return the time it takes in milliseconds. Similar things
>> could be
>> done for timeMicroseconds and timeSeconds.
>>
>>
>> I think that it is not the function of the stopwatch.
>> How about making std.benchmark? :)
>> There seems to be room for some arguments about the interface.
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com <mailto:phobos at puremagic.com>
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>
>>
>>
>>
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos

In the first place, I temporarily named std.stopwatch, but doubt it. Where is the best place to put this?

I doubt std.date.benchmark's module, too.
It isn't related on date clearly.
Such a false setting is often examined in Phobos.

(2010/08/17 23:23), Michael Parker wrote:
> This is great, but there are issues with QueryPerformanceCounter that I
> think ought to be pointed out if you aren't already aware of them. QPC
> is horribly unreliable
> on some chipsets and, on some systems, when running on multiple cores.
> Both issues are decribed in the MS Knowledge Base,
> with the chipset problem at [1] and the multicore problem at [2]. In the
> latter, pay particular attention to point #4 in the Recommendations
> section.
>
> Starting with Vista, QPC will use the newer High Precision Event Timer [3], if available (which it should be for most systems running Vista or 7), so this becomes less of an issue. But for XP, which is still going to be relevant for a few more years at least, this is a big headache. You can read more about timing issues in the PDF at [4].
>
> If I were going to use this class in a game, I would expect it to take the recommended precautions on XP. Otherwise, I'd just roll my own using timeGetTime.
>
> [1] http://support.microsoft.com/kb/274323
> [2] http://msdn.microsoft.com/en-us/library/ee417693.aspx
> [3] http://en.wikipedia.org/wiki/High_Precision_Event_Timer
> [4] (direct PDF link)
> http://algo2.iti.kit.edu/wassenberg/timing/timing_pitfalls.pdf
>
> On Tue, Aug 17, 2010 at 7:43 PM, SHOO <zan77137 at nifty.com <mailto:zan77137 at nifty.com>> wrote:
>
>     I made the module of the stopwatch, so I suggest it again here.
>
>     I suggested a time handling module that I called std.time before.
>     Unfortunately itself was not able to contribute to Phobos for the issue
>     of license. But, an important function was included in it. It is what is
>     the StopWatch suggested this time.
>
>     I have some knowledge about machine control engineering. In the field of
>     the machine control engineering, the high accuracy time measurement
>     often plays an important role.
>     For example, the case wants to perform the measurement of the voltage
>     with time by millisecond order for feedback control. When it looks like
>     it, resolution power is not enough by time acquisition such as C's time
>     function in many cases.
>
>     Or the high accuracy time measurement is important in the game
>     programming, too. Or in benchmark testing, too.
>
>     There is std.perf in Phobos as a module with this role now.
>     However, the module is unlisted, and a license doesn't seem to be a
>     Boost license, too.
>     I did not refer Tango at all about this class and examined and made it
>     in my own hand completely.
>
>     Here is the module to suggest this time:
>     http://ideone.com/TVw1P
>
>     # This module is tested by Windows (real) and Ubuntu (virtual PC).
>
>     Please look at it once by all means, and review it.
>     I think that I will commit it at 2010-08-22T15:00Z as far as there is
>     not serious dissenting opinion.
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> --
> Mike Parker
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

I have some knowledge about these problems.
However, there is not the tool to measure really correct time by Windows.
It means that Windows have a problem about timeGetTime equally.
Ability of timeGetTime is about 10[ms] order. Besides, its accuracy is
affected by programs to work in background.
In the scene using a highly precise performance counter, the performance
seems to be insufficiency.

I think the problem that QPC has is the defect of OS and machines.

On 08/18/2010 12:26 AM, SHOO wrote:
> In the first place, I temporarily named std.stopwatch, but doubt it. Where is the best place to put this?
>
> I doubt std.date.benchmark's module, too.
> It isn't related on date clearly.
> Such a false setting is often examined in Phobos.

The problem is that std.date should really be std.datetime because it contains date AND time related stuff. Though I agree benchmark is a bit of an odd presence there (it is related to time though), clearly stopwatch is a time thing.

Andrei