I’ve ported about one third of upb to C++, on a branch, to see how it would turn out. It was a ton of work. Here are my current observations:

• The C++ is cleaner, more readable, less error-prone code. It’s just a fact. Compare for yourself (C: upb_def.h, upb_def.c; C++: upb_def.h, upb_def.cc). This is due to numerous factors:
  • type-safe containers means fewer casts.
  • “public” and “private” keywords make it easy to separate the private parts of your interface, without having to specify in comments which is which.
  • namespaces and class scope mean that I don’t have to write out my identifiers like upb_fielddef_dothis(), I can just write DoThis().
  • real inheritance and member classes mean I don’t have to explicitly call all the right constructors/destructors, or write explicit casts for upcasts
  • destructors that are guaranteed to run on scope exit mean I can use RAII patterns like mutexes that automatically unlock when the scope is exited
• The source got shorter; the portion I ported went from 1483 lines to 1133, or a ~30% reduction.
• The binary got a LOT bigger. I had one function get literally 5x as big. I haven’t figured out why this happened yet. I used templates to make the table generic, but I was extremely careful to make sure that the template only generated a small amount of code — basically just the hash lookup routine, which is small (note: the hash function for strings was not templated or inlined). But another issue is that the C++ compiler appears to emit multiple copies of the same function in the same object file! For example, I found some virtual destructors emitted literally three times in the same file. Why is this?
• I just heard back from a security guru from the Google security team, who said that C is often easier to audit than C++ because it’s easier to figure out what is actually going on, without having to dig through layers of abstraction. This surprised me (maybe it shouldn’t have, since Sam Quigley said the same thing in a comment on my last entry), but I was also a little bit relieved.

I’m leaning towards sticking with C, for the following reasons:

• C++ compilers aren’t very good at keeping things small, even when you are juducious with your use of templates.
• C++ compilers are much more complicated that C compilers, and therefore not as ubiquitous or as easy to trust generally.
• C isn’t harder to audit for security than C++, and may actually be easier.

I’ll try to take some of the lessons I learned from my partial C++ port to make the C more readable.

I haven’t released upb at all yet, and my last message indicating I’m thinking of porting it to C++ will probably make skeptical readers think I’m moving farther away from a release rather than closer to one.

Since I agree that my progress doesn’t look too promising to someone observing from the outside, let me say where I think these projects currently are, where they’re going, and when they’re likely to release.

First of all, Gazelle is currently pushed on the stack until I have upb released. The reason is that I realized that Protocol Buffers are the answer to two big problems I was facing with Gazelle:

1. byte-code format: right now the Gazelle byte-code format is LLVM’s BitCode, which is the format LLVM uses for storing its byte-code internally. I invested a lot into BitCode (you’ll notice my name is on the linked document), including writing a standalone encoder and decoder (230 lines of Lua and 856 lines of C, respectively). But this was before I worked at Google or knew about Protocol Buffers. Protocol Buffers are much easier to use because they have a formal schema (the .proto file) that can generate nice APIs and help you out with backward compatibility. Without a format schema, BitCode makes you resort to things like an ad hoc text file that describes the schema. This approach was showing its limits.
2. parse tree format: I always knew I wanted Gazelle to be capable of generating parse trees in some kind of standard format. Protocol Buffers end up being a match made in heaven, since they are isomorphic to parse trees in a very deep way. Indeed, the ast system for the Elkhound Parser is very much like Protocol Buffers in that you define your parse tree format and it generates classes for representing your AST.

Since Gazelle is gated on upb, the question then is: when will upb release? Why hasn’t it released already?

A few months ago I was working on upb for 100% of my time at work. I had banked 20% time for a while, and I was also a bit burned out on my 80% project, so my manager very graciously gave me the liberty to work on upb for all of my working hours.

During that time upb made progress in several areas. It got some better benchmarks and tests, and I fleshed out the upb compiler so that it wasn’t dependent on the official Protocol Buffers compiler for bootstrapping. Maybe most importantly, I worked a lot on the in-memory message format to figure out how to make it work well with dynamic languages.

My goal during that time was to write a Python extension that a few initial internal-to-Google customers could use. The value proposition is that it would be API-compatible with what they were already using, but many times faster. I wrote said extension, which was incomplete (supported decoding only, not encoding), but looked complete enough to use for this case.

By this time I was approaching the amount of time I could reasonably ask from my manager at work, so I had to tie up the loose ends and get it into my initial customer’s hands. I put all the pieces together and tried it out, but then ran into a problem; I hadn’t realized that this initial customer was using an old deprecated feature of Protocol Buffers called MessageSet. There was no way I could support MessageSet without significant changes. I was defeated for the moment. I had to take a break for a few months and re-devote my time to my 80% project.

