Thanks for a great read there first of all. But... and this is something I see time and again and I must admit I don't really understand. What makes C faster than C++? I feel like C++ is all about you don't pay for what you don't use. Furthermore, I feel that C++ has at least one feature that in a one certain special case will result in faster code. While I generally would say avoid indirect calls where performance is critical (for obvious reasons) thereare certain times when it is faster than climbing through tons of logic. For these cases, if one indirect branch is reasonably likely the optimization most recent x86 chips take with static branch prediction is to "assume the [indirect] branch is not taken" which might seem wierd but makes sense since the chip can't easily guess this information statically. Good compilers will usually write the most commonly jumped to location after the indirect uncomditional jump instruction soooo....
JMP [EBX] JMP default_function is output. Unfortunately, C doesnt' have a way to specify this base case. Trying to code this yourself won't really work either because a C compiler is likely to notice that the branch is unconditional and remove you branch that occurs after anyway.... Which would be if you were using the low level jumping routines anyhow. There are a couple other features as well. So my question really is, how do you add features to a language (some of which give you opportunities to optimize things you wouldn't be able to) and come out slower? I'm assuming that if you are using C++ you know how to use discretion in feature use ofcourse. I also believe there may genuinely be a reason I don't understand since I see many good programmers picking C over C++. Thanks in advance for any explanation you have. - Nick On Nov 22, 2007 11:07 AM, Don Dailey <[EMAIL PROTECTED]> wrote: > I think we are missing the point of programmer productivity with higher > level languages. High level languages MIGHT improve the speed at which > you write code, but usually that is a minor concern. In computer > GO, what you want is the pathway that gives you the best programs in the > least amount of effort. > > For that, C currently appears to be the best choice. This in not > just my opinion, there is empirical evidence to support this claim. > Take a close look at the very best GO programs in the world, and I > doubt you will see Ruby and Python programs. I doubt you will see Java > programs. All of these programming languages, as wonderful as they > may be and most of which claim dramatically increased productivity, > simply are not "producing." > > Most arguments for using these languages are nonsense. They focus on > only one aspect of the total picture - how fast you can write bug-free > code. Some languages are clearly better than others at that but the > biggest factor by far is the programmer herself. > > Many say, "it's just not worth a few percent speedup to code in a low > level language." I hope you realize that "few percent" is probably > in the best case around 50%. We could argue about the exact number, > but the fact is that you take a substantial hit programming in Java (for > instance) and that is not even a high level language. > > Computer Go is still in the dark ages but is gradually emerging from it > - it's starting to be appreciated that 50% represents a significant > strength improvement. That probably means it's "low hanging fruit" - > in other words you are probably going to get the most improvement for > your programming time developing and programming in C. > > And yet many will say, but I would rather spend my time improving the > algorithm in a language that makes it easy to express my ideas. I > might be throwing away 50%, but I will quickly make up the difference > with my vastly improved ability to experiment and express my wonderful > ideas. One might even argue that using a low level language like C > is actually "inhibiting" their ability to forge ahead. > > My experience in computer chess is that the people who think this way, > never catch up. I call this the drunken sailor approach. The > metaphor is the drunken sailor who blows most of his paycheck the day he > gets it. He does this, because it seems to him like a lot of money. > When there is a lot of money in your pocket, it's easy to spend it > frivolously and then tighten up when you are almost broke. > > Computers are fast. You don't mind taking the 2 to 1 hit (or whatever > it is) for the extra luxury of programming in a high level language. > However, this mentality doesn't stop here. If you are thinking this > way, chances are that you take other shortcuts for the "long term > good". > > The problem is that you never stop taking the hit. You say, in 18 > months computers will be 2X faster, so it "doesn't matter." This is > the stupidest thing I keep hearing. In 18 months you will have a > faster computer, but your program will STILL be a crippled program that > sucks. Getting a faster wheelchair doesn't stop you from being > crippled. The drunken sailor borrows money thinking that his next > paycheck will cover these debts but forgets he will have to borrow money > again. > > When I develop my go program, the vast majority of the development time > is spent by the computer, not me. I need to optimize the computers > time, not my time. Whatever the program can do in 1 minute, I would > like to see happen in 30 seconds. If I had a network of workstations > my productivity (as measured by program strength) would improve > significantly because I could try a lot more thing in the same amount of > time. But even if I had such a network, I wouldn't willingly > cripple it by throwing away half the power. > > In fact, the whole concept is not to optimize what YOU do, it's to > optimize what the computer does. If you are not stingy about the > performance (playing strength) right from the start you are already > starting from the wrong mentality. That's probably why the best > programs are in C or assembler - these programmers see performance as > part of the overall whole - not something that is "in their way." > They don't romanticize their language or the tools they use, they are > focused on the problem and tend to make the most logical choices, not > the sexiest ones. > > My advice when this question comes up (which language for go programmer) > is to first ask, what do you hope to achieve? If you want to build a > high performance go program, anything other than C or assembler is like > tying your hand behind your back. If you do this only as a hobby and > have no aspirations (just for fun and pleasure) then by all means, you > will be much happier in a high level language. > > > - Don > > > > > > Raymond Wold wrote: > > Nick Apperson wrote: > > > >> But, to be fair, I totally agree that compiling python or ruby would > >> give > >> you noticable speed gains. And as always, speed comparisons are only > >> useful > >> in context. In terms of go programming.... if you are prototyping use > >> whatever the hell you want. If you are finishing something off, > >> don't waste > >> my time with any of those slow languages (that includes java and c#). > >> > >> > > I would posit that coding go, we are _always_ prototyping. > > _______________________________________________ > > 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/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
