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. > For example, Mogo probably could be coded in Java and still (probably) > be the best 9x9 program. If so, then it would be the best despite the > fact that it was coded in Java, not because of it. They would have had > to overcome a good bit of performance handicap. Because its algorithms are well suited for more cycles. > 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. > 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. 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. > 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*. _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
