On Friday, April 12, 2013 4:52:28 PM UTC-7, Dave Cheney wrote:
Please stop this cargo cult programming.
Please stop insulting people for making suggestions. I understand your
intention, but your language is needlessly rude. I've moderated various
mailing lists in my time and I try to stay away from this sort of language.
There are at least three good
reasons why you should not add this line to the start of any main
function you write.
1. Obviously your program is CPU bound, therefore, if you run your
program more that once concurrently, it will be misconfigured and
there is nothing you can do about it.
That implies the program will be run more than once simultaneously. That's
completely dependent on the type of program it is an the environment it
runs in; for example, almost none of the code I write (primarily iOS and
Mac application code and system frameworks) would ever be run this way.
2. Your program is not non deterministic.
I think you mean it *is* nondeterministic. But any code that uses
parallelism is nondeterministic. Even if the number of CPUs is fixed, all
sorts of other parameters like the timing of I/O operations or the
frequency of task interrupts aren't. It's a *good* idea to exercise code in
different environments instead of just assuming it will work in one.
For example, the docs for GOMAXPROCS point out that this mechanism will go
away when the Go schedule is more mature. At that point presumably CPU
scheduling will be more dynamically based on the available CPU cores.
leading to exactly the sort of nondeterminism you're decrying here.
3. Your operations people will hate you. You've just robbed them of
the one mechanism they have to adjust up, or down, a Go program
deployed in their environment.
Who says there are "operations people"? Who says this program runs in some
server farm? How do you know what kind of environment this code is for?
To repeat: export GOMAXPROCS=somenumber is the recommended way to
adjust GOMAXPROCS for an invocation of a program.
Again, you're assuming an environment where it's convenient or just
possible to manipulate environment variables around a program. I've worked
in many environments where it's not (such as GUI applications.) Anyway,
opinions vary — IMHO environment variables are a total mess to use,
especially during development. If I want some kind of dynamic preference
I'd prefer to use something else such as the CFPreferences API.
My 2¢? I understand that Go's scheduler is immature and not yet capable of
adapting intelligently to the available CPU power. But it seems weird to me
to have the default be to limit it to only a single core — it's restricting
the program to using only 1/4 or 1/8 of the typical available CPU. As a
first pass approximation before (or instead of) doing careful tuning, it
seems to me more appropriate to allow the code to use all CPUs.
I'm guessing this is a canned .sig since it clashes weirdly with the tone
of the rest of the message. I always find that sort of jarring...
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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.