When this data was brought to the attention of the gcc developers on the gcc mailinglist, a very interesting and elucidating discussion followed. See http://gcc.gnu.org/ml/gcc/2009-12/msg00176.html and follow all the subthreads from there.

There is a key issue in the gcc discussions, about whether code that relies on uninitialized variables and similar make any sense. I personally think that any code that triggers warnings on one or more compilers should be disqualified, as only really portable code should be reasonable to compare in a shoot-out like this. Code that is “undefined” by the C standard really does not provide any interesting information.

Personally, I would also like to see some comparisons between compilers aiming for size, for targets where size really matters. For example, ARM Cortex-R or Cortex-M CPUs, with compilers from commercial players like ARM, IAR, GreenHills, etc. I understand that such a shoot-out is very hard to arrange in practice, however .

Another interesting measure would be the evenness or robustness of a compiler. Is a compiler consistently generating decent code, or does it swing wildly from very good to very bad? I guess you could approximate this if you compared the size for a function generated by a particular compiler to the average of all other compilers’ code for that function. Could give an interesting graph for each compiler.

The code sources are quite interesting: it is isolated functions collected from a large spread of open-source projects. Quite often it looks like the extremes of differences from one compiler to another corresponds to extreme functions. I liked this one, where clang created a file 20x the size of llvm. I can see how a naive switch generator gets big here, while an optimized switch code generator can make some very simple comparison statements out of it (this is a bit from Qemu, from a PCI device model, which is close to my interest of virtual platforms, we get this kind of code a lot).

sh_pci_reg_write (void *p, target_phys_addr_t addr, uint32_t val)
{
uint32_t *__tmp__282;

switch ((int) addr)
{
case 0:
case 1:
case 2:
case 3:
case 4:
case 5:
case 6:
case 7:
case 8:
case 9:
case 10:
case 11:
case 12:
case 13:
case 14:
case 15:
case 16:
case 17:
case 18:
case 19:
case 20:
case 21:
case 22:
case 23:
case 24:
case 25:
case 26:
case 27:
case 28:
case 29:
case 30:
case 31:
case 32:
case 33:
case 34:
case 35:
case 36:
case 37:
case 38:
case 39:
case 40:
case 41:
case 42:
case 43:
case 44:
case 45:
case 46:
case 47:
case 48:
case 49:
case 50:
case 51:
case 52:
case 53:
case 54:
case 55:
case 56:
case 57:
case 58:
case 59:
case 60:
case 61:
case 62:
case 63:
case 64:
case 65:
case 66:
case 67:
case 68:
case 69:
case 70:
case 71:
case 72:
case 73:
case 74:
case 75:
case 76:
case 77:
case 78:
case 79:
case 80:
case 81:
case 82:
case 83:
case 84:
case 85:
case 86:
case 87:
case 88:
case 89:
case 90:
case 91:
case 92:
case 93:
case 94:
case 95:
case 96:
case 97:
case 98:
case 99:
case 100:
case 101:
case 102:
case 103:
case 104:
case 105:
case 106:
case 107:
case 108:
case 109:
case 110:
case 111:
case 112:
case 113:
case 114:
case 115:
case 116:
case 117:
case 118:
case 119:
case 120:
case 121:
case 122:
case 123:
case 124:
case 125:
case 126:
case 127:
case 128:
case 129:
case 130:
case 131:
case 132:
case 133:
case 134:
case 135:
case 136:
case 137:
case 138:
case 139:
case 140:
case 141:
case 142:
case 143:
case 144:
case 145:
case 146:
case 147:
case 148:
case 149:
case 150:
case 151:
case 152:
case 153:
case 154:
case 155:
case 156:
case 157:
case 158:
case 159:
case 160:
case 161:
case 162:
case 163:
case 164:
case 165:
case 166:
case 167:
case 168:
case 169:
case 170:
case 171:
case 172:
case 173:
case 174:
case 175:
case 176:
case 177:
case 178:
case 179:
case 180:
case 181:
case 182:
case 183:
case 184:
case 185:
case 186:
case 187:
case 188:
case 189:
case 190:
case 191:
case 192:
case 193:
case 194:
case 195:
case 196:
case 197:
case 198:
case 199:
case 200:
case 201:
case 202:
case 203:
case 204:
case 205:
case 206:
case 207:
case 208:
case 209:
case 210:
case 211:
case 212:
case 213:
case 214:
case 215:
case 216:
case 217:
case 218:
case 219:
case 220:
case 221:
case 222:
case 223:
case 224:
case 225:
case 226:
case 227:
case 228:
case 229:
case 230:
case 231:
case 232:
case 233:
case 234:
case 235:
case 236:
case 237:
case 238:
case 239:
case 240:
case 241:
case 242:
case 243:
case 244:
case 245:
case 246:
case 247:
case 248:
case 249:
case 250:
case 251:
case 252:;
__tmp__282 = (uint32_t *) ((((SHPCIC *) p)->dev)->config + addr);
*__tmp__282 = val;
break;
case 448:;
((SHPCIC *) p)->par = val;
break;
case 452:;
((SHPCIC *) p)->mbr = val;
break;
case 456:;
((SHPCIC *) p)->iobr = val;
break;
case 544:;
pci_data_write (((SHPCIC *) p)->bus, ((SHPCIC *) p)->par, val, 4);
break;
}
return;
}

