The Programming Thread

The thing that's so illuminating about doing stuff at that level is that you realize how goddamn _hard_ everything is, with like simple string append being this elaborate maze of pain. (And going down a level to the abstract nand-gate level, it gets even harder, to the point that simple integer addition takes hours.)

And then you do regular programming, and you put in a string append, and a vestigial part of your brain is like "wow, that's going to take a lot of processor power and compute time!" until you think about it further and realize that the string you're appending to was a payload in an XML document sent over sockets in a text-based protocol (HTTP) containing results that were literally pulled off B+ trees on a disk by a database server, and that the string append, as involved as it actually is at a machine level, is this incredibly minuscule fraction of everything that's been happening behind the scenes. But you still get all huffy when someone does/doesn't use a StringBuilder for efficiency reasons, because come on.

Visual Studio Express is nice and free, although it does give you a lot of noise from Microsoft's attempts to push you into writing to their libraries and toolchain. Doing example programs can sometimes be more difficult that it should be.

I've heard people use Dev C++ before with no complaints, but it's getting a little old.

Also, Code::Blocks.

And then you spend ten years doing that kind of programming and your brain gets soft, and then you get hired onto a team where the term "hot path" actually means something again, and your crappy habits bite you in the ass for eighteen months until you learn to distrust the "new" statement with a fear and loathing you previously reserved only for absurdities like "string s = ""; for (int i = 0; i < bigNumber; i++) { s += strings\[i\]; }"

The delta between 'high level coding' and 'low level coding' is absolutely monstrous now and only getting wider.

You have the true high level language guys where performance is almost always a secondary consideration (so long as your algorithmic stuff isn't broken) and where the language provides a lot of the basic ADTs (maps/tables, vectors, strings) so that you don't make n00b mistakes (hi O(N^2)!) and you get garbage collected memory and all that hotness.

Then you have the low level guys who worry about cache line alignment, never call malloc/new, and don't link into the CRTL.

It really ought to be a false dichotomy, you should be able to have your cake and eat it too. Maybe someday you will.

I'm in a small shop, so I switch between:

1) getting the ARM booting, where.... printf? What's that? Here's a crippled version! Debugger? You really think that JTAG is going to work today?
2) Now I can write some C++ code on the ARM processor. Let's not go crazy with the new/frees here, so pick the correct container for the job, but well, we're ok.

The context switches can be jarring.

Tinkering with embedded stuff is crazy awesome from a learning perspective. The last couple of months I've been working on a Xilinx MicroBlaze system that runs Linux (and some apps from sourceforge). Going from carving out a hardware environment in your FPGA to figuring out the right kernel config to actually cross-compiling your program to run on there can give you a big picture view of how a complete system comes together much better than isolated courses dealing with computer architecture and programming could do.

So for people more used to it than I:

Is parsing back up an XML tree supposed to be painfully stupid parent of parent of parent of parent trees? Fucking with libvirt and trying to make it understand vcenter (haha), and the resulting xml is kind of irritatingly kludgy to go "I have a MAC address, which VM does it belong to?"

Basically: Fuck you XML by XMLLLLLLL

XPath makes XML bashing infinitely less painful, IMO. Assuming you've got an XPath library handy, of course. The last time I didn't, I ended up writing one rather than go without.

I have one, but it was giving me issues with what should have been basic calls. I think my "how you use xpath instead" assumed I did something first knowing how to use it. I shall read up!

Basically, I need to go up three levels and down one in order to figure out the vm name from the MAC given libvirt's rather silly domain file.

You may blame Elyscape for my appearance in this thread... I was a programmer (mostly under Linux, and then web development) from 1994-2005. I've decided to take up coding again for fun and (possibly, someday) profit, and Elyscape was nice enough to chat with me about it. Installed Python and PyQt this evening. Should be fun. (I hope!)

Fixing race conditions in code that somebody else wrote without any regard for best practices or proper synchronization. Oh, and this is in code that has to be ready for mass production in a few weeks and there isn't any time budgeted to rewrite all the broken stuff. Like, there's one single class with about 40 private members all interacting, and this class is used in a highly concurrent environment.

