cgvis the IT thing

Gold Linker working in Ubuntu

Yeah, the Ubuntu Guys fixed the Gold Linker Package. Speed difference is incredible, now we need LLVM. Some problems are still there: GNU ld respects folders in /etc/ld.so.conf.d/, gold does not (e.g. it doesn't find libs in /usr/local/lib).

Useful things StackOverflow

Useful discussions on StackOverflow found in the last time:

• Recursive Locks vs. Non-Recursive Locks
• How do I recover a semaphore when the process that decremented it to zero crashes?. The solution with file locks seems to be good. Maybe file mapping / file locks should replace SharedMemory/Semaphore Combinations anyway.

From Signals back to Callbacks (Results)

See this Post for my motivation.

With the exchange of boost::signals2 to boost::function as delegates the project saved around 40% compilation time and 10% executable size. There are even Faster Delegates, may be we should give them a try.

From Signals back to Callbacks

Most signals in our project are never planned to be a signal, e.g. whole communication between looslely coupled parts of a component. They could be exchanged through non-thread-safe callbacks (with boost::bind / boost::function) instead of boost::signals2' signals, as we know their instantiation time (during component init) and they usually just link to one object. Interestingly not only performances increases, also compile time seems to be heavy bound by boost::signals2. The compiler was g++ 4.4 (current Ubuntu)

Qt4 (Console) to Boost migration

(Note: this contains flame and half knowledge)

The last two months, I hat to migrate one small project from Qt4 to Boost to make it fit better into one bigger project. Fortunately it did not contain GUI stuff (this may be remain Qt).

This migration showed me three things:

1. Qt does improve a lot of things and you get accustomed to it.
2. Qt signals suck.
3. What to replace with what.

Don’t call your global variable ‘socket’

This small C++ issue ate my day yesterday. If you call your global variable 'socket' the compiler will use it for the socket-syscall (even when called by ::socket).

Ok, who would do that? In the same file you get the error:

main.cpp:5: error: ‘int socket’ redeclared as different kind of symbol
/usr/include/sys/socket.h:105: error: previous declaration of ‘int socket(int, int, int)’


But when done in a seperate file you will just get a SIGSEGV error at the call to socket (..) without a chance finding out whats the trouble. Especially when you don't use the socket function directly, e.g. it's hidden by boost::asio.

GGP Reasoner online

The General Game Playing Reasoner (C++, LGPL3) is now online. It consists of a logic unit (unify and such things, you remember from your AI course ) and a Game Description Language (GDL) abstraction layer.

You'll find it on the General Game Playing Website of TUD.

Fast std::string on the stack & fast string concatenator

So, as I promised, here are some techniques I used to speed up the logic system in the General Game Player module. The logic subsystem is using the standard unify-approach from the book Artificial Intelligence - A modern approach. By doing this there are a lot of string operations which were slow when using std::string for the strings and std::ostringstream for concatenation. On the other side, I did not wanted to loose the object oriented approach, so I did not used C-Strings.

But StackStrings These are small objects covering a C-String (char [] field) and providing operations like substr(), length() and conversion operators. The recursive unify algorithm garantuees that the length of the strings (at least most) will not get bigger, so it is possible to allocate the string on the stack and let all subfunctions use them. The string is not 0-terminated, it has it's length as a second member variable. This makes it possible to generate a substring just by providing a pointer and the length of the original string, without copying and inserting a 0.

How to use?

// Allocating by Hand
char field [length];
SString s (field, length);
// Doing this with a Macro
STACKSTRING (field, s, length);
s.setTo ("what ever you want it to have");
// now all functions can use s as long as the memory on the stack exists (no allocation & deallocation)

The profiler showed me no significant string operation consts anymore; before it was >50% just by allocation & deallocation.

The other slow part I found was std::ostringstream for string concatenation. When you gurarantee, that all strings live until the final concatenation, then you can use it. Original std::ostringstream copies all and does some thread locking which was not necessary for me.

FastStringCollector collector;
std::string a; SString b; // for SString see above
collector << a << b;
std::string c = collector.str(); // collection will be done all here.

So both classes are not as powerful as the C++ STL variants but much faster in the special cases for me.

The stackstring can be fond here: stackstring.h
The fast collector here: faststringcollector