Dave, The only thing that is "fast enough" is some fixed algorithm that tends to be boring. The whole reason for Moore's Law is that few people think their computers are fast enough. They will NEVER be fast enough and we will always want our computers to be faster because they clearly can do more when they are faster.
This by itself refutes everything you said. It's true that some things are good enough even on the computer you had 20 years ago. I don't know about you, but I don't really care about that. If you don't care to have a stronger GO program, then you can be perfectly satisfied with non-scalable GO programs even though they are limited and cannot be improved. And just because one might be perfectly happy to be a few years behind, doesn't mean someone else should be too. Programming in C is like being about 1.5 years ahead when it comes to playing strength in a go program. If you want to wait a year and half, more power to you. And I have no idea what you mean by "brute force." That way of writing go and chess programs died decades ago, nobody writes brute force go (or chess) programs that I know of. >From the context of your email, you seem very convinced, almost contemptuous of the idea that a computer program should require more than some fixed amount of computational resources. Since computer go is not solved, it seems like a trivial conclusion that it will require MORE computational resources than we have available right now. What basis do you have for thinking otherwise? Do you believe GO is not NP hard or that there is some intrinsic reason that a properly programmed computer would not benefit from more resources? I have more comments below: Dave Dyer wrote: > > I disagree with almost everything Donn wrote. > > Thanks to Moore's law, it is somewhere between unusual and rare for > the execution "speed penalty" of the language to matter, and if it > matters today (some but not all languages are fast enough), it won't > matter when the program is finished. Huh? When the program is finished, there will be faster computers. I understand that. But I think you overlooked the very trivial point that if you had coded in C, the program will STILL be stronger (on this new hardware) than if it was programmed in Ruby. > Thought experiment: 5 years ago, C was "fast enough" but java with > a 50% speed penalty was "too slow", then today both are "fast enough". C is still not fast enough, and thus Java will never be. This is moving target, not a fixed target. If it's a fixed target and you don't care about advanced programs (just static fixed algorithms) then you are right. > > Note that /some/ programs will always be too slow, so the speed of > the program also doesn't matter. A brute force Go program will never > be fast enough in any language on any computer. Exactly! That's is exactly the point. There are a few programs that don't care how fast the computer is, but those are mostly boring programs that we don't care so much about. Text editors for instance run just fine on old computers. We don't need Moore's Law for those applications. > --- > > For most other programs what matters is the time to develop the program, > not the execution speed once developed. That said, current monte carlo > programs are in the zone where speed does matter. I suspect that what matters to most people is the final playing strength of the program. You don't seem to care about this and so you probably optimize for development time. In such a case, if your goal is to minimize the amount of time you spend typing in the program (and getting it right), and you don't care how strong it is, then you are completely correct. However, for me the coding time is very small even though the development time is large. I spend more time thinking about the program than coding it, and I spend a great deal of time waiting on the computer, because I have no clue what will work and I must test it. I can't just furiously type in code. It would be ridiculous for me to optimize for the coding case where I spend the least amount of time. By using C, I optimize the case where most of the time is spent. > There are cases where the intrinsic features of a language make > a huge difference to a particular strategy, but most modern languages > have very similar feature sets, and it's not too likely that unusual > language features are a big advantage. Agreed. In fact, there is no strong argument for high level languages due to this in my opinion although there are some benefits. I don't deny the benefits, but I consider them outweighed by common sense. > Overwhelmingly, two factors govern productivity for something like > go programming. > > (1) the quality of the development environment. > > (2) the availability of suitable libraries which contain debugged > code that will be useful. Yes, C is very strong in the second case and although it's not personally my main concern, it's definitely a benefit. The quality of the development environment definitely makes a difference in the coding speed. GCC in linux is not very strong here, but it's certainly adequate. I have never felt the need to use one of the IDE's - perhaps I should. You see to have very old-fashioned ideas about the whole programming philosophy. You take the view that a project like go is a fixed static "task" and that you must optimize the programmers time in typing in code. And then you are "done." And since it takes many man hours, it doesn't matter if it takes 10 seconds to find a move instead of 1. After all, waiting an extra 9 seconds is nothing compared to the hundreds of hours programming this task. Or you can wait 5 years and that 9 seconds is now 1 second. This model might be reasonable in a corporate environment where you have different priorities, but the whole POINT of a GO program is to make it as strong as possible. It's like a man who restores old cars - his goal isn't to minimize the labor, it's a hobby for him and he isn't about the quantity, he is about the quality. He wants the car to be wonderful when he is done and will spare no reasonable expense. However, if you had a shop where you did this for profit, you would count every cost and take the shortcuts. You would maximize your profits, do things with machines instead of your hands and so on. Writing scalable go programs that have any chance of being competitive requires you to NOT tie your hands behind your back. You will (unfortunately) need a fast computer and you will need to program in C or assembler. I don't like this any more than you do, but it's a cold harsh reality. Pretending that it will suddenly be competitive in a few years (when computers get faster) is pure nonsense, the other programs will benefit too and thus you will NEVER catch up, even if your algorithm is just as good. If your algorithm is actually BETTER, then you will STILL benefit from a faster computer in 18 months. At some point you will STILL be forced to upgrade your computer if you want to remain competitive. The goal isn't necessarily to be competitive, it may simply be to have the strongest program you can make. In this case, the arguments are all the same. Make your algorithms smarter, and it will get stronger. Get a faster computer and it will get stronger. Do either one and your program will be stronger, but do both and it will be a lot stronger. Go ahead and try it. Write a non-scalable program, use the slowest language you want to and run it on a 10 year old computer. It shouldn't matter what the final program runs on because if it runs good on the 10 year old computer you won't need a newer computer. - 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/