For example there are locks around reading/writing to containers and stuff, but if you look closely you can see some assumptions being made that simply don't hold up. Like, a message gets dispatched over a message bus, and then a note is added to a list that keeps track of sent messages awaiting replies. But there's no guarantee the reply won't arrive before the note is added (and in fact it often does). It's just assumed to be one single operation for some reason.

/rant

Eventually they'll need to be other entry added to the programmer hierarchy - quantum programming? - but for the moment multithreading is the hardest thing around.

I am often surprised at just how difficult it is. When I first started reading into it, it didn't seem so bad. My first few programs went pretty well, too. But eventually when stuff starts getting complex, the number of non-obvious things that can bite you is staggering. It's taken me a while to adapt my mental model to take into account so many more situations.

And I'm doing this in only one particular environment (C#, running on a regular windows pc, with one executable). So this is probably easymode.

Yeah, even just having two executables/separate processes running on the same PC can make things a pain. I remember doing that to fix an issue with C++/C# not interacting well. (I forget the exact error, something about C++ not respecting C# ...spaces? I'm sure it will come back to me in like two hours) So many extra little cases and wonkiness had to be caught and tracked down. Bleah.

The beauty of multiprocessing/multithreading code is that even if you have it working, it still probably doesn't work right all the time. And sometimes it may be 100% fine on a single core system, but will totally fail on a multicore system. And then you have cache coherency issues depending on the platform (read/write barriers come into play).

The safest best practices are either go 100% crazy multithread and architect with that in mind from the beginning (and code in something like, I dunno, Haskell or Erlang) or go with a single main thread, no shared anything, and communicate entirely with queues and semaphores.

That said, I do really hate playing a game and having it chug away while only using one processor. SPAZ does that, for example, it's entirely single-threaded, and considering its really just a basic 2d game, it really should run faster on.
(Granted, they could probably optimize it in other ways and suddenly it would run fine without the need to open the multi-threaded hydra, hard to say without seeing their code)

This assumes that there are intrinsically parallelizable tasks, and what I've found is that many things we think are parallel actually aren't. You can do things in parallel but inevitably there are sync points or data dependencies that kill much of the overlap or introduce latency that people find objectionable. The main area where parallelization is almost always a win is ensuring that your UI is responsive at all times -- hiccups/stutters aren't acceptable in modern software. (You can get around this by time slicing and lots of micromanagement in a single threaded code base, but it's not worth it).

Oh, and you usually want anything that is latency sensitive to sit in a high priority thread with a semaphore (audio mixing comes to mind).

Even ignoring Amdahl's law, which is unintuitive for many at the limit, finding even theoretical cases of optimal parallelism is tough. It's hard for a game to meaningfully use 4 cores, much less the 8 or more available on high end PCs, which is a shame.

That said, if I'm going to complain about games and technology, my first complaint is how so many are still 32-bit for no apparent reason.

You guys are way smarter than me.

Somewhere in the neighborhood of a quarter of PC gamers still use 32-bit operating systems (cf. the Steam hardware survey). Supporting both architectures implies a significant QA cost (since you need to test everything twice). Thus, essentially all games are still built as 32-bit binaries.

Give it a few years. With DX10/11, XP is already irrelevant for new releases, and 32-bit Windows 7 is increasingly irrelevant. I'm surprised that 32-bit Windows 8 even exists. I predict that in five years, 64-bit binaries will be the norm for AAA PC releases. The benefits (more registers, meaning improved performance simply by recompiling in 64-bit mode) should outweigh the apathy.

I didn't even know there was a 32 bit win 8. Whoa.

There are a number of things (multi-step-forward AI planning, audio, UI, preloading textures) which can benefit, or so I have heard, from parallelization. Is this not so much the case / runs headfirst into Amdahl's law? If my information is wrong, I have a person to go make fun of at some point, and I always love doing that (well, more that I love not being wrong about things).

Those benefit from running in other threads, but that's not the same as being particularly parallelizable. Audio can run in one separate thread for the most part -- so you've trimmed a couple milliseconds off your main loop, but that's it. Now what do you do with the other 2 cores, not to mention the other 90% utilization available in the audio thread core? Preloading textures helps reduce hitches, but once you've preloaded them, then what? UI can run in a separate thread, and that has huge benefits for perceive performance, but it doesn't actually make things run significantly faster overall, your UI is sleeping most of the time anyway.