Thanks to the community transcripts wiki:

Spolsky: Quite probably. I mean C is a car, it’s very dangerous – it doesn’t have seatbelts, but it’s very powerful because it goes very fast. In fact, I’d go so far as to say, unless some people are gonna punch me about this one, but you cannot write multi-threaded code in the C programming language. You just can’t. Although technically all the capabilities are there, it is beyond the capability of mortal humans – and I know, some of you out there are very smart and you think that you have the capability of writing multi-threaded code in the C programming language, because you’re hot shit. Well, let me tell you, it is beyond the capability of humans on this planet, for their brains are just not adequate to the task of writing multi-threaded code in most languages, least of all low-level languages like C. It’s just not gonna work, it’s just not gonna make you happy. So there.

The only problem with this statement is that it means we are all doomed: since all operating systems are written in C, and all low-level libraries, it means that we have no way to build the first level of abstraction needed to provide the higher-level primitives for C# and Python and everything else higher up the stack.

But in general, I think this is a fairly true statement for volume programming.

But note that the application IS written in C++ still: that is the only choice on the xbox where the project started, by design by Microsoft. However, you can use my favorite scripting language Python to script and skin the application.

The interesting material in the article is the background on WHY he thinks that this is the case. He points to the immense popularity and rise of scripting in much of computing land. In the past ten years, it is clear to him (and I would agree with this too mostly) that languages like Perl, PHP, Awk, Ruby, JavaScript, and Python have eclipse Java and C++ as the most interesting and important programming languages for many practical tasks. Especially for web applications, where Java seems to have a presence but noone would dream of using something as clunky and impractical as C.

What can this teach us for the purpose of simulation and the creation of models of computer system hardware for the purpose of simulation? Maybe a fair bit…

The reason that scripting languages have gotten so popular is primarily that they let you get the job done faster. In web land, this is due to a few important factors listed or hinted at in the article:

• The overall code tends to be shorter and more to the point
• A tendency to make any value into a string when needed (excellent debugging aid)
• Dynamic typing, variables that just appear when needed
• Automatic memory management
• Ease of handling strings
• Most tasks are pretty short
• Performance of computation does not matter very much when processors are as fast as they are today and a single disk or network access operations is likely to dominate programming time

What the article continues with a discussion that we need to focus on programming language pragmatics rather than syntax or semantics. How practical is the language for the everyday tasks of a programmer? And it seems that simple darwinian evolution has propelled scripting-style languages to the top of heap here. Purity and elegance and deep semantical properties are obviously less important than getting the job done in the shortest time possible.

What can this teach us modeling folks?

• A key takeaway is the focus on short code. Code has to be short and focused to be quick and easy to write. You should not need to consult several header files and lots of documentation to understand and formulate your code, which is an ill that keeps hitting C and C++ programs.
• Memory management has nothing to do in a productive programming environment.
• Basic types have to be appropriate to the task at hand.
• Syntax has to be concise and powerful.
• Dynamic typing is much faster to code with than static typing and variable declarations.
• An interactive “try it out” environment is preferable to long compile/link/test cycles.

Obviously, some of these do not translate well into hardware modeling. Hardware entities tend to have very-well-defined types by nature. If I have a 16-bit register containing a 13-bit counter and three status bits, I cannot very well let that counter be a dynamic variable that can take on any numeric value. Or the atom “foo”. It kind of has to be restricted in semantics to how the hardware would behave… it is not just a “value” to be manipulated quite abstractly. Which means that what you probably rather need are types well-suited for the task at hand.

It is also nice if variables can just pop into existence when needed, with the least amount of declaration possible. Another C-family performance killer is the annoying need to declare a function before calling it. That made sense in linearly scanning compilers back in the 1970s, but today, just let the compiler take the entire program into account and find the function. It is not that hard, especially not for the quite small and isolated context that a virtual platform device model is (few device models are more than a few thousand lines of code in my experience).

The interactive nature of scripting is also interesting. The ability to just write new code directly into a running system without an explicit compile usually rests on a virtual-machine approach and does have some cost in terms of performance. And unlike webservers, virtual platforms need all the raw CPU performance they can get! However, it make excellent sense to use an interactive environment to prototype and test things, and then move the resulting code to a harder compile stage.

Right now, we really do not have such a tool at hand. Virtutech DML is in my opinion the most promising step along this road, but it is not really “perl for modeling” at this time. SystemC has too many C++ roots to really behave well in this respect… you get all the drawbacks of explicit memory management, rampant headerfiles, and statically declared types. It might be good to compile, but it sure is an absolute pain to write.

And if we want virtual platforms to really fly, it is not so much “all about the models”, but really “all about model programming” — since there is a huge volume of models that need to written out there, and getting the time needed to write these models down is a primary concern. The total work invested in modeling any particular device is what we need to focus on, really.