两种思路，查找任何匹配项所需的速度，与查找所有匹配项所需要的速度相比，与存储相比。

对于第二种情况，我想指出一个GPU并行版本，它查询所有匹配的袜子。

如果您有多个要匹配的财产，则可以使用分组元组和更高级的zip迭代器以及推力的转换函数，尽管这里是一个基于GPU的简单查询：

//test.cu
#include <thrust/device_vector.h>
#include <thrust/sequence.h>
#include <thrust/copy.h>
#include <thrust/count.h>
#include <thrust/remove.h>
#include <thrust/random.h>
#include <iostream>
#include <iterator>
#include <string>

// Define some types for pseudo code readability
typedef thrust::device_vector<int> GpuList;
typedef GpuList::iterator          GpuListIterator;

template <typename T>
struct ColoredSockQuery : public thrust::unary_function<T,bool>
{
    ColoredSockQuery( int colorToSearch )
    { SockColor = colorToSearch; }

    int SockColor;

    __host__ __device__
    bool operator()(T x)
    {
        return x == SockColor;
    }
};


struct GenerateRandomSockColor
{
    float lowBounds, highBounds;

    __host__ __device__
    GenerateRandomSockColor(int _a= 0, int _b= 1) : lowBounds(_a), highBounds(_b) {};

    __host__ __device__
    int operator()(const unsigned int n) const
    {
        thrust::default_random_engine rng;
        thrust::uniform_real_distribution<float> dist(lowBounds, highBounds);
        rng.discard(n);
        return dist(rng);
    }
};

template <typename GpuListIterator>
void PrintSocks(const std::string& name, GpuListIterator first, GpuListIterator last)
{
    typedef typename std::iterator_traits<GpuListIterator>::value_type T;

    std::cout << name << ": ";
    thrust::copy(first, last, std::ostream_iterator<T>(std::cout, " "));
    std::cout << "\n";
}

int main()
{
    int numberOfSocks = 10000000;
    GpuList socks(numberOfSocks);
    thrust::transform(thrust::make_counting_iterator(0),
                      thrust::make_counting_iterator(numberOfSocks),
                      socks.begin(),
                      GenerateRandomSockColor(0, 200));

    clock_t start = clock();

    GpuList sortedSocks(socks.size());
    GpuListIterator lastSortedSock = thrust::copy_if(socks.begin(),
                                                     socks.end(),
                                                     sortedSocks.begin(),
                                                     ColoredSockQuery<int>(2));
    clock_t stop = clock();

    PrintSocks("Sorted Socks: ", sortedSocks.begin(), lastSortedSock);

    double elapsed = (double)(stop - start) * 1000.0 / CLOCKS_PER_SEC;
    std::cout << "Time elapsed in ms: " << elapsed << "\n";

    return 0;
}

    //nvcc -std=c++11 -o test test.cu

1000万只袜子的运行时间：9毫秒

成本：移动袜子->高，查找/搜索袜子排成一排->小

我们想做的是减少移动次数，并用搜索次数进行补偿。此外，我们还可以利用智人的多威胁环境，在解密缓存中保存更多的东西。

X=您的，Y=您的配偶

从所有袜子的A堆开始：

选择两个袜子，将相应的X袜子放在X线上，将Y袜子放在Y线上的下一个可用位置。

直到A为空。

对于每行X和Y

选择行中的第一只袜子，沿着行搜索，直到找到相应的袜子。放入相应的袜子成品线。可选当您搜索线条时，当前正在查看的袜子与之前的袜子相同，请对这些袜子执行步骤2。

可选地，在第一步中，您从该行中拾取两个袜子，而不是两个，因为缓存内存足够大，我们可以快速识别其中一个袜子是否与您正在观察的行上的当前袜子匹配。如果你有幸拥有三只手臂，那么考虑到受试者的记忆足够大，你可以同时解析三只袜子。

直到X和Y都为空。

Done

