Hi all,
I just made an interesting observation:
[1000 timesRepeat: [0.001 seconds wait]] timeToRun. "--> 2612"
I think the reason for this might be that Delay >> #schedule uses a critical section that is also accessed by the TimerEventLoop process with the highest priority in the system, so the synchronization overhead would be the bottleneck in this case.
Instead, if you need to produce many short delays anyway (for instance, to simulate a running process, just like me right new), you can use a busy-wait instead:
Duration >> busyWait
| proceedTime | proceedTime := Time utcMicrosecondClock + self asMicroSeconds. [Time utcMicrosecondClock >= proceedTime] whileFalse
http://www.hpi.de/ [1000 timesRepeat: [0.001 seconds busyWait]] timeToRun "--> 1000" Much faster.
Could we need this in the Trunk, too?
Best, Christoph
On 2021-07-01, at 10:18 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
Hi all,
I just made an interesting observation:
[1000 timesRepeat: [0.001 seconds wait]] timeToRun. "--> 2612"
That's because OS tick stuff tends to be very much not what we expect. We've been through a lot of excitement about this over the decades.
As best I remember, unix tends to have issues that effectively limit us to 500 ticks/sec and so the smallest delay is 2mS. Aliasing means you can end up with 'almost 3' I think. Windows used to be really terrible, but who knows, maybe they've improved it since last time? The only OS that made it easy to get actual, precise, regular, ticks is/was RISC OS. Of course pretty much nobody uses that any more.
Strange how "modern serious OSs" manage to do less well.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim If you must choose between two evils, pick the one you've never tried before.
Hmm... #busyWait would eat up more CPU cycles to gain accuracy. What about #waitPrecisely? Then you would not reveal that little implementation detail. And clients could make the decision between #wait and #waitPrecisely depending on whether they need accuracy, not whether they have CPU cycles to spare. Or #waitExactly? There must be some good name out there. :-)
Best, Marcel Am 01.07.2021 19:18:36 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi all,
I just made an interesting observation:
[1000 timesRepeat: [0.001 seconds wait]] timeToRun. "--> 2612"
I think the reason for this might be that Delay >> #schedule uses a critical section that is also accessed by the TimerEventLoop process with the highest priority in the system, so the synchronization overhead would be the bottleneck in this case.
Instead, if you need to produce many short delays anyway (for instance, to simulate a running process, just like me right new), you can use a busy-wait instead:
Duration >> busyWait
| proceedTime | proceedTime := Time utcMicrosecondClock + self asMicroSeconds. [Time utcMicrosecondClock >= proceedTime] whileFalse
[http://www.hpi.de/] [1000 timesRepeat: [0.001 seconds busyWait]] timeToRun "--> 1000"
Much faster.
Could we need this in the Trunk, too?
Best, Christoph
Hi Marcel,
to me as a non-domain expert for this stuff, both #waitExactly and #waitPrecisely would just sound "better" than normal #wait (similar to names such as "PluggableTextMorph*Plus*" or "JPEGReadWriter2"). #busyWait, on the other hand, is something I would have considered a pretty popular term - it alerts me directly that this will be a busy and resource-intensive operation. But maybe that's just my impression. :-)
Best, Christoph
Hmm... #busyWait would eat up more CPU cycles to gain accuracy. What about #waitPrecisely? Then you would not reveal that little implementation detail. And clients could make the decision between #wait and #waitPrecisely depending on whether they need accuracy, not whether they have CPU cycles to spare. Or #waitExactly? There must be some good name out there. :-)
Best, Marcel Am 01.07.2021 19:18:36 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>: Hi all,
I just made an interesting observation:
[1000 timesRepeat: [0.001 seconds wait]] timeToRun. "-->Â 2612"
I think the reason for this might be that Delay >> #schedule uses a critical section that is also accessed by the TimerEventLoop process with the highest priority in the system, so the synchronization overhead would be the bottleneck in this case.
Instead, if you need to produce many short delays anyway (for instance, to simulate a running process, just like me right new), you can use a busy-wait instead:
Duration >>Â busyWait
| proceedTime | proceedTime := Time utcMicrosecondClock + self asMicroSeconds. [Time utcMicrosecondClock >= proceedTime] whileFalse
[http://www.hpi.de/] [1000 timesRepeat: [0.001 seconds busyWait]] timeToRun "--> 1000"
Much faster.
Could we need this in the Trunk, too?
Best, Christoph
[...] both #waitExactly and #waitPrecisely would just sound "better" than normal #wait [...]
Ah, that's right. We wouldn't want to make everybody start using #waitExactly. Then it's maybe better to encode the "trade-off" directly in the message name. The method's comment should then reveal why it is there and that the normal use should be #wait. :-)
Best, Marcel Am 02.07.2021 15:58:17 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
to me as a non-domain expert for this stuff, both #waitExactly and #waitPrecisely would just sound "better" than normal #wait (similar to names such as "PluggableTextMorph*Plus*" or "JPEGReadWriter2"). #busyWait, on the other hand, is something I would have considered a pretty popular term - it alerts me directly that this will be a busy and resource-intensive operation. But maybe that's just my impression. :-)
Best, Christoph
Hmm... #busyWait would eat up more CPU cycles to gain accuracy. What about #waitPrecisely? Then you would not reveal that little implementation detail. And clients could make the decision between #wait and #waitPrecisely depending on whether they need accuracy, not whether they have CPU cycles to spare. Or #waitExactly? There must be some good name out there. :-)
Best, Marcel Am 01.07.2021 19:18:36 schrieb Thiede, Christoph : Hi all,
I just made an interesting observation:
[1000 timesRepeat: [0.001 seconds wait]] timeToRun. "-->Â 2612"
I think the reason for this might be that Delay >> #schedule uses a critical section that is also accessed by the TimerEventLoop process with the highest priority in the system, so the synchronization overhead would be the bottleneck in this case.
Instead, if you need to produce many short delays anyway (for instance, to simulate a running process, just like me right new), you can use a busy-wait instead:
Duration >>Â busyWait
| proceedTime | proceedTime := Time utcMicrosecondClock + self asMicroSeconds. [Time utcMicrosecondClock >= proceedTime] whileFalse
[http://www.hpi.de/] [1000 timesRepeat: [0.001 seconds busyWait]] timeToRun "--> 1000"
Much faster.
Could we need this in the Trunk, too?
Best, Christoph
squeak-dev@lists.squeakfoundation.org