Messages in this thread | | | Date | Fri, 26 Oct 2012 12:04:10 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 01/16] math128: Introduce various 128bit primitives |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, 2012-10-26 at 11:42 +0200, Ingo Molnar wrote: > > * Peter Zijlstra <peterz@infradead.org> wrote: > > > > > On Fri, 2012-10-26 at 11:24 +0200, Ingo Molnar wrote: > > > > > > > So can we control this by restricting the users and avoiding > > > > the overflow? > > > > > > > > A 2^64 result should be a *huge* amount of space already for > > > > just about anything. > > > > > > I _think_ something like: dl_runtime * dl_deadline < U64_MAX, > > > might do that. The question is, is this constraint usable? > > > Simplified that boils down to about 4 seconds each, which > > > sounds pretty much ok for most people -- but such statements > > > usually come back to bite you (640kb anybody...). > > > > We could constrain the precision, not the maximum value. > > > > Having a 4 seconds hard limit is one thing, only having 10 nsecs > > precision at 40 seconds is another. > > That gets to be rather ugly I think.. for one it might > surprise people, secondly you get to have a bunch of > conditionals and shifts in that code path.
I don't think a limitation of precision to about 64 bits is a "surprise": it's high grade precision of 0.00000005 parts per trillion...
( As a comparison, there's ~13 parts per trillion amount of pure gold dissolved in ocean water. )
> Personally I'd prefer to do the simple thing, esp. for a new > interface. So either do the hard limit or the u128 thing.
Given that the u128 thing, once it gets converted to machine instructions, is not simple *at all*, that leaves us with the hard limit.
> If we go with the hard limit, we can always address things > when people run into it and complain, at such a time we also > have a better view of people's uses and expectations methinks.
Indeed.
Thanks,
Ingo
| |