On Thu, Jan 7, 2010 at 8:22 PM, John McIntosh
<johnmci@smalltalkconsulting.com> wrote:
I think Eliot wanted those in my vm work I think qwaq has them
time to add them I think
Yes. �We haven't moved to using it at the image level yet but the VM uses 64-bit microseconds from 1901 internally. �The current value of the clock however is updated by the VM's heartbeat which runs anywhere from 500Hz to 1KHz. �So while the clock has microsecond precision it only has millisecond resolution.
I made a similar change to VisualWorks, which uses 64-bit microseconds from 1901. �The advantage is that sub-second time values are actually wall clock values, as opposed to a 32-bit millisecond value that will wrap after 49 days that is unsynchronised with wall time.
BTW, 64 bit microseconds from 1901 is ~580,000 years. �So with e.g. 61-bit tagged integers in a 64-bit VM with maximum positive value of 2^60 - 1, the clock would take ~35,000 years to overflow tagged integers.
should it return a Long integer or a double
An unsigned long integer.
�
On 1/7/10, Esteban Lorenzano <estebanlm@gmail.com> wrote:
> Some times I wanted smaller grain for running tests... but most of the
> time millis are good enough :)
>
> On 2010-01-07 18:52:16 -0300, Alexandre Bergel
> <
alexandre@bergel.eu> said:
>
>> Hi!
>>
>> I am currently working on a new profiler for Pharo. The idea is to
>> graphically renders a profiling using Mondrian. I hope to release it
>> soon.
>> When discussing with an expert in the field (Walter Binder), the
>> question about time grain was raised. I am partly based on
>> MessageTally, which has a millisecond grain. Anyone is aware of a
>> finer grain? At the level of nanosecond? Does it makes sense since
>> there is no JIT (yet)?
>>
>> Alexandre
--
===========================================================================
John M. McIntosh <johnmci@smalltalkconsulting.com>
Corporate Smalltalk Consulting Ltd. �http://www.smalltalkconsulting.com
===========================================================================