当前，我已经在Windows Google Compute Engine VM上测试了高性能计算并行算法。但是，Google VM（可能还有大多数VM）无法正确提供物理主机的“真实” NUMA体系结构。 （例如，如果物理主机具有2个CPU插槽，8个CPU内核/插槽，并且每个CPU内核有2个超线程，则基于我的侦探工作，VM会简单而错误地报告说，一个主机中有32个CPU内核单个套接字...。它还会报告每个CPU内核的L1 / L2缓存的“奇怪”结果，因为它会“重复计数”等。）
无论如何，关键问题是：JIT编译器是否利用了所有NUMA体系结构信息，尤其是在使用jdk8并行流期货（例如“收集器”）时？ （例如，更有意义的是先尝试在收集器协议中对芯片上彼此“接近”的线程进行“合并”步骤，然后再进行“远”的线程（例如在不同的CPU插槽上）（彼此之间（也基于真实的L2高速缓存大小等，基于真实的L2高速缓存大小等以某种方式提取数据会更有意义）。 JIT与静态编译语言（例如C ++）相比的主要优势是，如果我是对的，那么当我们在“非VM”计算机上测试代码时，我们的Java程序将表现得更好。...（也就是说，是这样的优化所产生的差异不到1％，但是我认为对于高性能计算而言，将套接字之间的数据传输减至最少并充分利用缓存会带来很大的不同。）