与kdb中的两种方法相比，每种方法都需要更多的时间来运行操作

据我了解,， 当应用于一元函数时，每个both（'）都使用一个线程来执行操作，每个previor（'）：）使用所有可用的从属（线程）来执行操作

每个在内部使用两个，peach在内部使用每个previor

q)each
k){x'y}
q)peach
k){x':y}

出于好奇，我检查了是否每一个Previor执行一个操作所需的时间比每一个Previor都少，但似乎每一个Previor即使在大的操作数大小之后也要花费更多的时间

很少观察到：

q)\t:10000 type '[(1h;2h;3j;4.2)]
3
q)\t:10000 type ':[(1h;2h;3j;4.2)]
120
q)\t:10000 type '[(1000#1.2)]
275
q)\t:10000 type ':[(1000#1.2)]
1154
q)\t:10000 type '[(10000#1.2)]
2765
q)\t:10000 type ':[(10000#1.2)]
16035
q)\t:10000 type '[(100000#1.2)]
27587
q)\t:10000 type ':[(100000#1.2)]
153916

q)\t:10000 type each (10000#1.2)
2774
q)\t:10000 type peach (10000#1.2)
16127

Number of slaves in my env are 2
q)\s
2i

---

是我遗漏了什么，还是我们可以得出结论，对于作为操作数的单个列表，将一元函数应用于每一个操作数，两者都比之前的更快。

任何潜在的多线程应用程序都需要权衡IPC序列化和传输的成本与并发计算的好处。一般来说，应用程序将从使用

q)each
k){x'y}
q)peach
k){x':y}

减少输入和输出的大小，因为这将在一定程度上减少IPC开销（序列化和传输总是会产生影响）

增加计算强度

有鉴于此，对于简单的操作（如

类型

），我预计当使用

peach

时，随着输入向量的增加，性能会略有下降，因为这会放大线程操作对IPC序列化的影响然而，我无法重复您的结果，我的

每个
都与
peach
相当。我将考虑升级到<代码> 3.6 /代码>，如特里所建议的，我相信它有一个更有效的IPC序列化方法，减少了多线程< /P>引入的开销。
所有这一切并不意味着MultiHeading不会改善您已测试的操作。对于大型输入列表上的mondadic操作（特别是对于小型输入/输出），
peach
不是一个合适的多线程实现，因为它引入了许多IPC序列化和传输开销，输入中的每个项都被单独发送到给定的线程。但是考虑到这些操作很容易矢量化，因此.Q.fc（function cut）的性能会更好，这将通过将输入向量分块成n个块并将这些块发送到每个
s
线程来减少IPC开销

q)(.z.o;system"s";.z.K;.z.k)
`w64
4i
3.6
2019.07.25
q)\t:100 type each (1000000#1.2)
3995
q)\t:100 type peach (1000000#1.2)
3615
// type can easily be vectorized through a simple lambda {type each x}
q)\t:100 .Q.fc[{type each x};(1000000#1.2)]
1890

我建议您阅读
上的白皮书，我认为对于简单的原子操作，单线程的性能通常优于使用从线程。当跨多个分区使用HDB数据时，从线程通常是有意义的，特别是当这些分区存储在不同的物理设备上时。同意-只有在（a）处理大量数据并可并行化和/或（b）执行操作时，从线程和peach才会更快返回少量数据，以最大限度地减少序列化和将数据从从属线程发送到主线程的开销，反之亦然。你的例子不符合这种模式。然而，您的计时似乎有点不对劲…..6x计时差异不是我所看到的（我只看到在l64 v3.5中使用peach时稍微慢一点）-您使用的是什么操作系统和kdb版本？它可能非常依赖于硬件，具体的硬件实现有序列化的成本。事实上，我对每个版本都使用peach（10000#1.2）类型的peach操作，运行3.6 2019.06.03，从而缩短了时间。。对于更复杂的列表，情况并非如此，因为meIt的第一个示例根据版本有很大的不同。问题中的操作系统是Linux，kdb版本是3.3。
peach
性能（在本例中）似乎从v3.5开始有了很大的提高。如果你需要升级，你可以考虑升级。