So those are things that benefit from overlap, but they don't scale to 8 (or more) cores/hyperthreads.

Now AI planning could conceivably benefit because you could have N AIs simultaneously 'thinking', but I'm not sure how common that is in practice. Most people just use a generic job queue system and hope that they get some distinct benefit from it, but that's often up to the vagaries of how data dependencies unfold in the queue.

They are all fairly related concepts though and the distinctions, especially between the latter two, are mostly of academic interest. To a working programmer the key distinction is to learn to think and write code in terms of multiple things happening simultaneously and all the synchronization headaches that brings along.

Makes a certain amount of sense. The guy that I was talking to is a good friend of mine who comes to the game dev business through AI research, and one of the things he's working on as a side project is writing AI that properly benefits from - and I think this is about as direct a quote as I can remember - the unimaginable amount of unused processor power and extraordinary improvements in theory that have taken place.

He talks about something he calls "look look-squared" where he has three AI... threads? I guess? I don't know the technical details that thoroughly... which do, respectively: look for good short-term moves, look for good long-term moves, and try to figure out what the player is doing.

He also says that all of the optimization in the world doesn't help that much in the end because so much blocks on the graphical engine, and for various reasons (which he didn't explain) the graphical engine isn't amenable to parallelization.

Well, the graphics engine is hugely parallel in that most of it runs on a separate computer (the GPU) altogether =)

But that's the Amdahl Law's thing -- you're limited by the things you can speed up the most. If AI is consuming 15% of your time and you make it like 1000x faster...you still haven't really done much overall for your game.

Heh, speaking of multi-threaded, I do like how easy some of it is now in C#, at least for operations that don't need to communicate with each other.

The code was essentially:

Code (text):

1.  
2. Parallel.Foreach(EnumerateList(), F =>
3. {
4.    DoThingWithF;
5. });
6.  
7. MessageBox.Show("All Done!");
8. [\CODE]

I'm about to graduate with a degree in CS and we were never taught threading. I don't know if it's normal to teach that at an undergraduate level or not. Granted CS turns into a pure theory major the first day of your Junior year, so you go two years without being asked to program anything except for the rare project where you have to use something arcane like Haskell, (at least it sure seems arcane when all you've done is Java/C++), so when you go fire up a grossly out of date Eclipse to write a Java program for your own use during your Senior year you can't figure out why it won't compile until you realize you're declaring stuff outside of the class bracket and oh wait there needs to be a main doesn't there and hoo boy where did all of this go?

Then Charles says Love2D is great and you believe him, so you jump into LUA and have to look at the API every thirty seconds and feel like a kid in highschool AP Computer Science again.

Then the girl whose code is a chaotic poorly documented mess gets an interview with Amazon, so you feel slightly better about your future again.

Ouch. No threading? Sigh, well, to be fair, CS classes always seem to lag slightly behind what's needed in the 'real world'. Even the game programming specific ones.

Ha, ha, someone expected to learn programming at university!

Actually now that I think about it, we did do some things with threads, but it wasn't a "do this using threads" which would have been way more edifying. It was an OS class where we had to make an OS simulator (OSP?) work by implementing certain kinds of process queues (and some other things) and a large part of that was handling threads.

By that I assume you mean big-O stuff? Because that was pretty much my experience too. I wouldn't know jack about big-O without that class.

Beats an English degree.

Oh yeah it included that too. Pretty handy, but that stuff was more of a "going to have to relearn it when I actually do it." At least I've got the foundation though!

Allow me to herp my derp and say that CS curricula ain't what they used to be. Get off my yard when I'm done talking to you!

You'll learn more in your first year as a professional than you did during your entire undergraduate curriculum. You'll get paid for it too!

By "threading," do you mean concurrency concepts (critical sections, semaphores, deadlocks, monitors, etc.) in general? In my curriculum, that was in the OS class, which was semi-optional[1] and could have been skipped by someone who wanted to take a different concentration, but it was definitely something that was available.

[1] You had to take two of operating systems, programming languages (where you did stuff with a half-dozen different language families), and compilers. I missed compilers, and really wish I wouldn't have.

Wow, that is just totally foreign to me. Every CS class I had had tons of programming in it.