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.