STL中不必要的锁定？ （Visual C ++ Express） [英] Unnecessary locking in STL? (Visual C++ Express)

问题描述

在我的测试中，我发现使用多线程比使用多线程更慢。单线程。

经过一些研究，我发现我的线程花费大部分时间等待 _Lockit _Lock（_LOCK_DEBUG）。这是屏幕截图。

正如你所看到的，锁被应用在一个本地变量上，这不应该要求任何锁定！

我的问题是： / p>

• 为什么STL锁定此向量？


• 如何使我的程序更快？ （使用数组？）

更新

Visual Studio项目中的以下命令行选项：

  / D_HAS_ITERATOR_DEBUGGING = 0/ D_SECURE_SCL = 0
 

重要的是将其应用于解决方案文件中的所有项目，否则会在运行时发生错误（冲突的迭代器等） 。

我改变的第二件事是将 std :: vector< bool> 改成 std :: vector< char> 。我不知道 std :: vector< bool> 太慢了。

解决方案

如果你花费时间在LOCK_DEBUG，那么你正在使用调试迭代器。这些迭代器都跟踪它们的位置和父容器，并检测几种未定义的行为。但是，它们会增加运行时成本。

在发布模式下编译，看看是否仍然是瓶颈。可能还有其他开关或 #define 需要将其关闭 - 不是积极的。

锁定实际上需要正确的操作 - 当你从向量中读取时，你必须确保没有人在同一时间写入该向量（至少得到大多数STL实现的线程安全预期 - - 即不同的读者是安全的，即使多个作家没有）。

也请考虑不要使用向量< bool> （使用 deque< bool> 或向量< char> 或向量< int& ），因为它通常需要更多的线程开销，因为它在单个位中存储伪bool。这使得它适应更多的空间，但不幸的是，读取和写入容器不再是原子的，这可能需要更多的锁定。

I'm trying to build a Tetris AI algorithm that can scale over multiple cores.

In my tests it turns out that using multiple threads is slower than using a single thread.

After some research I found that my threads spend most of their time waiting for _Lockit _Lock(_LOCK_DEBUG). Here's a screenshot.

As you can see, the lock is applied on a local variable, which shouldn't require any locking anyway!

My questions are:

• Why does STL lock this vector?
• How can I make my program faster? (Use arrays?)

Update

I eliminated the lock by setting these command line options in my Visual Studio projects:

/D "_HAS_ITERATOR_DEBUGGING=0" /D "_SECURE_SCL=0"

It's important to apply this to all projects in the solution file or errors will occur at runtime (conflicting iterators etc).

The second thing I changed was changing std::vector<bool> into std::vector<char>. I wasn't aware that std::vector<bool> was so slow.

解决方案

If you're spending time in LOCK_DEBUG, then you are using the debugging iterators. These iterators all track their positions and parent containers, and detect several cases of undefined behavior for you. They do, however, impose a runtime cost.

Compile in release mode and see if that's still a bottleneck. There might be an additional switch or #define required to turn them off too -- not positive.

Any other locking is going to actually be required for correct operation -- when you're reading from the vector, you must ensure nobody is writing to that vector at the same time (at least to get the kind of thread safety expected of most STL implementations -- namely that different readers are safe, even though multiple writers are not). That requires locking to maintain.

Also consider not using vector<bool> (use a deque<bool> or a vector<char> or vector<int> instead), as it usually requires more threading overhead because it stores pseudo-bools in individual bits. That lets it fit more in less space but unfortunately means that reads and writes to the container are no longer atomic, which could require more locking.

这篇关于STL中不必要的锁定？ （Visual C ++ Express）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！