From @hoelzro

See the attached script. When running the script, CPU usage (as reported by top) is very high.

From @hoelzro

supply-cpu-test.p6

From @hoelzro

On Sun Dec 28 18​:05​:18 2014, rob@​hoelz.ro wrote​:

See the attached script. When running the script, CPU usage (as
reported by top) is very high.

For that matter, iterating over Supply.Channel results in high CPU usage as well.

From @hoelzro

On Sun Dec 28 18​:06​:47 2014, rob@​hoelz.ro wrote​:

On Sun Dec 28 18​:05​:18 2014, rob@​hoelz.ro wrote​:

See the attached script. When running the script, CPU usage (as
reported by top) is very high.

For that matter, iterating over Supply.Channel results in high CPU
usage as well.

So far, it seems to be Channel.list which is the culprit.

From @hoelzro

On Sun Dec 28 18​:08​:28 2014, rob@​hoelz.ro wrote​:

On Sun Dec 28 18​:06​:47 2014, rob@​hoelz.ro wrote​:

On Sun Dec 28 18​:05​:18 2014, rob@​hoelz.ro wrote​:

See the attached script. When running the script, CPU usage (as
reported by top) is very high.

For that matter, iterating over Supply.Channel results in high CPU
usage as well.

So far, it seems to be Channel.list which is the culprit.

Ok, any usage of earliest { ... } seems to go through a busy waiting loop unless a wait block is specified.

From @lizmat

On 29 Dec 2014, at 03​:05, Rob Hoelz (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Rob Hoelz
# Please include the string​: [perl #​123515]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=123515 >

See the attached script. When running the script, CPU usage (as reported by top) is very high.<supply-cpu-test.p6>

Looking deeper into the code, this appears to be caused by the implementation of “earliest” (former “winner”), which basically does a Thread.yield()​:

loop { Thread.yield }

This also eats 100% of one CPU. Not sure whether this is intended behaviour of Thread.yield or not. Having to use Thread.yield in “earliest” may also be sub-optimal.

Liz

The RT System itself - Status changed from 'new' to 'open'

From @moritz

On 29.12.2014 13​:44, Elizabeth Mattijsen wrote​:

On 29 Dec 2014, at 03​:05, Rob Hoelz (via RT) <perl6-bugs-followup@​perl.org> wrote​:

# New Ticket Created by Rob Hoelz
# Please include the string​: [perl #​12351]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=123515 >

See the attached script. When running the script, CPU usage (as reported by top) is very high.<supply-cpu-test.p6>

Looking deeper into the code, this appears to be caused by the implementation of “earliest” (former “winner”), which basically does a Thread.yield()​:

loop { Thread.yield }

This also eats 100% of one CPU. Not sure whether this is intended behaviour of Thread.yield or not.

yield just tells the scheduler to prefer another thread; if no other
thread has work to do, it'll re-enter the thread that called yield,
causing 100% CPU usage.

Having to use Thread.yield in “earliest” may also be sub-optimal.

Agreed.

Cheers,
Moritz

From @hoelzro

Commit 49dac31 addresses this; since the subject of the ticket is resolved, I'm going to close this ticket and create a new one to address the busy waiting issue.

On Mon Dec 29 05​:00​:57 2014, moritz.lenz@​gmail.com wrote​:

On 29.12.2014 13​:44, Elizabeth Mattijsen wrote​:

On 29 Dec 2014, at 03​:05, Rob Hoelz (via RT) <perl6-bugs-
followup@​perl.org> wrote​:

# New Ticket Created by Rob Hoelz
# Please include the string​: [perl #​12351]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=123515 >

See the attached script. When running the script, CPU usage (as
reported by top) is very high.<supply-cpu-test.p6>

Looking deeper into the code, this appears to be caused by the
implementation of “earliest” (former “winner”), which basically does
a Thread.yield()​:

loop { Thread.yield }

This also eats 100% of one CPU. Not sure whether this is intended
behaviour of Thread.yield or not.

yield just tells the scheduler to prefer another thread; if no other
thread has work to do, it'll re-enter the thread that called yield,
causing 100% CPU usage.

Having to use Thread.yield in “earliest” may also be sub-optimal.

Agreed.

Cheers,
Moritz

@hoelzro - Status changed from 'open' to 'resolved'