FAQ
Hi,

Isn't it too late to commit significant scheduler changes? If no, what
is approx deadline before Go1.1? If yes, will it be possible to
release the scheduler changes before Go1.2 (I guess another year)?

What performance improvement would justify movement of net poller into
C runtime?

Search Discussions

  • Dave Cheney at Nov 22, 2012 at 5:12 am
    I can speak for the authors, but I think there is time.
    On 22/11/2012, at 16:07, Dmitry Vyukov wrote:

    Hi,

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?

    What performance improvement would justify movement of net poller into
    C runtime?
  • Dave Cheney at Nov 22, 2012 at 5:12 am
    I *cannot* actually speak for anyone but myself, but I still think there is time.
    On 22/11/2012, at 16:07, Dmitry Vyukov wrote:

    Hi,

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?

    What performance improvement would justify movement of net poller into
    C runtime?
  • Ian Lance Taylor at Nov 22, 2012 at 5:23 am

    On Wed, Nov 21, 2012 at 9:07 PM, Dmitry Vyukov wrote:
    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    There is time for scheduler changes before Go 1.1.
    What performance improvement would justify movement of net poller into
    C runtime?
    I don't know. I don't recall hearing about this idea before. Why
    would it help?

    Ian
  • Dmitry Vyukov at Nov 22, 2012 at 6:48 am

    On Thu, Nov 22, 2012 at 9:23 AM, Ian Lance Taylor wrote:
    On Wed, Nov 21, 2012 at 9:07 PM, Dmitry Vyukov wrote:

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    There is time for scheduler changes before Go 1.1.

    And what would be an approx deadline?


    What performance improvement would justify movement of net poller into
    C runtime?
    I don't know. I don't recall hearing about this idea before. Why
    would it help?

    Perhaps some communication was private, that's my fault.
    I am talking about this change:
    https://codereview.appspot.com/6460108/diff/43012/src/pkg/runtime/epoll_linux.c

    It moves epoll linux poller into runtime. Brad expressed reasonable
    concerns about moving more code into C. The reasons are:
    1. It special access to the scheduler, and can submit work in batches.
    Currently I observe "bounce" during submission, i.e. poller wakeups another
    thread, then another, at this point first thread blocks again and poller
    need to wake it up again. Poller in runtime will be able to make the whole
    batch of new work available to worker thread and only then start waking
    them.
    2. More efficient handling of timeouts. Runtime already implements
    efficient heap for timeouts.
    3. More efficient goroutine blocking/unblocking w/o channels.
    4. It's also more convenient to "pin" memory blocks to use as epoll_ctl
    contexts. This eliminates the need for global map that maps fd's to socket
    objects.
  • Rémy Oudompheng at Nov 22, 2012 at 7:06 am
    Are the changes (mostly) independent? Do you already have almost-ready
    CLs that show how the code looks?

    I don't know about the deadline, but seeing the code might help.

    Rémy.
  • Dmitry Vyukov at Nov 22, 2012 at 7:16 am

    On Thu, Nov 22, 2012 at 11:06 AM, Rémy Oudompheng wrote:

    Are the changes (mostly) independent? Do you already have almost-ready
    CLs that show how the code looks?

    I don't know about the deadline, but seeing the code might help.
    The CLs are:

    https://codereview.appspot.com/6441097/
    https://codereview.appspot.com/6460108<https://codereview.appspot.com/6460108/diff/43012/src/pkg/runtime/epoll_linux.c>


    They are "almost" ready.
    The net CL can be minimized significantly.
    The scheduler CL does not detect deadlocks at all and also burns CPU even
    when process is completely idle (that needs to be fixed).
    Both CLs needs to be synced to tip, there will be serious conflicts.
    Plus some refactorings and additional error handling.
  • Ian Lance Taylor at Nov 22, 2012 at 4:41 pm

    On Wed, Nov 21, 2012 at 10:48 PM, Dmitry Vyukov wrote:
    On Thu, Nov 22, 2012 at 9:23 AM, Ian Lance Taylor wrote:
    On Wed, Nov 21, 2012 at 9:07 PM, Dmitry Vyukov wrote:

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    There is time for scheduler changes before Go 1.1.


    And what would be an approx deadline?
    End of 2012?

    What performance improvement would justify movement of net poller into
    C runtime?
    I don't know. I don't recall hearing about this idea before. Why
    would it help?


    Perhaps some communication was private, that's my fault.
    I am talking about this change:
    https://codereview.appspot.com/6460108/diff/43012/src/pkg/runtime/epoll_linux.c
    It moves epoll linux poller into runtime. Brad expressed reasonable concerns
    about moving more code into C. The reasons are:
    1. It special access to the scheduler, and can submit work in batches.
    Currently I observe "bounce" during submission, i.e. poller wakeups another
    thread, then another, at this point first thread blocks again and poller
    need to wake it up again. Poller in runtime will be able to make the whole
    batch of new work available to worker thread and only then start waking
    them.
    2. More efficient handling of timeouts. Runtime already implements efficient
    heap for timeouts.
    3. More efficient goroutine blocking/unblocking w/o channels.
    4. It's also more convenient to "pin" memory blocks to use as epoll_ctl
    contexts. This eliminates the need for global map that maps fd's to socket
    objects.
    The performance of the network poller is clearly important. Still I
    wonder if we can add scheduler hooks, or in general scheduler
    improvements, to get some of the advantages with less C code. I think
    the relevant question is to what extent the poller is unique, and to
    what extent other Go programs may want to get some of the same
    advantages.

    Ian
  • Brad Fitzpatrick at Nov 22, 2012 at 4:49 pm

    On Wed, Nov 21, 2012 at 10:48 PM, Dmitry Vyukov wrote:
    On Thu, Nov 22, 2012 at 9:23 AM, Ian Lance Taylor wrote:

    On Wed, Nov 21, 2012 at 9:07 PM, Dmitry Vyukov <dvyukov@google.com>
    wrote:
    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    There is time for scheduler changes before Go 1.1.

    And what would be an approx deadline?


    What performance improvement would justify movement of net poller into
    C runtime?
    I don't know. I don't recall hearing about this idea before. Why
    would it help?

    Perhaps some communication was private, that's my fault.
    I am talking about this change:

    https://codereview.appspot.com/6460108/diff/43012/src/pkg/runtime/epoll_linux.c

    It moves epoll linux poller into runtime. Brad expressed reasonable
    concerns about moving more code into C.
    Yes, I'd like to see us moving more of the runtime to Go, not more Go into
    C.

    Moving things to C feels like giving up, or an admission that Go can't be
    fast or low-level, both of which I know not to be true.

    Of course, I don't work on the runtime, so my voice carries little weight.

    Like Ian said, I'm curious if we can't just give the pollster the scheduler
    hooks it needs.
  • Michael Jones at Nov 22, 2012 at 5:47 pm
    One comment on this point--there are truths about mathematics that cannot
    be proven from within its laws. There are facts about the Universe that may
    not be measurable from within space-time itself. So if there are things in
    Go's heart or brain that cannot be expressed in Go, or cannot easily be
    expressed in Go, that does not seem a weakness.

    Not saying this defensively, just pointing out that every molecule has some
    inner atoms; atoms have inner particles; and particles seem to have tiny
    subcomponents too. If the broad truth is that "It's onions all the way
    down" then so be it. Fine to have Go -> a little C -> a little Assembler ->
    (say) x86 uOps -> reorder buffer -> some macro fusion -> logic gates ->
    analog current/voltage -> electrons -> ...

    Metaphysical musings on Thanksgiving morning, before a family lunch and
    dash to the SFO airport and then off to Sydney.
    On Thu, Nov 22, 2012 at 8:49 AM, Brad Fitzpatrick wrote:

    Moving things to C feels like giving up, or an admission that Go can't be
    fast or low-level, both of which I know not to be true.



    --
    Michael T. Jones | Chief Technology Advocate | mtj@google.com | +1
    650-335-5765
  • 2paul De at Nov 25, 2012 at 2:54 pm
    As I have been looking forward to these performance improvements since
    about june/july here is my opinion:

    "What performance improvement would justify movement of net poller into C
    runtime?"

    The to-be-expected performance improvement, which I think is substancial,
    justifies such a pragmatic move. The conceptual issues could be fixed in
    the next-following release, building hooks into the runtime so other Go
    programs can benefit by using a standard interface to gain the same
    advantage; my feeling is that there will not be enough time to do THAT by
    year end (I could be wrong).

    There is the issue the higher conceptual cause, like writing more key
    portions of Go in Go and therefore not in C. Thats a very fine and
    respectable goal, however from my experience in software, users will see
    the actual results and performance increase more, and see less the fact
    that something is done in a conceptual optimal or correct way. It is a
    good idea and usually acceptable to be pragmatic whereever it is justified
    by a substancial win in performance and therefore having more happy users.


    Thanks



    On Thursday, November 22, 2012 6:07:46 AM UTC+1, Dmitry Vyukov wrote:

    Hi,

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?

    What performance improvement would justify movement of net poller into
    C runtime?
  • Russ Cox at Nov 25, 2012 at 4:23 pm

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    It depends on how invasive they are. Chances are much better the
    simpler they can be.
    What performance improvement would justify movement of net poller into
    C runtime?
    I think you'd need both a significant performance improvement and an
    argument that you can't get the same improvement by working within
    package net.

    The first step for either of these would be a concrete proposal of
    what you want to change, so that we can get the design right. I'm
    happy to make time for that. I've been distracted by some non-Go work
    recently but that is wrapping up finally.

    Thanks.
    Russ
  • Ugorji at Dec 17, 2012 at 3:12 pm
    Hi folks,

    Is there any update to these scheduler changes making it for Go1.1?
    On Sunday, November 25, 2012 11:23:38 AM UTC-5, rsc wrote:

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    It depends on how invasive they are. Chances are much better the
    simpler they can be.
    What performance improvement would justify movement of net poller into
    C runtime?
    I think you'd need both a significant performance improvement and an
    argument that you can't get the same improvement by working within
    package net.

    The first step for either of these would be a concrete proposal of
    what you want to change, so that we can get the design right. I'm
    happy to make time for that. I've been distracted by some non-Go work
    recently but that is wrapping up finally.

    Thanks.
    Russ
  • Dmitry Vyukov at Dec 17, 2012 at 3:17 pm

    On Mon, Dec 17, 2012 at 7:12 PM, Ugorji wrote:
    Hi folks,

    Is there any update to these scheduler changes making it for Go1.1?

    It seems that they are not making it into Go1.1...
    I want to make the race detector fully usable for Go1.1
    (documentation, stability, usability, etc). I don't have time right
    now to work on the scheduler (it's not my main project).

    On Sunday, November 25, 2012 11:23:38 AM UTC-5, rsc wrote:

    Isn't it too late to commit significant scheduler changes? If no, what
    is approx deadline before Go1.1? If yes, will it be possible to
    release the scheduler changes before Go1.2 (I guess another year)?
    It depends on how invasive they are. Chances are much better the
    simpler they can be.
    What performance improvement would justify movement of net poller into
    C runtime?
    I think you'd need both a significant performance improvement and an
    argument that you can't get the same improvement by working within
    package net.

    The first step for either of these would be a concrete proposal of
    what you want to change, so that we can get the design right. I'm
    happy to make time for that. I've been distracted by some non-Go work
    recently but that is wrapping up finally.

    Thanks.
    Russ
  • Rémy Oudompheng at Dec 19, 2012 at 9:02 pm

    On 2012/12/17 Dmitry Vyukov wrote:
    On Mon, Dec 17, 2012 at 7:12 PM, Ugorji wrote:
    Hi folks,

    Is there any update to these scheduler changes making it for Go1.1?

    It seems that they are not making it into Go1.1...
    I want to make the race detector fully usable for Go1.1
    (documentation, stability, usability, etc). I don't have time right
    now to work on the scheduler (it's not my main project).
    What about your CL about pure go edge-triggered epoll?

    https://codereview.appspot.com/6461075

    Rémy.
  • Dmitry Vyukov at Dec 24, 2012 at 2:44 pm

    On Thu, Dec 20, 2012 at 1:02 AM, Rémy Oudompheng wrote:
    On 2012/12/17 Dmitry Vyukov wrote:
    On Mon, Dec 17, 2012 at 7:12 PM, Ugorji wrote:
    Hi folks,

    Is there any update to these scheduler changes making it for Go1.1?

    It seems that they are not making it into Go1.1...
    I want to make the race detector fully usable for Go1.1
    (documentation, stability, usability, etc). I don't have time right
    now to work on the scheduler (it's not my main project).
    What about your CL about pure go edge-triggered epoll?

    https://codereview.appspot.com/6461075
    I've benchmarked it against current tip and it still gives visible
    boost (up to 50% IIRC). But now it need to be compared against Go
    version... that does not exist yet (there are concerns about moving
    code from Go to C).
  • Tylor at Dec 24, 2012 at 11:59 pm
    I'm very much looking forward to seeing these changes in action. The
    non-preemptive nature of the Go scheduler remains one of our biggest Go
    pain points. (Our other big pain points, GC performance and heap limits
    look to have been addressed in what will be 1.1)

    I can understand Brad's argument to increase the ratio of Go code in core,
    rather than decrease it, and I agree with that view when it is practical. I
    speak only as a user, not a core/run-time developer; but for me this ideal
    is less important than the pragmatic value of having a better scheduler.
    Once a better scheduler is in place, it can always be re-implemented in Go
    later. There is nothing wrong with well written C, even if well written Go
    is preferable :)

    To put it another way, I would rather have more C code in the run-time,
    which is essentially hidden from me from in my software maintenance, then
    have to continue to put scheduling hacks in my own software's Go code. I'm
    sure I am not the only end user that has to work around the current
    scheduling issues.
    On Monday, December 24, 2012 8:44:23 AM UTC-6, Dmitry Vyukov wrote:

    On Thu, Dec 20, 2012 at 1:02 AM, Rémy Oudompheng
    <remyoud...@gmail.com <javascript:>> wrote:
    On 2012/12/17 Dmitry Vyukov <dvy...@google.com <javascript:>> wrote:
    On Mon, Dec 17, 2012 at 7:12 PM, Ugorji <ugo...@gmail.com <javascript:>>
    wrote:
    Hi folks,

    Is there any update to these scheduler changes making it for Go1.1?

    It seems that they are not making it into Go1.1...
    I want to make the race detector fully usable for Go1.1
    (documentation, stability, usability, etc). I don't have time right
    now to work on the scheduler (it's not my main project).
    What about your CL about pure go edge-triggered epoll?

    https://codereview.appspot.com/6461075
    I've benchmarked it against current tip and it still gives visible
    boost (up to 50% IIRC). But now it need to be compared against Go
    version... that does not exist yet (there are concerns about moving
    code from Go to C).

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedNov 22, '12 at 5:07a
activeDec 24, '12 at 11:59p
posts17
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase