Re: [boost] [gsoc 2013] draft proposal for chrono::date

Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-04 10:46:00

Le 04/05/13 15:29, Rob Stewart a écrit :
> On May 4, 2013, at 8:39 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>
>> Le 04/05/13 14:32, Rob Stewart a écrit :
>>> On May 3, 2013, at 7:05 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>>>
>>>> Le 03/05/13 19:53, Howard Hinnant a écrit :
>>>>> On May 3, 2013, at 1:46 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>>>> The UB is when you need to build a date if the day is not on the range. E.g. the implementation could use some arrays indexed with the day and access memory that has no sense.
>>>> If we are sure that a day is in the range 1..31, this kind of assumptions can be done on the implementation. The implementation could not do it if the day value has not been validated previously or behavior would be undefined.
>>> You can apply the same range checking in the date constructor as you intended for the day, month, and year constructors. There is no difference in performance, since the same checking is done.
>>>
>> Yes, there is one. When using constant/constexpr objects there is no need to validate at runtime its validity, they are valid by definition at compile time.
> OK, but is that level of performance worth worrying about?
>
>
This is the question. In the best case (all the date parts have already 
validated they are in range) we can make 6 comparison less.

Accessing a year_month cache would mean two comparison plus the access 
itself (an two dimension array). We need an additional comparison to 
check if the day is a valid day for the year/month before adding it to 
the days since the year/month obtained from the cache.

I suspect that this could take around the twice the 6 comparison time 
(but I'm not good on performance estimation), which would mean a loss of 
30%.

Of course, I see what I need to do, check what the compiler generates :( 
If as a result of this analysis the gain is less than 30%, I would move 
to let the validation of the date parts to the validated date build. 
This would mean no need for the no_check overloads for day(3) and  
year(2015).

Best,
Vicente