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