Game Design, Programming and running a one-man games business…

Category: programming

Multithreading concurrency bug?

I have a theory, help me out if you know about this stuff. take the following image from the visual studio concurrency profiler for GSB2 pre-draw code…

8156,6792 and 8404 are my additional worker threads I spawn to help me process stuff. Click to enlarge…

threadsWhat I do is basically build up a queue of tasks. The threads are always running and checking for whats next available to process for them. Meanwhile the main worker thread also does the same thing, ensuring it is not idle while the other threads are busy. Critical sections surround access tro the queue stuff to ensure there are no nasty bugs.

I think my problem is illustrated by the red section with the black line connecting above it. This is a thread sat there doing nothing. Here is what I think happens…

  • The main thread builds up the queue of stuff to do.
  • 6792 jumps in and grabs a task to do
  • 8404 jumps in and grabs a task to do
  • The main thread then thinks ‘right then, I’ll do this next task’
  • 8156 wants to jump in now and also grab a task, but the main thread is busy doing actual work. In fact, it seems to ‘miss’ its opportunity to grab a task for ages, even though the other threads do ok getting task after task.

Is this just a problem of my code design because the allocation of tasks is done by a thread that is not otherwise idling? It seems horribly wasteful to have a whole thread work just as a 99% idle ‘task allocator’. I thought cpus were clever enough to allow interruption of one cpu by another in these instances?

I know I could queue up the tasks ahead of time, but each task takes a variable amount of time, and also varies each frame. I *could* work off the last known task timings and write a clever allocator that tried to assign things in the best order, but that seems possibly like overkill, and something the cpu surely handles anyway? Or am I totally misreading this data. IO checked a few frames, they all seem to have the same pattern.

Optimizing dilemma of the day

Below is an image from Gratuitous Space Battles 2‘s ship design screen. On the left is my problem. That’s a load of ship components you can add to a hull, rotate, change size, color etc. All very cool. The problem is that you might choose to have BIG versions of some of them, as main structure bits, so the source graphics have to be big, normally 256sq for sub-components.

blog

Ok, so that’s cool, but the problem is, when I load in those icons I’m loading in a DDS file that is 256 square, which means about 170k in the format I’m using. If I have 300 of them (rough guess) then that’s 51MB of file access, which is bad but not catastrophic, but it does mean 300 distinct file accesses, which is slow, even after I’ve rewritten the DDS loader to be massively faster. As a result, when you click on ‘edit appearance’, there *might* be a slight delay, which is intolerably awful for someone like me with zero patience. And I have a FAST PC, I want this to be fast and smooth on low-spec.

So as I see it the options are:

1) Only load visible ones, then load the others as you scroll (could be irritating for scrolling)

2) Load in placeholders, and spin off the file accessing portion of the texture load into a separate thread, then when they are all there, interleave the texture creation with the display frames of the main thread (DX9 so only main thread may do DX stuff). This seems ultra complex and hacky.

3) Save out small preview images for each item, and load those instead. Less memory, but a bunch of useless duplicate files AND still 300 file accesses.

4) Stick em all in a single big pak file and see if that’s quicker. This is easy, but I find it messy during development as I’m always adding/removing/editing files in those folders, so I need a hybrid debug/release system.

I think I might have to go with 4…

I know file access is slow but….

As a programmer, you learn fairly early on that file access is very slow. The slowest place to get data is the hard disk, we all know that. Ok, maybe tape storage. But it always amazes me just *how slow* it can be. I don’t mean the stuff like reading a texture file from disk, you expect that to be tiresome, but just file-system operations stuff. I guess I’ve always assumed that because modern hard drives have cache chips on them, and we also have a LOT of RAM available to page stuff, that querying the NTFS (or whatever file system you have)  file table should be fairly quick.

In other words, seeing if a file exists, or enumerating files in a folder shouldn’t take an age, if I’m not actually going to load in the contents. Doesn’t windows know enough about optimizing to page chunks of the FAT into RAM?

Maybe it can’t, or it doesn’t work that way, but I have discovered, to my mild surprise that if you don’t want to use compressed or locked pak files (I like an open file structure to encourage investigative modders), it actually makes enormous sense from a performance POV for you to scan your whole game folders file structure into disk and manage your own file-cache for stuff like enumerating filenames later on.

Why would I not know what files to access already? Well GSB2 writes a lot of files at runtime, and it also handles some objects having companion lightmap files, or sometimes not. The simplest and most flexible system is for it to check for companion files at runtime on startup, and then field any FileExists() calls internally. It’s faster. And I mean its 10x as fast, we aren’t talking 1% speedups here. Things are now getting to the point where I just assume all O/S code is sluggish bloatware and write my own versions whenever possible. I might eventually have to do some trickery involving multi-threaded file-loading, or loading in only specific mip-maps from files at specific points.

I do actually REALLY enjoy this kind of thing, which is a pain because I should be fixing bugs, implementing features and generally trying to keep GSB2 on schedule. Not to mention some new D3 DLC and the TOP SECRET THING. Oh and SMTG.

It’s a good thing I already have a holiday booked this year, as I’d never book one now if I’d waited this far :D

Gratuitous Space Battles 2 : First battle video!

Well I’ve been working on this beast long enough, so it’s time to share my efforts with you wonderful people of the internet. I have a whole bunch of stuff I’ll eventually talk about and show to you, but I thought I’d start off the Gratuitous Space battles 2 videos with a decent 9 minute explanation by me of the stuff that is new (so far) in the graphics engine for the GSB 2 battles. There is a lot to talk about:…

I tend to do more written stuff than videos just because I find the majority of video content moves ‘too slow’ for me. I want all the information and spectacle of stuff condensed as much as possible because I take information in very very fast. If someone has a really slow speaking voice it’s even more agonizing. But hey, I’m not the audience, you are, and the good people of the internet seem to prefer video content to written, so I’m going to try and do my bit to keep up with your youtube-watching ways. or twitch, or whoever is cool this week :D

It’s difficult because I hate my own voice, and I have broadband (ha!) delivered by a sliver of copper the size of an angels nostril hair, so my upload speed is about 45kb/s on a GOOD day. This vid took nearly 4 hours to upload. Grr. Luckily I should have a chance of getting fiber here in December.

Anyway, enjoy the vid, post any comments here or on youtube or on the GSB2 official forums. I have more stuff to show off in a few weeks!