然而，由于这与选择排序具有相似的复杂性，由于I/O（移动袜子）和搜索（搜索袜子的行）的速度，所花费的时间要少得多。

我希望我能为这个问题贡献一些新的东西。我注意到，所有的答案都忽略了这样一个事实，即在不降低整体洗衣性能的情况下，有两点可以执行预处理。

此外，即使是大家庭，我们也不需要假设有大量袜子。袜子从抽屉中取出并穿上，然后在洗衣服之前，将它们扔到一个地方（可能是一个垃圾箱）。虽然我不会将所说的垃圾箱称为后进先出堆栈，但我认为可以安全地假设

人们把两只袜子大致扔在箱子箱子在任何时候都不会随机化，因此从该容器顶部获取的任何子集通常都包含一双袜子。

由于我所知道的所有洗衣机的尺寸都是有限的（不管你要洗多少袜子），而且洗衣机中会发生实际的随机性，所以无论我们有多少袜子，我们总是有几乎不含单品的小子集。

我们的两个预处理阶段是“把袜子放在晾衣绳上”和“把袜子从晾衣绳里拿出来”，我们必须这样做，这样才能得到既干净又干燥的袜子。和洗衣机一样，晾衣绳是有限的，我假设我们可以看到袜子的整个部分。

以下是put_socks_on_ine（）的算法：

while (socks left in basket) {
 take_sock();
 if (cluster of similar socks is present) { 
   Add sock to cluster (if possible, next to the matching pair)
 } else {
  Hang it somewhere on the line, this is now a new cluster of similar-looking socks.      
  Leave enough space around this sock to add other socks later on 
 }
}

不要浪费时间四处移动袜子或寻找最佳搭配，这一切都应该在O（n）中完成，这也是我们将它们放在未分类的线上所需要的。袜子还没有配对，我们只有几个相似的簇。我们这里有一套有限的袜子是很有帮助的，因为这有助于我们创建“好”的簇（例如，如果这套袜子中只有黑色的袜子，那么按颜色簇就不是办法了）

下面是take_socks_from_line（）的算法：

