On Wednesday, March 5, 2014 7:39:17 AM UTC+5:30, Roy Smith wrote: > "Rhodri James" wrote: > > wrote: > > > Code should look like its intent. Warping it around performance is > > > hardly ever worthwhile. > > That depends. In Python, I'd agree with you; if I'm worrying about > > performance in Python, I'm worrying at the level of the algorithms I'm > > using. In a constrained embedded C environment, which is where I spend > > most of my working life, writing your code so that the compiler chooses > > the right optimisation is critical. Sometimes it matters a great deal to > > me that something like "x *= 5" compiles to a single ARM instruction, or > > that splitting a loop into two to avoid a conditional test will let an > > DSP's optimiser double the speed of a section of code.
> Yeah. BTDT. I've stolen the bottom three bits of a pointer for my own > use because I know everything is 64-bit aligned so it's all zeros > anyway. I feel like there must be some organization I should be going > to every month that meets in a church basement and I can get up in front > of the room and say, "Hi, my name is Roy and I'm a C++ hacker", and have > everybody be supportive. > I mostly live in the Python world these days, where I'm firmly in the > camp of, "Stay away from O(n^2) and don't hit the database with > unindexed queries, and you're probably good". But, that's because we > push most of the hard work off onto C and C++ code that is written by > guys who worry about the bottom three bits. > One of those really awesome tools is haproxy. It's just amazing how > fast (and stable) that thing is. It's all written in C. Most of the if > statements are decorated with #pragmas telling the compiler which branch > is the most likely to be taken, so it can optimize better. We need > people like that down in the trenches, so the rest of us can run around > naked in the park with flowers in our hair and not worry about the > bottom three bits any more. I agree with most of the sentiment above... Except the implication that C and C++ are equivalent I wrote http://www.the-magus.in/Publications/chor.pdf 25 years ago criticising C *in education*. I was half my age then and used stronger language then than I would now Ive tried to express some pangs of conscience here http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html However my point then as now was: "C is dangerous to TEACH CS/programming with. Its sweet if you KNOW what you are up to." With C++ its horrible all the way - C++ has pretentious abstractions that invariably leak* C is honest in having few abstractions - C++ syntax is ridiculously brittle. C syntax is mostly straightforward - One of C's difficulties is complex binding-times: pre-process, compile, link load, run. Needs work but is master-able. With C++ Ive not got the basics after 25 years -- order of static constructors, templates... - I dont believe its coincidence that most of the rock-solid software I use has a C (not C++) under-belly -- python, linux-kernel, emacs, gcc, haskell, git, latex With apps in C++ its always catching-cook -- will it segfault me before I save my file? - Some guys with a wee bit more reputation who seem to agree with yours truly o http://article.gmane.org/gmane.comp.version-control.git/57918 o http://harmful.cat-v.org/software/c++/rms * ... which summarizes my objection in this thread: Python's 'is' leaks the machine abstraction. 'id' does it legitimately (somewhat), 'is' does it illegitimately -- https://mail.python.org/mailman/listinfo/python-list
