Hi Ian,
2016-07-18 0:33 GMT+02:00 Ian Lance Taylor <i...@golang.org>:
> On Sun, Jul 17, 2016 at 9:25 AM, Scott Cotton <w...@iri-labs.com> wrote:
> >
> > I'm well aware of the benefits of non-deterministic select for many use
> > cases, I don't contest that at all or the decision to have it part of
> > golang.
> >
> > A clear and concrete problem is the following: The sat solver
> competition
> > at satcompetition.org requires
> > deterministic solvers for reproducible results. Suppose I have a
> > select{...} in a go program which solves sat,
> > and I want to enter it in the contest. I can't. Also, others can't
> > reproduce the results. Also, the problem is hard
> > and very heuristic so minor variations can cause huge differences in
> runtime
> > (like 1s vs. 1 month).
>
> If the results of your program depend on the choices made in a select
> statement or in goroutine execution, then your program is in some
> sense racy.
Indeed, I agree. And if the results do not depend on that...
> It's not necessarily racy in a way that causes undefined
> execution, but it's still racy in the sense that your results become
> unpredictable.
I don't agree. Many randomised algorithms have varied performance based
on the random seed. As per Rob's select based rng:
chan := ...
select {
case <- chan:
return 1
case <- chan:
return 0
}
It is natural to use select and channels to express deliberately random
choices.
Whether they have a performance impact or not is completely orthogonal to
raciness.
> The answer to the problem is not to pin down the
> precise choices made by select statements and by the scheduler, it's
> to not write racy programs.
>
There are non-racy programs which exhibit this problem. Just pick any
randomised algorithm
and code a choice using select{}. You will have performance replicability
issues.
>
> I'm not just being facetious: on a multi-processor system with
> GOMAXPROCS > 1, there is no way to pin down the scheduler sufficiently
> to ensure that the same program choices are made each time. So if
> your results change based on scheduler decisions, you have no hope of
> reproducible results. Don't write your program that way.
>
One could say the same thing about introducing cputicks() in select
statement
choices :) Don't write concurrent non-deterministic programming languages
with no way to
determinize choices. At least if you want to be able to seriously evaluate
them
and seriously replicate behaviour.
Since no one chimed in on how the scheduling/select choices are made, I
took a look-see myself.
A summary:
issue 5606048 introduced cputicks() in seeding fastrand1, the runtime rng
which determines map order,
mapping of G's to M's, and lockorder for selects. adding the option to
remove cputicks from this
seeding looks to me like it would determinize the non-OS sources of
non-determinism. Better to
give the option of setting the seed explicitly to the user, or at least to
some of my applications if the option
is not welcome as legitimate due to racy-ness paranoia.
>
> Ian
>
--
Scott Cotton
President, IRI France SAS
http://www.iri-labs.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.
For more options, visit https://groups.google.com/d/optout.
