Don Dailey wrote:
Raymond Wold wrote:
On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote:
Experience in a language is a factor, but nobody refutes that properly
coded C is fastest (next to properly code assembly) and if performance
is your goal, then anything else accepts some compromise. That
compromise may work well for a particular individual and may even
produce a stronger program for them, but it's still a handicap.
Do you have anything to back this up? I was under the impression that
most decent assembly programmers agreed that they can't compete with the
best C compilers. Assembly is for when you *need* to be in touch with
the very lowest level, which in most cases you don't, because lots and
lots of other assembly programmers have been there before you and
distilled their knowledge into really really smart compilers that know
more, and can try out more, than you ever could in a lifetime.
I know that there are assembler programmers who specialize in the skills
requires to beat C code. However, there is no need to back this up.
You can express any C program in assembler and better C compilers do
this better and they continue to improve. Until C compilers are
perfect, then it will always be possible to express a (non-trivial)
program in more efficient assembler code.
That something is technically possible does not mean that a human can do
it. A compiler does not have to be perfect to beat a human, because
humans aren't perfect either.
My feeling is that the engineer who starts his GO programming project in
a high level language is not going to be able to compete with the C
programmer, even if he is given the extra hardware to equalize. I say
this because he has already proven (in some sense) that he can't make
good decisions and you can be reasonably sure that he will make more bad
decisions. For example you can be relatively sure that he will not
favor doing things fast if he has to write ugly code - after all he has
already made choices that indicates he values high level thinking and
nice code over low level efficiency. In fact it would be rather silly
if he used a high level language, but then resorted to performance tricks.
See, the thing about (most) high-level languages is that the "ugly
optimization" is a myth. In a high-level language, the optimizers will
work best with *correct* code, coded as the language was intended, and
programmers who try to optimize invariably /slow down/ their code.
Perhaps in the general case. Perhaps most humans will fail. But
skillful humans can find ways to optimize the code by doing unnatural or
ugly things - it's just getting more difficult.
No, it's getting impossible. For a high level language, an "ugly" way to
optimize is a bug in the language. That optimization should be moved to
the compiler, so that the "elegant" way of coding that solution end up
with the optimized code when compiled.
I don't say this to be ugly or to be critical of java or other
programmers. These languages are fine choices as long as you don't
believe you are writing a cutting edge high performance go program.
This assumes that to be cutting edge, cycles matter.
Of course it does - that is my assumption and I stated it.
Well it's a humongous assumption. The skill benefit per cycle added will
vary a _lot_ depending on the algorithm. As Dave Dyer said, standard
alpha-beta will have such a fast-growing three that added cycles will
add minimally to the skill. This, despite that alpha-beta can
technically solve the game of go given enough resources. Monte Carlo
methods will reach such a stage as well. The other added things will
need to balance. Knowledge-based approaches for instance, often has a
fixed search, and adding AB search or MC on top of it will add minimally.
If your algorithms
are such that doubling the execution time available means a 0.01%
increase in wins (this is *obviously* not true for a Monte Carlo-heavy
program, but might be for others), then giving up clarity is not worth
it. And if that 0.01% increase means you'll spend weeks extra
programming, because you have to recode something from scratch instead
of using a simple refactoring, the high-level language IS a fine choice.
This is my opinion but if your program is such that it doesn't benefit
from increased cycles, then your code is written wrong - certainly you
have hit a dead end by definition.
I am rather curious, which CGOS program that is NOT in C/C++ or
assembler is highest rated? Despite all the hype about expressibility
and code maintainability I would guess that the best programs are in C,
then perhaps Java (since it's relatively fast) and that the weakest are
in the "highly productive" dynamic programming languages that are slow.
This is because, at the current point in time, Monte Carlo programs
dominate. *This* *can* *change*.
It changes practically every day. None of these programs are the same
and some don't even use UCT now.
Even the non-scalable programs are scalable now - they are just hard
coded for a given platform. The programmer has to make some changes
and recompile them to work right on the next faster machine. They
usually tweak and optimize at the same time, but that in itself is not
scalability.
- Don
See, that's another advantage of a high-level language. Suddenly there's
a computer revolution, and all your hand-crafted assembly is worthless,
and much of the optimized C as well. Assumptions about register sizes,
opcodes available, memory layout/allocation/swapping, or concurrency
control might all be wrong. You will have to rewrite everything, while
the rest of us can let the thousands of people that write compilers do
that job for us, and our programs will be just as fast on the new platform.
The same goes for "tweaking" a program. Coding go, we'll want to try out
new approaches all the time, continuously improving our programs. But
when all your code is in a low-level language, they're so much harder
for refactoring programs to understand. You often have to rewrite from
scratch, instead of switching out modular parts. Or you end up writing
your own abstraction framework in your low level language, and end up
reimplementing part of Lisp, poorly.
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
