multiple thread is slower???

[caperover2002]

Hi, All,

I tried to use multiple thread to speed up. Unfortunately, it becomes about 10% slower if I add one more thread, although exactly the same code is used in both cases.

I am sure my computer has two dual-core CPU's and my code is compiled with option multi-thread DLL. The only reason why it slows down, which I can think of, is that all threads are using the same CPU although there are four CPU's. Does anyone know how to test that instead of look at CPU performance?

I don't have any lock or mutex in my code, but four thread reads the same vector through iterator. Will that be a problem?

Besides this, is there any other reason that can cause mutiple thread to be slower?

Thanks,
CR

[Arjay]

You can look at Task Manager to see if all four processors are being used.

Are you sharing data between threads? If so, is there a lock on the shared data causing a bottleneck?

[caperover2002]

Arjay,

Four threads read the same std::vector through iterator, but they are not overlapping, say for example 0-1000, 1001-2000, 2001-3000 and 3001-4000.

Vector is synchronized, does this mean only one thread can access the vector at a time? If that is the case, four threads will be slower than one thread.

Thanks,
CR

[Lindley]

I could believe a vector might have some internal synchronization, although I don't think it's required to by the standard.

Easy way to check: Temporarily replace your vector with a dynamically-allocated C-style array, and see if the slowdown persists.

[Arjay]

Arjay,

Four threads read the same std::vector through iterator, but they are not overlapping, say for example 0-1000, 1001-2000, 2001-3000 and 3001-4000.

Vector is synchronized, does this mean only one thread can access the vector at a time? If that is the case, four threads will be slower than one thread.

Thanks,
CR

Yes, since you are sharing the vector between threads, the vector must be synchronized (as all shared data does when accessed by multiple threads).

Perhaps you can use a different collection or make a copy of the data while it's being processed in the thread so you don't need to lock the vector during the processing.

[Arjay]

I could believe a vector might have some internal synchronization, although I don't think it's required to by the standard.

Easy way to check: Temporarily replace your vector with a dynamically-allocated C-style array, and see if the slowdown persists.

The std::vector as implemented in Visual Studio does not have any synchronization. I believe the boost one does, but can't say about other implementations.

[zerver]

Arjay,

Four threads read the same std::vector through iterator, but they are not overlapping, say for example 0-1000, 1001-2000, 2001-3000 and 3001-4000.

Vector is synchronized, does this mean only one thread can access the vector at a time? If that is the case, four threads will be slower than one thread.

Thanks,
CR

AFAIK, std::vector iterator is thread-safe for reading, so you do not need to use synchronization/mutexes.
How long does the processing take? If processing time is very short, the overhead associated with managing the threads may defeat any performance gain.
Try increasing the processing time for each vector element (e.g. using Sleep()) and see if it still is slower than single threaded.

[Edders]

You may want to have a look at this thread as well - http://www.codeguru.com/forum/showthread.php?t=450537. Especially the post and link from MikeAThon. It describes an issue called "false sharing" where caching issues caused by multiple cores accessing data in the same cache line actually slows down the application. This may be what you are seeing as multiple threads are accessing the same vector.

If this is indeed the case then you could make each thread use a different copy of the data so that the issue is avoided.

[Arjay]

AFAIK, std::vector iterator is thread-safe for reading, so you do not need to use synchronization/mutexes.

Any shared resource is safe for reading when shared between threads, but that isn't considered to be thread safe.

[zerver]

Any shared resource is safe for reading when shared between threads, but that isn't considered to be thread safe.

Well, the resource may be designed in such a way that (apparent) reading actually involves some writes. For instance, some obscure container may contain some internal mechanism that keeps a cache of recently read values.

So, "thread safe for reading" still has a meaning.

[Arjay]

Well, the resource may be designed in such a way that (apparent) reading actually involves some writes. For instance, some obscure container may contain some internal mechanism that keeps a cache of recently read values.

So, "thread safe for reading" still has a meaning.

I respecfully disagree. The container is either thread safe or not.

'Thread safe for reading' implies that you don't need synchronization for reading (which is always true); however, the problem is that many folks will synchronize while writing, but think that they don't need to synchronize while reading. The fact is that if you ever writing to a container, you will need to synchronize access for both reading and writing.

[zerver]

I respecfully disagree. The container is either thread safe or not.
The fact is that if you ever writing to a container, you will need to synchronize access for both reading and writing.

True, but I did not say anything about writing to the container. It is a very common scenario to have large sections of code that only reads from a container.

[Arjay]

A good general rule to follow is the stl containers are not thread-safe. If you need thread safety (i.e the ability to read and write to the container from multiple threads), you'll will need to add your own synchronization. There are exceptions to this, like the boost library, but for the most part it's true.