I mention this all just to illustrate that I do have actual customers that I am targeting, and I have had aggressive pushes to deliver something to those customers, but unfortunately my work wasn’t complete enough for them yet.

This brings us up to now. In the last week or two, I have made several strides, including executing on part of a design that will get me MessageSet support. I have also developed an interface for a “pick parser”, which lets you pull only a small subset of fields out of a protobuf. This will be a big win for use cases that only need a few fields from a very large proto, and I have a customer internal-to-Google who is very interested in this interface.

Meanwhile I’m very interested in trying to get the upb Python extension into AppEngine, because I think it could be a huge win there since users aren’t allowed to load custom Python extensions. This means that currently, people trying to use protocol buffers on AppEngine are limited to pure-Python extensions that are much slower than a C extension can be. But to get into AppEngine I will need to get a security audit, which is part of the reason I am leaning towards C++ at this point. I think C++ will make the code shorter and less gnarly (fewer casts), which should lead to easier verifiability. I converted one header file so far, and it got 38% smaller and much easier to read.

I hesitate to make schedule estimates, but my main purpose is to impress on my possibly-impatient audience that:

• I do have motivation to release.
• I do have initial customers and initial use cases.
• I am making progress.
• I am currently focused on delivering (1) a pick parser, (2) a Python extension, (3) an easily-auditable code-base.
• I look forward to being able to announce my first release!

Yours,
Josh

My reasons aren’t ideological, they are highly practical. Basically I am realizing that while object-oriented C is OK for a while, it’s very weak at inheritance. Inheritance in C involves a lot of casting, duplicated code and/or macros, and careful discipline. The main problems with this are:

• the code gets longer and less readable
• the code involves more possibly-unsafe operations like casts

Both of these problems make the code ultimately more difficult to audit for security. And getting upb audited for security is something I plan to do very soon.

I am coming to believe that porting to C++ would make upb smaller (in lines of code) and easier for verify for security. However, there are a few major disadvantages that are giving me pause:

• there are still some contexts in which C++ is a no-go, like the Linux kernel, embedded systems that only have a C compiler (but no C++), or projects that want to stay C-only. Doing this port would make upb unsuitable for these contexts.
• projects that are currently C-only would need to create C++ source files to call upb APIs, and will have to link in the C++ runtime
• (possible) C++ could result in a larger binary.

When I look at the downsides though, they don’t seem to pertain to my initial goals of making upb useful for Python, Lua, Ruby, etc. extensions, and for use inside Google. Being useful for really restricted embedded systems is a far-off use case. So it’s sounding like porting to C++ is the right thing to do.

I hope it significantly reduces the line count, as I expect it will. That will make me feel better about giving up the minimalism of C. I will definitely be compiling with -fno-exceptions -fno-rtti -fvisibility-inlines-hidden on gcc. I also won’t be using any of the C++ standard library (not even <string>).

I need only the tiniest bit of functionality:

• a portable mutex.
• a portable atomic_t that lets me atomic_inc() and atomic_dec().

We’re talking “lives in one single header” small. The mutex would just be wrappers around existing mutex implementations (pthreads, windows, etc), and since those routines typically take care of any memory barriers you need to safely read/mutate the shared state, I wouldn’t have to worry about that.

The atomic type would have to be hand-coded and architecture-specific, since most threading libraries don’t provide one. The reason for providing this would be reference-counting. If you are reference-counting an immutable structure, then you don’t need to worry about memory barriers to ensure the consistency of that structure; if you’re reference-counting a mutable structure, then you’ll need to protect the mutable state with mutexes and acquire the mutex before freeing anything.

The library (er, header file) should also support compiling everything to nothing if NO_THREAD_SAFETY is defined as a preprocessor symbol.

Yes, that all sounds good. Tiny yet functional. I’ll be writing this very soon unless something exactly like what I’ve described happens to already exist.

Unfortunately, there is still no good way (AFICS) to lurk on high-volume mailing lists. Your current options are:

• Subscribe your personal email address to the mailing list. Pros: threads well, tracks “read” status well, easy to reply. Cons: too much overhead to subscribe to a new list (subscribe, confirm, set up mail filter), mail builds up as unread if you don’t read it for a while. Overwhelming for high volume lists. Not convenient when your level of interest in a list varies.
• Read on gmane.org. Pros: threads somewhat well (new messages on old threads get lost, because the whole thread is sorted based on when its first message arrived), tracks your “read” status (but not across browsers or computers), easy to track a single list and only read what interests you. Cons: not easy to track multiple lists. There’s no top-level “what’s new on lists I care about” view. Not easy to reply (the built in editor makes you wrap lines yourself).
• RSS feed from gmane.org. Pros: easy to track multiple lists, old mail doesn’t build up if I don’t read it for a while, lets me read mailing list posts alongside my other feeds. Cons: RSS is a terrible match for mailing lists. It doesn’t understand threads at all. No easy way to reply. Also, the gmane RSS feeds link you to the blog interface, which is equally terrible at threading.
• The Lurker email archiver. I’ve been a fan of this project for a while. Pros: GREAT interface (check out this demo site), top-level page that summarizes threads and their activity, thread view that shows you replies according to both time and threading. Cons: you have to run it yourself (it’s a project, not a service), doesn’t remember what you’ve read, and no easy way to reply.

What I would love is a website that would let me easily lurk on mailing lists. I’d love an interface like Lurker, but that I log into so that it knows what I’ve read. I’d want a top-level view that shows popular threads across ALL mailing lists I’m lurking on, not just one mailing list at a time. And I’d want the ability to easily reply to mailing list threads.

If anyone knows a better way to get what I want, please let me know!

gcc was my first real compiler, and this was back before binutils supported Intel syntax like they do now. So I read Brennan’s Guide to Inline Assembly (which I still reference frequently), and didn’t worry too much about it.

One thing that always bugged me a little bit was how the instruction names weren’t exactly the same. AT&T made you put these suffixes on your instructions, so mov would become movl. The main problem with this is Googleability.

But today what was previously an annoyance reached the level of being a serious problem. I was looking at an instruction listing and saw the instruction movslq. First I Googled for movsl (presuming that the “q” was a “quadword” suffix), but that yielded nothing. Then I tried Googling for movslq in its entirety, still nothing that seemed to define the instruction.

When I did follow the link, what I discovered is that movslq in AT&T syntax corresponds to movsxd in Intel syntax. The moment I discovered this, it became quite clear to me that AT&T syntax was a dead end. “-M intel” will be my default parameter to objdump from now on.

Specific problems:

“checkout” is a destructive command

I seriously have no idea what Linus was thinking. It is insanity that:

$ git checkout foo.c

…will overwrite any local modifications you may have to foo.c without asking.

You can’t merge upstream changes into your local, uncommitted modifications

Suppose I cloned some repository and I started hacking it up. My changes are still hacky and not ready to be committed. Say a few days later I want to pull upstream changes, but without committing my hacky changes to my local repository:

$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /tmp/foo
   e726259..e20c51a  master     -> origin/master
Updating e726259..e20c51a
error: Entry 'foo.c' not uptodate. Cannot merge.

Git is refusing to perform a merge of my local modifications with the upstream changes. It wants me to commit my local changes first. This is annoying. Every version control system I have ever used supports this, except Git. Asking me to commit my hacky changes is unreasonable; they’re hacky and unfinished. They might not even compile!

Yes, I could do:

$ git stash
$ git pull
$ git stash apply

But why should I have to do this? CVS, SVN, and P4 don’t make me.

Git’s merge conflict resolution workflow is unintuitive

Continuing with the above example, now suppose I committed my local changes and then did a pull, but the changes were conflicting:

$ git pull
Auto-merged foo.c
CONFLICT (content): Merge conflict in foo.c
Automatic merge failed; fix conflicts and then commit the result.

Ok, git is somewhat helpful here, I’ll fix the conflicts in foo.c and commit the result:

$ vim foo.c
$ git commit
foo.c: needs merge
foo.c: unmerged (f388ef85dd65c39e4c76f5e597d3b67f7d1a0726)
foo.c: unmerged (6f4bf54585ae256236c0d6cfa9f114affb94313f)
foo.c: unmerged (06c974ebbfc04394f4fad8a6dcb31e64866fa1bf)
error: Error building trees

Ok, maybe it’s obvious to experienced git users what my error is here, but git’s error message here is worse than unhelpful — it’s downright confusing. I think I’ve resolved the conflict, but all git can think to do is tell me is that “foo.c needs merge” and spit some SHA1’s at me. It gives me absolutely no help about what I need to do to fix the problem.

Suppose that I want to resolve the merge by using either my version or their version verbatim (”accept mine”/”accept theirs”):

$ git checkout foo.c
error: path 'foo.c' is unmerged

Again, unhelpful (and in this case, what I’m trying to say actually makes sense, git just won’t let me do it).

Interface for working with the index almost universally confusing

I understand the difference between the working directory, the index, and the committed tree pretty well. But I cannot for the life of me remember the difference between:

$ git reset --soft
$ git reset --hard
$ git reset --mixed

I can barely keep them straight while I’m reading the manpage. “Soft” resets HEAD but not the working directory or index. “Mixed” resets HEAD and the index, but not the working directory. “Hard” reset HEAD, the index, and the working directory.

In conclusion, this isn’t meant to be an exhaustive list of problems with git’s interface, it’s more meant to be a microcosm. Git’s interface is not intuitive or easy to learn, and its error messages are not helpful. Which is too bad, because as I said I think Git is solid technology. I just hope someone writes a better porcelain for it. I’m not talking about evolutionary changes, I think the suite of top-level commands (checkout, branch, merge, pull, reset, commit, etc) needs to be redesigned from scratch.

When I say “documentation,” I am talking about several slightly different things:

• Project Homepage for projects like upb and Gazelle. The goal of a project homepage is to answer the question “what is this project and why should I use it?” It should also be attractive enough for a person to feel like this project is high-quality stuff. And of course it should point them to the relevant resources (downloads, source tree, bug tracker, etc). Good examples: http://git-scm.com/, http://www.ruby-lang.org/en/, http://www.gazelle-parser.org.
• Manuals for projects like upb and Gazelle. The goal of the manual is to provide both tutorial-like and reference-like information about how to use the software. Manuals have a lot of structure and are a bit more formal, since they are intended to precisely explain how the software should be used. They tend to track the software itself more closely than the other types of documentation, and are often even checked into the source tree. For example, Gazelle’s Manual.
• Design discussions/rationale. This isn’t quite like a manual because instead of describing how the software works, they describe why the software is the way it is. What are the alternatives to your approach and why did you pick the one you did? What are the trade-offs? I don’t think we see as much of this documentation as we should in the open-source world, but one good example is the Python PEP process.
• General articles about a particular subject. I mean to write some documents that explain the basic ideas of parsing in a more approachable way than most parsing literature. The literature can be a bit oblique, and I think I could do a good job of explaining it in a way that anyone can understand.

The main options that I see available to me are:

• Plain HTML. Even I have come to the conclusion that this isn’t a good choice any more. Too much work to write, too little flexibility, not enough bang for the buck. Of the four documentation kinds above, the only one it remotely makes sense for is the “Project Homepage” case, but even that is too much work for me. Creating the Gazelle homepage took too much work, and it’s not even that awesome.
• Personal Wiki / MarkDown. By “Personal Wiki” I mean a wiki that you run yourself. I put this in the same category as MarkDown because the two tend to have the same advantages/disadvantages. The advantages are that you can get a reasonably attractive product with minimal effort, and they are fairly customizable. The big disadvantage is that no two markdown languages are compatible, and there are so many to choose from (seriously: MarkDown, ReStructured Text, Textile, AsciiDoc, and those are just the ones I know off the top of my head). It’s slightly scary to invest a lot into a format that is one of many possible contenders.
• Hosted Wiki, like the Google Code wiki or the GitHub wiki. In this case hosting is taken care of, but you have less control over the look and more stuff cluttering your page. Also, I can’t figure out why, but something about the design of Google Code makes me totally uninspired to write any documents in its wiki. Another thing to note is that if a hosted wiki disappears (GitHub is only a startup, it could totally go under), it’s not clear what happens to your documents!
• DocBook, which is a little better than a MarkDown scheme because DocBook seems to have gained some critical mass. Still, the DocBook people seem to have a mild-to-moderate case of XML-itis, and the DocBook homepage seems more concerned with spitting acronyms at you than telling you if DocBook is capable of something basic like theming your document in different ways.

So as you can see, I’m not super satisified with any of my options. The Gazelle Manual uses AsciiDoc, which seems to work ok, and I would probably choose it again. I guess I’d be most inclined to choose either AsciiDoc or DocBook for writing general articles (I like this article about Python types and objects which was made using DocBook and is attractive).

I can’t decide what to do for the Project Homepage or the Design Discussions case. I really want to have attractive Project Homepages, but I don’t have too much web design talent and HTML is too much work for me. For Design Discussions I guess I’m leaning towards the GitHub wiki just because it pairs with the project hosting nicely, though I am somewhat uncomfortable with the idea that GitHub could disappear one day, and that moving my documents from the GitHub wiki somewhere else sounds like a headache.

Here’s an extreme example of why. Take an innocent-looking function like:

int float_to_int(float f) {
  return (int)f;
}

Looks simple enough, right? Unfortunately, float -> int casts are stupidly expensive on x86. Without any -m flags, gcc compiles this to:

sub      $0x8, %esp       ; allocate stack space
fnstcw   0x6(%esp)        ; save floating-point control word
flds     $0xc(%esp)       ; push floating-point param onto fp stack
movzwl   0x6(%esp), %eax  ; move prev fp control word into %eax
mov      $0xc, %ah        ; set rounding mode of control word to "truncate"
mov      %ax, 0x4(%esp)   ; save it *back* to the stack
fldcw    0x4(%esp)        ; set the floating-point control word to truncate
fistp    0x2(%esp)        ; store integer from the fp stack to the stack
fldcw    0x6(%esp)        ; set the fp control word back to what it was
movzwl   0x2(%esp), %eax  ; read the value into eax (the return value)
add      $0x8, %esp       ; give the stack space back
ret

This would be funny if it weren’t so sad. All these gymnastics are required because the cast is required to round down (according to the C standard), but that requires the x86’s floating point unit to be in a different mode than for most operations.

Compiling exactly the same code with -msse2 allows the compiler to take advantage of an SSE-only instruction, and the above is replaced with:

cvttss2si  0x4(%esp), %eax     ; convert value to integer with truncation
ret

The difference in this case is astounding. Hopefully this will motivate you never to forget the -march flag!

The right thing to do in my case is compile with -march=core2. When I compile with -march=core2 or -msse3, the compiler to emits the not-quite-as-terse:

sub     $0x4,%esp
flds    0x8(%esp)
fisttpl (%esp)
mov     (%esp),%eax
add     $0x4,%esp
ret

I’m really not sure why gcc prefers this version when sse3 is available. It seems to be more work than the sse2 version. I tend to believe gcc know what it’s doing here, but I’d love to learn why.

Intel has added a number of new instructions to Nehalem and it has sped up others. The 4.2 version of Intel’s SSE vector extensions takes the x86 ISA back to the future just a bit by adding new string manipulation instructions. I say “back to the future” because ISA-level support for string processing is a hallmark of CISC architectures that was actively deprecated in the post-RISC years; typically, when a writer wants to give an example of crufty old corners of the x86 ISA that have caused pain for chip architects, string manipulation instructions are what he or she reaches for. But the new SSE 4.2 string instructions are aimed at accelerating XML processing, which makes them Web-friendly and therefore modern (i.e., not crufty).

I chuckled a bit when I read this. I’m not very purist when it comes to hardware. If these instructions will make my parsers faster, then they sound great to me!

The four new instructions are:

• pcmpestri: packed compare of explicit length strings, returning index
• pcmpestrm: packed compare of explicit length strings, returning mask
• pcmpistri: packed compare of implicit length strings, returning index
• pcmpistrm: packed compare of implicit length strings, returning mask

The variants are as follows:

• implicit length strings are NULL-terminated, explicit strings have an explicit length (ie. the whole input register).
• they can return an index into the source string (if you were searching for something) or a mask (if you wanted to test each character of the input

Both let you scan a 128-bit SSE register (treating it as either 16 8-bit characters or 8 16-bit characters) and perform all kinds of searches/comparisons. The instructions are configurable; you supply a control word that specifies all of the different variations of the instructions. For example, are the input values signed or unsigned, are we comparing against ranges or specific values, etc.

The reciprocal throughput of these instructions is high (2 cycles) but the latency is annoyingly slow (9 cycles). This means that you have to wait nine cycles after issuing the instruction before you can use the result. It’s hard to think of too many useful things you can execute in parallel while you’re waiting for that answer. As a side note, these figures come from Intel’s Intel® 64 and IA-32 Architectures Optimization Reference Manual, which says that the latency number is a worst case estimate:

Actual performance of these instructions by the out-of-order core execution unit can range from somewhat faster to significantly faster than the latency data shown in these tables.

I’m not enough of a hardware geek to know what to actually expect.

Still, that’s nine cycles to wait before getting a lot of really useful information. In addition to returning the index or mask, the instructions set several of the flags in useful ways.

So what processors have SSE 4.2? Or in other words, how long will my impatient self have to wait to try them out? Apparently SSE 4.2 is available on Penryn, which is the second-gen Core 2, which debuted in 2007/2008. It uses a “45 nm process”, which I’m sure means something to hardware geeks but not to me. All I know is that it’s not the Core 2 that’s inside the MacBook Pro sitting on my lap. And of course SSE 4.2 is in the new Nehalem.