Re: microseconds ought to be enough for anybody
Hi, # I'm not an expart of data/time, timer precision or anything. but, # working with some embedded systems. so I might be biased by that. At Mon, 01 Nov 2010 12:06:48 -0400, Ryan Lortie wrote: > > - microseconds ought to be enough for anybody > > A nanosecond is on the scale of individual clock cycles and > processors are getting slower, not faster. I have an extremely > hard time imagining this sort of precision being meaningful (much > less, actually useful) in our platform. Heck; our mainloop is > still based on milliseconds. I like the principle of making easy things easy. > - use of int64-as-microseconds is already extremely common > > This is another reason to avoid doubles. mind to give us some examples, if you have time? > The conclusion of all of this is one point: barring substantial > complaints, the be-all and end-all of time in glib is going to be > microseconds stored in a gint64. > > GDateTime already calls this a "GTimeSpan". That's OK. > > > I will do the following: > > - rip out the newly introduced GTimeSpec and all APIs using it > > - deprecate GTimeVal and all APIs using it > > - replace both with APIs using int64 of microseconds > > - deprecate GTimer > > with int64-based time, it's trivially easy to do it yourself what does glib give to people who's trying to solve hard things? Linux kernel, in paticular, after the looong discussion and hard works, get the high resolution timer and dynamic tick support to solve this hard things. would it be an API bloat to leave nano second precision interface to use those new features? or add them after you simplified as above? it is not like we want to run the main loop in every 1 nsec, but some time it is handy to have sub micro seconds precision when you are working on audio or controlling hardware. I know glib is developed for Gtk+ based apps, but these days, many, if not a lot, application is using glib as base frame work. and, IMO, good frame work should have some way to solve those hard things. thanks, -- yashi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
On Mon, 2010-11-01 at 14:21 -0400, Havoc Pennington wrote: > Well there's already G_USEC_PER_SEC but I guess it's saving typing of > more zeroes. Reading 1000 is very easy. With 100 or 10, you usually have to stop and count the number of zeros (see also: why 'thousands separators' exist). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
On Mon, 2010-11-01 at 13:57 -0400, Havoc Pennington wrote: > Hi, > > On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie wrote: > > The conclusion of all of this is one point: barring substantial > > complaints, the be-all and end-all of time in glib is going to be > > microseconds stored in a gint64. > > Your arguments sound right and a nice upgrade over current APIs. > > Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code. Much as I am a fan of self-documenting code.. isn't "* 1000" much shorter and easier? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 2:10 PM, Peter Clifton wrote: >> Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code. > > Much as I am a fan of self-documenting code.. isn't "* 1000" much > shorter and easier? Well there's already G_USEC_PER_SEC but I guess it's saving typing of more zeroes. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 1:06 PM, John Ralls wrote: > I don't see any reason to have a replacement for GDate. fwiw, the original (and possibly only) use of GDate was for security price data (Open/High/Low/Close), which has only a day, not a time or timezone. This is also why GDate is not opaque, because it was important to be able to allocate a huge array of GDate quickly. Not that this makes GDate something that should be in a general-purpose lib like GLib, but it is a use-case that I'm not sure GDateTime would cover. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
Hi, On Mon, Nov 1, 2010 at 12:06 PM, Ryan Lortie wrote: > The conclusion of all of this is one point: barring substantial > complaints, the be-all and end-all of time in glib is going to be > microseconds stored in a gint64. Your arguments sound right and a nice upgrade over current APIs. Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
On Mon, 2010-11-01 at 10:06 -0700, John Ralls wrote: > +1 > > I don't see any reason to have a replacement for GDate. Just add any > extra functionality it provides to GDateTime -- which, with int64, > will be good for +/- 290,000 years from whatever its epoch date is, > with microsecond resolution. That should be sufficient for everyone > except astronomers, who have their own time libraries anyway. GDateTime is currently bounded between Gregorian dates 0001-01-01 (proleptic) and -12-31. I can't see any reason that we should change that. GDateTime was originally proposed to double as a 'date' type by having "midnight on day" to roughly stand in for "day", with some APIs to make that easier. It turns out that there are a lot of reasons that you don't want to do that, so any API that encouraged that sort of use was removed with the idea being that we would add a proper construct for this in the future. > As for bizarre OSes with epochs beginning at some time before the > common era, well, if glib is ever ported to one a simple ifdef can > just add the correction value and be done with it. No worries. That's my current line of thinking. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: microseconds ought to be enough for anybody
On Nov 1, 2010, at 9:06 AM, Ryan Lortie wrote: > Hello > > After an extensive process of dithering and soul-searching, I've come to > the following conclusions about time in GLib: > > - we have too many time types > > no explanation required. > > - microseconds ought to be enough for anybody > > A nanosecond is on the scale of individual clock cycles and > processors are getting slower, not faster. I have an extremely > hard time imagining this sort of precision being meaningful (much > less, actually useful) in our platform. Heck; our mainloop is > still based on milliseconds. > > - double isn't as good as int64 > > Using doubles for time intervals is extremely wasteful. Doubles > were designed to represent extremely small and extremely large > numbers -- orders of magnitude that we never meaningfully encounter > while dealing with time. Those extra bits used to express order of > magnitude are lost for expressing actual information. If we used > fixed point, we get those 12 extra bits back. > > I also don't like the strange feeling that I get when I consider > that the precision of double-based time expression slowly decreases > with each passing year. Not that it's really a practical > consideration -- just a weird feeling. > > - use of int64-as-microseconds is already extremely common > > This is another reason to avoid doubles. > > - who cares about stupid platforms? > > I spent a significant amount of time hand-wringing over > hypothetical "stupid" platforms that have the epoch of their > monotonic clock in biblical times. Although that's a theoretical > possibility, I don't know of any such platforms and if they do > exist, we can cross that bridge when we get there. Our primary > concern should be Linux -- and Linux is quite sane here. > > The conclusion of all of this is one point: barring substantial > complaints, the be-all and end-all of time in glib is going to be > microseconds stored in a gint64. > > GDateTime already calls this a "GTimeSpan". That's OK. > > > I will do the following: > > - rip out the newly introduced GTimeSpec and all APIs using it > > - deprecate GTimeVal and all APIs using it > > - replace both with APIs using int64 of microseconds > > - deprecate GTimer > >with int64-based time, it's trivially easy to do it yourself > > > Somewhat related (but not directly): I'd like to deprecate GDate (and > the half-dozen or so related types) in favour of eventual replacement > with a GDateTime-style immutable opaque structure. I guess we could > call that GDay (pronounced "g'day") for lack of a better available name > or we could wait until glib4 and replace GDate with GDate at that point. > Probably we should consider support for non-Gregorian calendars before > that point anyway (the fabled GCalendar API). > > I'm going to start pushing this work into a branch today and I'll merge > it to master quite soon unless there are objections. > +1 I don't see any reason to have a replacement for GDate. Just add any extra functionality it provides to GDateTime -- which, with int64, will be good for +/- 290,000 years from whatever its epoch date is, with microsecond resolution. That should be sufficient for everyone except astronomers, who have their own time libraries anyway. As for bizarre OSes with epochs beginning at some time before the common era, well, if glib is ever ported to one a simple ifdef can just add the correction value and be done with it. No worries. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
microseconds ought to be enough for anybody
Hello After an extensive process of dithering and soul-searching, I've come to the following conclusions about time in GLib: - we have too many time types no explanation required. - microseconds ought to be enough for anybody A nanosecond is on the scale of individual clock cycles and processors are getting slower, not faster. I have an extremely hard time imagining this sort of precision being meaningful (much less, actually useful) in our platform. Heck; our mainloop is still based on milliseconds. - double isn't as good as int64 Using doubles for time intervals is extremely wasteful. Doubles were designed to represent extremely small and extremely large numbers -- orders of magnitude that we never meaningfully encounter while dealing with time. Those extra bits used to express order of magnitude are lost for expressing actual information. If we used fixed point, we get those 12 extra bits back. I also don't like the strange feeling that I get when I consider that the precision of double-based time expression slowly decreases with each passing year. Not that it's really a practical consideration -- just a weird feeling. - use of int64-as-microseconds is already extremely common This is another reason to avoid doubles. - who cares about stupid platforms? I spent a significant amount of time hand-wringing over hypothetical "stupid" platforms that have the epoch of their monotonic clock in biblical times. Although that's a theoretical possibility, I don't know of any such platforms and if they do exist, we can cross that bridge when we get there. Our primary concern should be Linux -- and Linux is quite sane here. The conclusion of all of this is one point: barring substantial complaints, the be-all and end-all of time in glib is going to be microseconds stored in a gint64. GDateTime already calls this a "GTimeSpan". That's OK. I will do the following: - rip out the newly introduced GTimeSpec and all APIs using it - deprecate GTimeVal and all APIs using it - replace both with APIs using int64 of microseconds - deprecate GTimer with int64-based time, it's trivially easy to do it yourself Somewhat related (but not directly): I'd like to deprecate GDate (and the half-dozen or so related types) in favour of eventual replacement with a GDateTime-style immutable opaque structure. I guess we could call that GDay (pronounced "g'day") for lack of a better available name or we could wait until glib4 and replace GDate with GDate at that point. Probably we should consider support for non-Gregorian calendars before that point anyway (the fabled GCalendar API). I'm going to start pushing this work into a branch today and I'll merge it to master quite soon unless there are objections. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
