On Tue, Aug 24, 2010 at 10:18 AM, Andreas Raab andreas.raab@gmx.de wrote:
On 8/24/2010 9:43 AM, Eliot Miranda wrote:
With these four one has a non-wrapping synchronised timebase with potentially microsecond resolution that marries well with Squeak's 64-bit integer support. This approach worked very well for VisualWorks where we got rid of lots of customer problems every 49.7 days (2^32 milliseconds). There has been some concern expressed about the performance impact of long integers but at least in VW that simply wasn't an issue.
For general purpose apps, sure. Remember that my concern is what the effect of switching to largeint arithmetic is on our routers which time-stamp in and outgoing packets at several points so that we can keep track of latencies and where they're introduced. I will absolutely believe that in "average" use there's not going to be an impact, but I don't think that what we're doing (timestamping millions of times per second) can be exactly considered average here :-) You'll recall that the introduction of the jiffy clock was in response to the server spending some 20% or so in gettimeofday...
Hmmm. Then, given that the clock's effective resolution is around 500Hz-1KHz, and that the 64-bit result is effectively immutable, there could be significant benefit in the primitive cacheing the current result, instantiating a new result object only when the time actually changes.
best Eliot
Cheers,
- Andreas
best Eliot
Thanks, Dave
On Mon, Aug 23, 2010 at 11:04:57AM -0700, Eliot Miranda wrote: > > On Sun, Aug 22, 2010 at 7:39 PM, David T. Lewis <lewis@mail.msen.com mailto:lewis@mail.msen.com> wrote: > > > > > Eliot, > > > > Yes, it can be retracted. I may not get to it for a few days so feel > > free to do so on my behalf. I introduced the change in trunk to put > > some visibility on the new primitives, which appears to have achieved > > the intended purpose ;) > > > > With respect to the Squeak epoch, we do have an issue that needs to > > be clarified. In the Squeak implementation, we have the 1901 epoch, > > but AFAIK there is no specification of the time zone in which the epoch > > is defined. In the Squeak implementation, local time has consistently > > been used in the platform interface, and the actual values of the > > Squeak clock for any real point in time are different depending on > > the time zone in which the image happens to be running. > > > > It's implicit that it is GMT/UTC. So the Squeak epoch is the start of 1901 > in Greenwich. > > To put it another way, there is no such thing as "UTC & local > > microseconds from the Smalltalk epoch" unless there is a clearly > > defined transformation between the Smalltalk epoch and the posix > > epoch, and in practice (in Squeak at least) this is not the case. > > Midnight on January 1, 1901 in Palo Alto, California was a different > > point in time from midnight January 1, 1901 in London, and I cannot > > determine which of the two was the "real" Smalltalk epoch. > > > > The latter is the only one that makes good sense. > > > > This begs the question of why, in implementing the interface to > > the underlying platform, we would *not* want use the posix epoch > > as a reference point. The Posix epoch is well defined, well documented, > > well understood, and easily translated to any existing definition of > > the Smalltalk epoch. In contrast, the Smalltalk epoch is ambiguously > > defined, poorly documented, and widely misunderstood. > > > > I think its easy to fix; just define it to be the start of the 20th century > in UTC. That's what we did with VW and its easy to do with Squeak. For me > backwards compatibility pushes strongly for keeping with the Squeak epoch, > i.e. Time seconds = Time milliseconds / 1000000. > > best, > Eliot > > > > > > Dave > > > > On Sat, Aug 14, 2010 at 05:28:28PM -0700, Eliot Miranda wrote: > > > > > > Hi David, > > > > > > any chance of getting you to retract this? The Cog VM has 64-bit UTC > > & > > > local microseconds from the Smalltalk epoch (1901), which are hence > > easier > > > to use as a basis for the Squeak clock and still last for ~ 54,000 years. > > > I'd like to see the Cog and standard VMs converge on a primitive set. > > This > > > is an issue for me since changing the epoch is, I think, an unnecessary > > > change. > > > > > > best > > > Eliot > > > > > > On Sat, Aug 14, 2010 at 4:55 PM, <commits@source.squeak.org mailto:commits@source.squeak.org> wrote: > > > > > > > Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 > > > > hours: > > > > > > > > > > > > > >
http://lists.squeakfoundation.org/pipermail/packages/2010-August/003596.html > > > > > > > > Name: Kernel-dtl.476 > > > > Ancestors: Kernel-eem.475 > > > > > > > > Add Time class>>primMicrosecondClock and Time class>>primUtcWithOffset > > for > > > > access to microsecond clock primitives available in newer Squeak VMs. > > > > > > > > primMicrosecondClock provides a system clock with nominal microsecond > > > > precision. > > > > > > > > primUtcWithOffset answers UTC time as microseconds since the Posix > > epoch > > > > and offset as seconds offset from GMT. The Squeak clock is > > traditionally > > > > implemented in terms of platform local time. Use of UTC time and offset > > is > > > > advantageous if time zones and daylight saving time offsets are to be > > > > considered. > > > > > > > > Example: > > > > { Time primMillisecondClock . > > > > Time primMicrosecondClock . > > > > Time primUtcWithOffset } ==> #(6932757 6932757830 #(1281815075538304 > > > > -14400)) > > > > > > > > > > > > ============================================= > > > > > > > > > > > >