Older blog entries for ncm (starting at number 399)

22 Jul 2010 (updated 22 Jul 2010 at 08:02 UTC) »

Avery Pennarun enlarged on his previous posting I criticized as wrong in almost every detail, yet not far wrong in its conclusion. This time he does much better, but in identifying what he considers essential in a language to replace C++, he mostly identifies features of C++0xA, the new ISO C++ standard. In other words, the closest possible practical approximation to his ideal replacement for present C++ is ... C++. One howler, though, is his remark that any replacement for C must be "as fast as C". This is a common mistake among slow-language promoters, which sets a low bar; it really needs to be substantially faster than C -- as, indeed, C++ is. Another howler is that he doesn't seem to know about Algol 68 and its notion of pointers.

I've come to realize that in every sense that matters, "high level language" always really means "slow language". Once you trade off speed, there's no excuse for not being utterly superb in every other way. Every imperfection and quirk becomes absolutely indefensible. Yet, every slow language I know of is riddled with weird quirks from top to bottom.

(Following up from redi about Avery's anti-C++ rant and my earlier response...) On re-examination, I find Avery is wrong in practically every detail, most probably because he started out and still lives in the world before there was a Standard C++.

Redi already noted that the Return Value Optimization (RVO) doesn't depend on inlining, and that Avery's example doesn't depend on the RVO anyway. I will add that RVO is implemented in every extant compiler, so you should think of it as a regular language feature.

Avery complains vaguely about C++ exceptions, but C++ is the only language where exceptions actually work. That's because C++ is the only language that has real destructors. Other languages need a "finally" construct, which obliterates most of the potential benefit of exceptions.

Everything Avery complains about in std::string is a feature; i.e. it has 99 problems, but Avery's ain't them. If you find yourself making a string class, you're wasting somebody's time. If your function would be just as happy with a const char*, then make it take a const char*. I don't make my own string types; I use either std::string or char*, and one or the other always does the job.

Avery's complaints about function pointers are just weird. In most places where you would have used a function pointer in C, you want a virtual function in C++. That's close to the only place where virtual functions are actually useful (which makes it criminally idiotic that virtual functions are the default in Java, but I digress). Most people don't find it immediately obvious how virtual functions fill in for function pointers without looking at actual examples. Now that you know, though, you can look for yourself.

So, if in all of Avery's examples he's wrong, where is he right? He's right that C++ code cannot be made as pretty as code in a slow language, and that it's a mistake to try. C++ code is always going to look kind of clunky. The knack is to know which kinds of clunkiness are essential, and which are your fault because you didn't think clearly about what you are doing. If you find yourself overloading operator[] or fooling around with exotic function pointers, it's probably the latter. Coding good C++ is a lot like chess; ask yourself, "does this line help solve an actual problem?" If not, it's likely to be procrastination, or over-engineering, or wankage. It's not to C++'s credit that you have to ask yourself that, but no language deserves the blame for your own dilatory impulses.

What sucks most is that there is no useful and pretty language as powerful as C++, and none being worked on, so those of us doing hard things will depend on C++ indefinitely. Other, slow languages will come and go and be used for easy problems, as Bram's Law predicts.

20 Jul 2010 (updated 20 Jul 2010 at 07:13 UTC) »

I find it hard to argue with Avery in his rant against C++, besides minor quibbles. (In fact, you can append to a std::string without re-allocating. You can choose whether a std::map should quietly allocate a new cell for a previously unused key.) Still, much of what he writes is true. Yes, C++ code is often unavoidably unpleasant to look at. Yes, std::string is nobody's baby. Parts of the language are best forgotten (I'm looking at you, RTTI, and exception declarations, and export templates). We could say that's the price of power, but Java is just as ugly and not powerful at all. Haskell is pretty enough, and seems powerful until you try to use it for anything. The Gloriously Incompatible Successor to C++ could be even more powerful, and beautiful, but it's nowhere on the horizon. Until somebody makes one, well... there's more to life than pretty code. Powerful code, for example.

