Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Best, Marcel
Ha! After reading my own post here ... is it just a cheap implementation of #rounded?^^
Best, Marcel Am 31.05.2023 10:01:50 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Best, Marcel
[(0 to: 5000) collect: [:ea | ea + 500 // 1000]] bench. '18,300 per second. 54.6 microseconds per run. 5.77884 % GC time.' [(0 to: 5000) collect: [:ea | (ea roundTo: 1000) // 1000]] bench. '6,980 per second. 143 microseconds per run. 2.97881 % GC time.'
Best, Marcel Am 31.05.2023 10:08:09 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Ha! After reading my own post here ... is it just a cheap implementation of #rounded?^^
Best, Marcel Am 31.05.2023 10:01:50 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Best, Marcel
On May 31, 2023, at 1:13 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
[(0 to: 5000) collect: [:ea | ea + 500 // 1000]] bench. '18,300 per second. 54.6 microseconds per run. 5.77884 % GC time.' [(0 to: 5000) collect: [:ea | (ea roundTo: 1000) // 1000]] bench. '6,980 per second. 143 microseconds per run. 2.97881 % GC time.'
Since you’re interested in the cost of rounding, not the cost of block activation, collection instantiation and Array at:put:, you’ll get much better data doing this:
{ [0 to: 5000 do: [:ea | ea + 500 // 1000]]. [0 to: 5000 do: [:ea | (ea roundTo: 1000) // 1000] } collect: #bench
That non-inlined do: in collect: dominates the computation, reducing the apparent cost of roundTo: over the inlined alternative.
Best, Marcel
Am 31.05.2023 10:08:09 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Ha! After reading my own post here ... is it just a cheap implementation of #rounded?^^
Best, Marcel
Am 31.05.2023 10:01:50 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Best, Marcel
Thanks!! :) Am 31.05.2023 18:15:11 schrieb Eliot Miranda eliot.miranda@gmail.com:
On May 31, 2023, at 1:13 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
[(0 to: 5000) collect: [:ea | ea + 500 // 1000]] bench. '18,300 per second. 54.6 microseconds per run. 5.77884 % GC time.' [(0 to: 5000) collect: [:ea | (ea roundTo: 1000) // 1000]] bench. '6,980 per second. 143 microseconds per run. 2.97881 % GC time.'
Since you’re interested in the cost of rounding, not the cost of block activation, collection instantiation and Array at:put:, you’ll get much better data doing this:
{ [0 to: 5000 do: [:ea | ea + 500 // 1000]]. [0 to: 5000 do: [:ea | (ea roundTo: 1000) // 1000] } collect: #bench
That non-inlined do: in collect: dominates the computation, reducing the apparent cost of roundTo: over the inlined alternative.
Best, Marcel Am 31.05.2023 10:08:09 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Ha! After reading my own post here ... is it just a cheap implementation of #rounded?^^
Best, Marcel Am 31.05.2023 10:01:50 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Best, Marcel
On May 31, 2023, at 1:08 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
Ha! After reading my own post here ... is it just a cheap implementation of #rounded?^^
Exactly. An inlined implementation avoiding integer/float/integer conversion.
Best, Marcel
Am 31.05.2023 10:01:50 schrieb Marcel Taeumel marcel.taeumel@hpi.de:
Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Best, Marcel
On May 31, 2023, at 1:02 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
Hi Eliot, hi Nicolas, hi all --
What's the meaning of that magic number 500 when calculating #timeToRun of a block?
In 2016, we changed from using primitive 135 to 240 to get some UTC-based microsecond value with millisecond precision. In Time class >> #millisecondsToRun:, we see that a magic 500 offset was added (by eem). And it is added, not removed. So, it is not the offset to call the primitive itself it seems...
More interestingly, we can see that 500 being added in Time class >> #microsecondsToRun: to a nanosecond value! So, what does it mean:
microsOrNanos + 500 // 1000
Nothing more than rounding accuracy. Integer division by 1000 truncates. Adding 500 ensures that times of 500usecs or more are answered as at least 1msec, instead of times of 999usecs or less being answered as 0msecs, etc.
Best, Marcel
squeak-dev@lists.squeakfoundation.org