[golang-dev] Go1.1 and scheduler changes

I can speak for the authors, but I think there is time.

I *cannot* actually speak for anyone but myself, but I still think there is time.

I don't know. I don't recall hearing about this idea before. Why
would it help?

Ian

And what would be an approx deadline?



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.

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.

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.

End of 2012?

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

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.

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.

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

It depends on how invasive they are. Chances are much better the
simpler they can be.
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

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.

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).

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.