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.
> >> 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. > 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. >> 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. > 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 > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
