A place to discuss and present upcoming features for the SWG:ANH Server


Postby Researcher » October 3rd, 2011, 12:55 pm

Last edited by Researcher on October 29th, 2012, 5:43 pm, edited 1 time in total.
Posts: 1
Joined: October 3rd, 2011, 12:52 pm

Re: Increasing Performance by replacing TBB Concurrent Hashmap

Postby Kronos » October 3rd, 2011, 2:44 pm

Hi there Researcher,

I'm one of the primary developers of this application, while our application is pretty thread heavy I do not believe it would be a good performance test. We are still pretty early in getting actual content in to the application and as such there isn't much inserting/updating or removing elements from the hash table.

I would appreciate it if however after you finish your research that you would share the information with us as we're always looking for ways to make this application better.

I wish you much luck in finding a suitable project and in your endeavor to replace TBB hash map with a wait-free hash table!

ANH Developer
Retired SWG:ANH Staff
Posts: 108
Joined: May 21st, 2010, 11:53 pm
Location: North Idaho
SWG Official Server: Wanderhome

Re: Increasing Performance by replacing TBB Concurrent Hashmap

Postby apathy » October 3rd, 2011, 5:32 pm

Thanks for the interest in our project. I wanted to take a moment to put a few technical points in that will hopefully help in your endeavor.

1. Is there significant inserting, updating, or removing elements from the hash table through out the application? (not just initialization)

In our particular hash table usages the bulk of inserting/removing happens at application or startup. The particular purpose of our usage of the concurrent hash map is to provide concurrent access to data in the map.

There are of course further guarantees which must be made to ensure the elements of the map that are accessed concurrently prevent contention on their respective shared states, although that's another topic entirely.

2. Is there alot of thread contention during those operations?

The most common scenario in our concurrent hash map usages is to get a handle to a Game Object and then privately perform operations on it in a given context. Game Objects themselves are isolated and use asynchronous message passing for communication. This approach significantly reduces the amount of contention during high level operations.

3. Is there other lock based data structures that cause performance issues?

When using lock or lock free data structures in a concurrent context there are a number of pitfalls you can fall into. The one thing I've noticed through experimentation and testing is that regardless of lock or lock-free solutions, contention on the cache-lines (accessing data that is too close to data being accessed by another thread) will significantly impact performance (in a bad way). Being aware of this type of pitfall is absolutely necessary to writing any type of container that is used concurrently.


With your questions answered I just have a few final points to make. As a researcher I'm not going to dissuade you from your quest to increase performance through lock-free alternatives. I will state that writing good lock-free solutions is extremely hard, even for those that know what they are doing. Over the course of this project I developed at least 2 different lock-free queue implementations, both were very difficult to get right and even then had issues with some edge cases. In the end, after all this research, TBB was decided as a best approach for us both in terms of performance and maintainability.

Good luck on your research and I hope to hear back from you on your results.
~ May the Source be with you ~
Retired SWG:ANH Staff
Posts: 57
Joined: July 16th, 2009, 12:36 am
SWG Official Server: Naritus

Return to Feature Proposals

Who is online

Users browsing this forum: No registered users and 1 guest