I upgraded my laptop kernel to Linux 2.6.34.1 to get the qcaux driver so it would talk to my Sanyo Katana LX phone, to offload pictures. When I plug it in, it shows up in dmesg, but nothing seems to know how to talk to it. I wonder what to try next. [Update: Dan Williams's blog has everything known. Yay Dan Williams. No picture downloads, but ModemManager can PPP through it, which is good for something, I guess.]

24 Jun 2010 (updated 24 Jun 2010 at 08:31 UTC) »

I just read And Another Thing, volume 6 of the Hitchhiker's Guide trilogy by Eoin Colfer, apparently under license by Adams's heirs. I'm tempted to say the best thing about it was the name of the Vogon ship, the Business End, out-Iain-M-Banksing Iain M. Banks himself.

I also read Strength in What Remains, by Tracy Kidder, The Wind-up Girl by Paolo Bacigalupi, Adventures of a Cat-whiskered Girl by Daniel Pinkwater (who I thought was dead and I'm overjoyed to find ain't), Complications: a surgeon's notes on an imperfect science by Atul Gawande, and Gunnerkrigg Court volumes 1 and 2 by Tom Siddell. All recommended.

21 Apr 2010 (updated 21 Apr 2010 at 04:39 UTC) »

I'm finally off Network Solutions. When they finally delivered the "authorization code" (first stalling for four days, for no reason) they offered a year's service for $16. Never, during 15 years as a regular customer, did they ever offer any $16 service short of a 7 year contract. Of course Gandi offers better every year, no strings attached (and even less for the despised ".biz", ".me", and ".co.uk" suffixes).

I'm a little late, but my Ada Lovelace Day choice for admired female hacker is Emilia Käsper, who coded implementations of AES-CTR and AES-GCM that run in under 10 cycles/byte, using SSE3 instructions, and defeat timing attacks besides. Each of 8 128-bit registers holds a bit from each byte in 128 bytes of plaintext: paper, slides. It isn't clear from the slides, but she shuffles the bits to their various registers using an SSSE3 instruction (and a "shuffle unit") that isn't in current AMD chips. Besides the speed, this is important because timing attacks on regular AES implementations are astonishingly easy.

A faster cipher would work on 128-byte blocks and just skip the bit shuffling. It wouldn't interoperate with anybody, but would be equally secure. If you went that route, I gather that one step of AES has turned out not to add any security, so you could skip that bit, too. You could call your cipher Skiphack. (Little historical joke there.)

My domain, cantrip.org, has been with Network Solutions ever since its inception. I've meant for years to move it, but just never got around to it until now. I chose Gandi.net for no better reason than that it's what Joey Hess uses. When you try to move your domain off of NS, they impose an arbitrary five-day delay, and offer you a 43% one-year discount (but still more than the competition) to stay. Of course each of these further steels my resolve to leave them.

I registered dingydangy.com with Gandi for my kids.

18 Mar 2010 (updated 7 Apr 2010 at 23:48 UTC) »
x86_64 AES assembly stinks, C blazes
In response to a problem at work where the new version of a program was running much slower than the released one, I looked at the performance of openssl doing AES on recent Intel x86_64. We had carefully ensured that SSL built using the hand-optimized x86_64 assembly version of the code. Imagine our surprise at finding that the C version runs twice as fast. I had tears from laughing.

How could this be? I interpreted it to mean that somebody at Intel made sure the compiler for x86 -> internal RISC (implemented in silicon) recognizes the instruction sequence generated by Gcc for AES, and pastes in its place a hand-coded sequence of internal operations. This means, in turn, that any new cipher that doesn't much resemble AES will be unfairly handicapped by running much more slowly on current Intel chips. It might mean that if Gcc were to improve its optimization to the point that the chip doesn't recognize the sequence it generates as AES, performance might drop by half or more. I wonder which chip version first got this optimization.

[Update: Or, it means that L1 cache alignment came out unlucky for the assembly code, in that particular build. Or something.]

10 Mar 2010 (updated 10 Mar 2010 at 02:12 UTC) »

They really should sell this thing as the "Friggin' Jetpack". No point in lowballing it, even though it is more like an adaptation of the Trek Aerospace "Solotrek" design than a proper jetpack.

Got a new camera, a Canon Powershot D10 that is supposed to work underwater. The manual says, "Playing back for a long time may cause feelings of discomfort." And regrets, for sure.

I have finally put my "socketpair for win32" (1, 2, 3) on github. That a bug turned up three years after initial posting suggests it is not, in fact, so trivial as I had originally said, and that perhaps, therefore, nothing in programming is. Or that nothing in interacting with an operating system is. Or anyway that nothing in interacting with a Microsoft operating system is. But probably the first is right.

390 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!