Hi Nick, When I say C, I really mean C or C++. C is basically a useful subset of C++.
C++ may be closer to the ideal HP language than C. To me, the ideal language will let you seamlessly step down to high performance coding in something just as efficient as C but be able to use much higher level language features without "getting in the way" of performance - which after all is what computers are all about. Even though I personally don't like c++ at least it doesn't invalidate this principle of being higher level without compromising the low level performance. The idea is that high level features should be optional. An interesting language is D. It's basically C with the option to use high level constructs and it's quite nice. It has everything needed to be a C/C++ replacement. It was designed specifically to be easy to optimize (for compilers) and in principle it can be faster than even C according to the website hype. I tend to believe this is true because it's really C code with stuff removed or added to improve (the opportunities for) compiler optimizations. However in practice, it's still noticeably slower (in my tests of GO code, about 1.4 X slower. ) I'm not willing to give up very much performance for things I use C for, so I can't yet use D. But I'm keeping a close eye on it. - Don Nick Apperson wrote: > 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] > <mailto:[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 <mailto:computer-go@computer-go.org> > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org <mailto:computer-go@computer-go.org> > http://www.computer-go.org/mailman/listinfo/computer-go/ > <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/
