[D-runtime] druntime commit, revision 410

[Fawzi Mohamed]

On 5-nov-10, at 18:59, Sean Kelly wrote:

> On Nov 5, 2010, at 9:12 AM, Fawzi Mohamed wrote:
>
>> On 5-nov-10, at 15:06, Sean Kelly wrote:
>>
>>> On Nov 4, 2010, at 6:43 PM, Jonathan M Davis wrote:
>>>>
>>>> Looking at core.time, I'd really suggest just moving over  
>>>> std.datetime.Duration
>>>> to core.time along with TickDuration, FracSec, and the dur!()  
>>>> function for
>>>> creating Durations, possibly along with some of the helper  
>>>> functions (which I
>>>> believe are primarily restricted to template constraints).
>>>
>>> Are there still 4 distinct duration types?
>>
>> I really think that using doubles with the number of seconds for  
>> those "normal" usages is really better.
>> That is what NSDate does (Next->Apple), and also libev.
>> QT on the other hand uses a structure similar to the *nix timings,  
>> and Boost/std/tango
>> The advantage of double is that it is a simple type, and introduces  
>> 0 dependencies, and is still flexible enough for most uses.
>
> This would render the -nofloat compiler flag useless, but perhaps  
> that isn't a huge issue.  It was one of the arguments for changing  
> double->long for Thread.sleep() in Tango though.

I don't know it it was changed to a long at some point, but I did  
discuss about it, and advocated a double for these reasons, and it is  
still a double now.
Anyway is there any platform out there where D could probably be  
ported that does not support floating point? thanks to 3D and DSP  
basically all modern processors support it, also in the embedded field  
(read ARM).
Yes there are embedded processors that don't support floats, but I  
don't think that D will target them.
(by the way I said NSDate, but I should have said NSTimeInterval which  
is a double)

>> Using integers one has to somehow give access to the time unit in  
>> some way, and so make the interface more complex.
>> If different timers have different resolution different structures  
>> have to be used.
>> Thus they lead to a more complex interface.
>
> I disagree.  With the Duration code, the call looks like this:
>
>    Thread.sleep(seconds(5) + milliseconds(10))
>
> How is that complex?  Though I'll admit that the double version is  
> pretty straightforward too:

You are right, It is not complex if you use it only for that.
But if later you want to use the same/similar structure for different  
clocks (probably outside the core), then you have problems if the  
other clock has a different resolution.

I thought that having a uniform type outside the druntime was part of  
the reason for choosing Duration.
In that case I find using a floating point number (normally a double)  
as duration is a good choice.

>    Thread.sleep(5.01)
>
> Or the conversion routines could be changed to return a double  
> instead of a Duration:
>
>    double seconds(T)(T val) {
>        return cast(double) val;
>    }
>
> etc.  I'll admit that I'm not absolutely crazy about dealing with  
> doubles inside the wait routines themselves, but this could be  
> solved by the addition of some library functions.  I'd probably  
> basically just rip out Duration and replace it with a bunch of free  
> functions that did essentially the same thing: long hours(double),  
> long nanoseconds(double), long totalNanoseconds(double), etc.

I remember a discussion were also Walter didn't like floating points,  
but to say the truth, I think that sunning them is a thing of the past.
(this has nothing to do with the fact that the clock itself should  
better use integers).

>> Converting various native timers to a double might cost a little  
>> bit, but normally that is not a problem.
>
> Since this will currently only be used for wait routines, the  
> performance impact is irrelevant.