Entering the scheduler continuously will improve performance - it is known as
“keeping things hot”. Waking a thread is usually about 6-7 usecs. So if you
never “sleep” you get much lower latency.
> On Oct 31, 2022, at 4:55 PM, Sergey Kurenkov <sergey.a.kuren...@gmail.com>
> wrote:
>
>
> > Your sample code above is entering the scheduler
> continuously, which is not a typical characteristic of a real program
> that has heavy CPU usage. It's possible that what you are seeing is
> contention on the scheduler lock.
>
> Ian,
>
> Don't understand your point. The sample code above actually has better
> latency in my test even though it is is entering the scheduler
> continuously according to you:
>
> func (c *Connection) imitateEncodeAndSend() {
> onFinish := time.Now().Add(8 * time.Microsecond)
> for time.Now().Before(onFinish) {
> runtime.Gosched()
> }
> }
>
> And this code has 10 times worse latency in my test:
>
> func (c *Connection) imitateEncodeAndSend() {
> onFinish := time.Now().Add(8 * time.Microsecond)
> for time.Now().Before(onFinish) {
> // runtime.Gosched()
> }
> }
>
>
>> On Monday, October 31, 2022 at 10:53:44 PM UTC+2 Ian Lance Taylor wrote:
>> On Mon, Oct 31, 2022 at 1:34 PM Sergey Kurenkov
>> <sergey.a...@gmail.com> wrote:
>> >
>> > I am trying to understand why higher CPU utilization leads to longer
>> > latency in reading from channels in golang. Could you help me with this
>> > question?
>> >
>> > I wrote a test that reads from channels and measure latency between
>> > writing to a channel and reading from the channel. It shows that the
>> > latency depends on CPU utulization. When one of functions looks like this
>> >
>> > func (c *Connection) imitateEncodeAndSend() {
>> > onFinish := time.Now().Add(8 * time.Microsecond)
>> > for time.Now().Before(onFinish) {
>> > runtime.Gosched()
>> > }
>> > }
>>
>> You should make sure that you are testing CPU utilization itself,
>> rather than heavy scheduler use. Sending a value on a channel
>> generally requires a trip through the scheduler, to pick up the
>> receiving goroutine and start running it. Often the scheduler can
>> find the next job without acquiring the global scheduler lock, but not
>> always. Your sample code above is entering the scheduler
>> continuously, which is not a typical characteristic of a real program
>> that has heavy CPU usage. It's possible that what you are seeing is
>> contention on the scheduler lock.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7497264f-d407-423e-8b51-9567bc1fbd21n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/58E31744-FB0B-497D-9E22-AD17E0D6ACEC%40ix.netcom.com.