while(socks left on line) {
 take_next_sock();
 if (matching pair visible on line or in basket) {
   Take it as well, pair 'em and put 'em away
 } else {
   put the sock in the basket
 }

我应该指出，为了提高其余步骤的速度，明智的做法是不要随机选择下一个袜子，而是从每个簇中依次选择一个又一个袜子。这两个预处理步骤只需要将袜子放在晾衣绳上或放在篮子里，这是我们无论做什么都必须做的，因此这将大大提高洗衣性能。

在此之后，很容易执行哈希分区算法。通常，大约75%的袜子已经配对，给我留下了非常小的袜子子集，并且这个子集已经（有点）聚类（在预处理步骤之后，我没有在我的篮子中引入太多熵）。另一件事是，剩余的集群往往足够小，可以一次处理，因此可以从篮子中取出整个集群。

下面是sort_maining_clusters（）的算法：

while(clusters present in basket) {
  Take out the cluster and spread it
  Process it immediately
  Leave remaining socks where they are
}

之后，只剩下几只袜子了。在这里，我将之前未配对的袜子引入到系统中，并在不使用任何特殊算法的情况下处理剩余的袜子——剩余的袜子非常少，可以非常快速地进行视觉处理。

对于所有剩余的袜子，我假设它们的同伴仍然没有洗，并将它们放在一边，以备下次迭代。如果你记录了一段时间内未配对袜子的增长（“袜子泄漏”），你应该检查你的垃圾箱——它可能会随机出现（你有猫睡在里面吗？）

我知道这些算法需要很多假设：一个充当某种LIFO堆栈的垃圾箱，一台有限的普通洗衣机，以及一条有限的普通晾衣绳——但这仍然适用于大量袜子。

关于并行性：只要你把两个袜子放在同一个箱子里，你就可以很容易地并行化所有这些步骤。

我已经采取了简单的步骤，将我的努力减少到一个需要O（1）时间的过程中。

通过将我的输入减少到两种袜子中的一种（休闲用的白色袜子，工作用的黑色袜子），我只需要确定手中有哪种袜子。（从技术上讲，由于它们从未一起清洗过，我已将过程缩短到O（0）时间。）

为了找到合适的袜子，需要提前付出一些努力，并购买足够数量的袜子，以消除对现有袜子的需求。因为我在需要黑色袜子之前就已经做了这件事，所以我的努力很小，但里程可能会有所不同。

这种前期工作在非常流行和有效的代码中已经多次出现。示例包括#DEFINE'将圆周率定义为几个小数（其他示例也存在，但这是我现在想到的）。

我在攻读计算机科学博士期间经常思考这个问题。我提出了多种解决方案，这取决于区分袜子的能力，从而尽可能快地找到正确的袜子。

假设看袜子和记住它们独特图案的成本可以忽略不计（ε）。那么最好的解决办法就是把所有的袜子都扔到桌子上。这包括以下步骤：

将所有袜子放在一张桌子上（1），并创建一个hashmap｛pattern:position｝（ε）当有剩余袜子时（n/2）：随机挑选一只袜子（1）查找相应袜子的位置（ε）取回袜子（1）并存放

这确实是最快的可能性，并且以n+1＝O（n）复杂度执行。但它假设你完全记得所有的模式。。。在实践中，情况并非如此，我个人的经验是，你有时在第一次尝试时找不到匹配的一对：

把所有袜子扔在桌子上（1）当有剩余袜子时（n/2）：随机挑选一只袜子（1）当未配对时（1/P）：找到具有相似图案的袜子拿袜子，比较两者（1）如果可以，存储配对

这现在取决于我们找到匹配对的能力。如果你的深色/灰色双鞋或白色运动袜经常有非常相似的图案，这一点尤其正确！让我们承认你有概率找到相应的袜子。在找到相应的袜子以形成一双袜子之前，平均需要1/P的尝试。总体复杂度为1+（n/2）*（1+1/P）=O（n）。

两者在袜子数量上都是线性的，并且是非常相似的解决方案。让我们稍微修改一下这个问题，承认你有多双类似的袜子，并且很容易在一次移动中存储多双袜子（1+ε）。对于K个不同的模式，您可以实现：

对于每只袜子（n）：随机挑选一只袜子（1）将其放到其模式的集群中对于每个集群（K）：取簇并储存袜子（1+ε）

总体复杂度变为n+K=O（n）。它仍然是线性的，但选择正确的算法现在可能很大程度上取决于P和K的值！但人们可能会再次反对，因为您可能很难找到（或创建）每只袜子的集群。

此外，你也可以在网站上查找最佳算法，并提出自己的解决方案，从而节省时间：）

如果“移动”操作相当昂贵，而“比较”操作很便宜，并且无论如何都需要将整个集合移动到一个缓冲区中，在那里搜索速度比原始存储快得多。。。只需将排序整合到强制移动中即可。

我发现，将分拣过程整合到晾衣架中，这一过程变得轻而易举。无论如何，我需要拿起每一只袜子，然后把它挂起来（移动），把它挂在绳子上的某个特定位置几乎不需要任何费用。现在，为了不强制搜索整个缓冲区（字符串），我选择按颜色/阴影放置袜子。左边更黑，右边更亮，前面更鲜艳。现在，在我挂上每一只袜子之前，我先看看它的“右边附近”是否已经有一只匹配的袜子——这限制了“扫描”其他2-3只袜子——如果有，我就把另一只挂在旁边。然后，我把它们成对地卷起来，然后在干的时候把它们从绳子上取下来。

现在，这似乎与顶级答案所建议的“按颜色形成桩”没有什么不同，但首先，通过不选择离散桩而是选择范围，我没有问题将“紫色”分类为“红色”还是“蓝色”桩；它只是介于两者之间。然后通过集成两个操作（挂起晾干和分拣），挂起时的分拣开销大约是单独分拣的10%。