ls.comp

Torque CPU performance.

2008-06-02T18:52:00.003-07:00

This could *significantly* reduce my CPU usage:

From http://www.garagegames.com/blogs/3182/12447:

Torque and CPU usage

Of all of the performance /
scalability considerations of stock TGE 1.5, this was my first concern.
A single dedicated server running on a very nice Linux box (Dual CPU /
Dual Core 64 bit AMD Opteron with 2gb RAM) consumed over 50% of the
CPU... and that was an empty server!

The problem is that
although on the surface the engine appears event driven, it's actually
polling the event queue instead of waiting on the event queue and it
has a sleep() that essentially makes it poll once per tick (1/32 of a
second). The problem is the stock sleep implementation turned into a
sleep(0), which essentially did nothing except give up the current time
slice and made the game engine run in a fairly tight loop.... this is
ok if you're running a single zone server per CPU, but if you're
wanting to run 10 zones on a dual CPU box then... well... it's not
going to happen.

The quick fix is to re-implement sleep() so
that it sleeps for the appropriate amount of time. An empty server
takes negligible CPU, and a decently loaded server only takes about 5%
of the CPU... awesome!

Long-term fix is to eliminate the polling
and make everything event driven, although at the moment it doesn't
appear that this solution is required. You'll end up running out of
memory before you run out of CPU cycles (10 zones on a single box
pretty much chews up all 2gb of RAM).

Torque on OpenSolaris

2007-10-19T07:57:00.000-07:00

Just got it running. SXDE 9/07, Sun Ultra 40 M2.

What I needed:

Solaris 10, Developer Edition (This is called SXDE for short)

The Torque game engine

pkg-get

patience

The main gotchas:

You'll need a new SDL. pkg-get -i libsdl

You'll need OpenAL. pkg-get -i openal

cpp -dM will show you that 'sun' is defined by the preprocesser. You'll have to modify the code to #ifdef sun/#undef sun/#endif in a few places. Just let the error messages guide you.

The Makefile's pretty close to the standard conf.UNIX.mk

nasm (you'll have to make & install that, but it's literally configure ; make && make install) will need -f elf -dLINUX to do what you want correctly.

OpenSolaris: A better model for open-source support

2007-10-07T22:40:00.000-07:00

One real problem with many support vendors for open source software is that they're not the original authors. The obvious problem is that they may not know what they're really doing, and may end up hacking up a solution that hurts other aspects of the system.

The less-obvious problem is that the changes may not get pushed upstream. If the author of the software doesn't care about your problem domain (e.g. Linux for anything but big iron), your changes may very well be ignored on the further release.

The real problem is power: you don't really have any. There aren't any strings to pull. The common phrase is "nobody to sue," but the real truth is "no accounts to cancel." Without hitting someone's wallet, they don't need to care about you. No matter how much you need this system to work, there's not much you can do to make it fit your needs better than prayer.

There are third-party vendors who will offer you support. They'll take a version of the open source product you need and they'll make sure it works with your stuff. But, you'll have to pay for the work to be redone every time the system changes. They're the wrong people. It's like complaining to your mistress about your wife — you feel better about it, but it doesn't do anything about your problems.

Something lots of open-source kids don't get: it's ok to pay for software. Because some software's free makes it bad for other stuff to cost money. They shove the word proprietary on there, to make that point.

Of course, these kids are idiots. Throwing money in the picture doesn't automatically make software less good.

Paying money gets you something. It's a string on the vendor. They like your money, they want it again. Hell they've probably promised their investors 300% returns based on the assumption that you'll pay them more later.

Which is why I like the OpenSolaris model. Pay Sun to get OpenSolaris to do what you want, and the next version of OpenSolaris will do what you want. You attach that green paper string to the right place. That string will take pulls as long as you've made it thick enough. When you're doing $5 million a year in operations, a couple thousand is really, really cheap insurance.

A lot better than paying IBM to fix Linux again for you.

Technorati Tags: operations, open source

Flex

2007-03-02T20:15:00.000-08:00

Designing good software's hard for many reasons. The essence of a good design is a good mix of flex and constraints.

Think of them as muscle and bone tissue. The constraints are hardpoints that give you leverage, while the muscles move those hardpoints into different configurations.

Using Flex During Development
Early in a system's development, you have all the speed you want, with very little existing code to pull around. This is a great time to intentionally overflex. Specifically, design interfaces and data structures to be excessively simple and flexible, with the understanding that you'll have to tie them down more later.

For example, lots of my early designs are little more than elaborate combinations of Hashtables and simple structures like this:


public class Entry {
  String name;
  Hashtable<java.lang.Class, Object> attributes;
  Hashtable<String,Entry> children;
}

I don't know what stuff I'm shoving into Entry yet, so I just key it by its type, which will be some interface the object implements.

Later on, I'll look at what interface classes I've implemented that end up in attributes and start adding specific members for them as needed. When I'm pretty sure it's going well, I'll try commenting out attributes and seeing what still complains.

Reflection and even plain C++ RTTI can come in really useful for this sort of stuff.

The Entry nicely builds a hierarchy. How about we try and serialize this into XML? Put out an <entry> tag with a name attribute, and then normalize the Class names and use them as attribute names, with the Object.toString() method as the value. Shove the children inside and you've got something you can manipulate.

Or, replace Entry with a normal DOM node and play with XPath, XQuery, and XSLT to do your work for you. Compiling an XSLT into a class and then running it against your data structure's not a bad way to go. Frankly I'd stick with the DOM approach until I was sure I couldn't get away with it. A few minutes playing with ways to hack the design around this decision can make a go/no-go decision for me.

The big point behind this is not to commit to any design before I know what's going on. Software development's an exploratory process, so there's no point in getting overcommitted early when I'm sure I'll have to change it later.