测试多线程对多核cpu的分支预测的影响

简介: 前言:现代的cpu都有流水线,分支预测功能,CPU的分支预测准确性可以达到98%以上,但是如果预测失败,则流水线失效,性能损失很严重。

前言:

现代的cpu都有流水线,分支预测功能,CPU的分支预测准确性可以达到98%以上,但是如果预测失败,则流水线失效,性能损失很严重。

CPU使用的分支预测技术可以参考:

处理器分支预测研究的历史和现状.pdf

同时多线程处理器上的动态分支预测器设计方案研究.pdf


正确地利用这些特性,可以写出高效的程序。

比如在写if,else语句时,应当把大概率事件放到if语句中,把小概率事件放到else语句中。

但是通常这种考虑都是基于单线程的,在多线程下有可能出现意外情况,比如多个线程同时执行同一处的代码。

测试:

下面基于Intel Core i5的一些多线程分支预测的测试。

测试思路(真实测试时发现不止以下三种情况,详细见下面的测试结果):

两个线程执行同一处代码,而if判断总为true。

两个线程执行同一处代码,一个的if判断总为true,另一个的if判断时为true,时为false。

两个线程执行不同的代码(逻辑功能一样,只是位置不同),一个的if判断总为true,另一个的if判断时为true,时为false。

代码如下:

其中test1测试的是同一处代码,当传入偶数参数时,则if判断总为true,当传入奇数参数时,if判断时为true时为false。

test2函数测试的是不同一处的代码,当传入偶数参数时,则if判断总为true,当传入奇数参数时,if判断时为true时为false。

import java.util.concurrent.CountDownLatch;
public class Test {
	public static int loop = 1000000000;
	public static int sum = 0;
	public static CountDownLatch startGate;
	public static CountDownLatch endGate;
	
	public static void test1(int x1, int x2) throws InterruptedException{
		startGate = new CountDownLatch(1);
		endGate = new CountDownLatch(2);
		new Thread(new T1(x1)).start();
		new Thread(new T1(x2)).start();
		Test.startGate.countDown();
		Test.endGate.await();
	}
	public static void test2(int x1, int x2) throws InterruptedException{
		startGate = new CountDownLatch(1);
		endGate = new CountDownLatch(2);
		new Thread(new T1(x1)).start();
		new Thread(new T2(x2)).start();
		Test.startGate.countDown();
		Test.endGate.await();
	}
}

class T1 implements Runnable{
	int xxx = 0;
	public T1(int xxx){
		this.xxx = xxx;
	}
	@Override
	public void run() {
		try {
			int sum = 0;
			int temp = 0;
			Test.startGate.await();
			long start = System.nanoTime();
			for(int i = 0; i < Test.loop; ++i){
				temp += xxx;
				if(temp % 2 == 0){
					sum += 100;
				}else{
					sum += 200;
				}
			}
			Test.sum += sum;
			long end = System.nanoTime();
			System.out.format("%s, T1(%d): %d\n", Thread.currentThread().getName(), xxx, end - start);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}finally{
			Test.endGate.countDown();
		}
	}
}
class T2 implements Runnable{
	int xxx = 0;
	public T2(int xxx){
		this.xxx = xxx;
	}
	@Override
	public void run() {
		try {
			int sum = 0;
			int temp = 0;
			Test.startGate.await();
			long start = System.nanoTime();
			for(int i = 0; i < Test.loop; ++i){
				temp += xxx;
				if(temp % 2 == 0){
					sum += 100;
				}else{
					sum += 200;
				}
			}
			Test.sum += sum;
			long end = System.nanoTime();
			System.out.format("%s, T2(%d): %d\n", Thread.currentThread().getName(), xxx, end - start);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}finally{
			Test.endGate.countDown();
		}
	}
}

因为测试的情况多种,简洁表述如下:

一个test1函数会有两个结果,如test1(2, 3)得到两个结果2.1s,2.2s,表示两个线程执行同一份代码,一个的if判断总是true(2是偶数),另一个的总是false(3是奇数),其中第一个线程平均执行一次计算的时间是2.1s,第二个线程平均执行一次计算的时间是2.2s。

测试的main函数中有两个for循环,每个10次。在表述测试结果时,用简略表示,如:

一行数据表示执行一次main函数的结果,后面的时间是粗略平均计算得到的

test1(2,3) 2.1s 2.1s test1(2,4) 2.1s 2.1s


main函数:

	public static void main(String[] args) throws InterruptedException {
		for(int i = 0; i < 10; ++i){
			test1(2, 3);
		}
		System.out.println("!!!!!!!!!!!!!!!!!!!!");
		for(int i = 0; i < 10; ++i){
			test1(2, 4);
		}		
	}

测试结果如下:

1 test1(2,3) 2.0s 2.0s test1(2,4) 1.8s 2.0s
2 test1(2,4) 1.3s 1.3s test1(2,3) 1.3s 1.8s
3            
4 test2(2,3) 1.3s 1.7s test2(2,4) 1.3s 1.9s
5 test2(2,4) 1.3s 1.3s test2(2,3) 1.3s 1.8s


先来分析第1行数据,test1(2,3)的结果是最坏的,显然这是因为两个线程执行同一份代码,且两者的分支预测结果互相干扰,导致总是不准。

但是为什么后面的test1(2,4)的结果也是比较差?尽管两个线程执行的是同一份代码,但是两个线程中if的判断都总是true,为什么会出现耗时比较多的情况?

简单推测1:可能是之前的test1(2,3)影响了test1(2,4)的分支预测的结果,分支预测器中有历史表,前面执行的分支预测历史会影响后面的选择。

再来分析第2行,显然test1(2,4)是最好的结果,两个线程执行同一份代码,且if总是为true。再看第2行的test(2,3)结果,比第1行的要好,为什么这个和第1行的数据差这么多?

简单推测2:应该是不同的核有自己的分支预测器。

再来看test2函数的测试结果,从第4行来看,test2(2,3)的结果符合预期,但是显然test2(2,4)的结果不理想,为什么两个线程执行不同地方的代码,if判断总是true,结果会不同?

简单推测3:受test(2,3)的结果的影响,结合简单推测1和2,就可以理解为什么test(2,4)的前一个结果是1.3s,后一个是1.9s了。

再来分析第5行数据,这行数据完全符合预期。


总结:

推测:i5的分支预测器是一个混合的分支预测器。每个核都有历史表,每一个核都有自己的分支预测器。

多线程下的分支预测并不是很乐观,如果可以避开多个线程执行同一份代码,且分支预测条件的结果总是变化,则尽量避开。

相关文章
|
5月前
|
缓存 测试技术 数据中心
【计算机架构】计算 CPU 动态功耗 | 集成电路成本 | SPEC 基准测试 | Amdahl 定律 | MIPS 性能指标
【计算机架构】计算 CPU 动态功耗 | 集成电路成本 | SPEC 基准测试 | Amdahl 定律 | MIPS 性能指标
249 0
|
6月前
|
SQL Java 数据库连接
联表查询 && 索引 && 事务 && JDBC使用 &&CPU工作原理 && 线程概念 && Thread类的用法
联表查询 && 索引 && 事务 && JDBC使用 &&CPU工作原理 && 线程概念 && Thread类的用法
135 0
|
2月前
|
监控 测试技术 Shell
APP的CPU,内存和流量如何测试?
APP的CPU,内存和流量如何测试?
|
3月前
|
存储 JSON 运维
【运维】Powershell 服务器系统管理信息总结(进程、线程、磁盘、内存、网络、CPU、持续运行时间、系统账户、日志事件)
【运维】Powershell 服务器系统管理信息总结(进程、线程、磁盘、内存、网络、CPU、持续运行时间、系统账户、日志事件)
49 0
|
3月前
|
NoSQL
【线程绑定cpu核心】
【线程绑定cpu核心】
|
4月前
|
分布式计算 并行计算 Hadoop
【云计算与大数据计算】分布式处理CPU多核、MPI并行计算、Hadoop、Spark的简介(超详细)
【云计算与大数据计算】分布式处理CPU多核、MPI并行计算、Hadoop、Spark的简介(超详细)
96 0
|
4月前
|
安全 Java
ConcurrentHashMap扩容的详细介绍以及多线程测试(基于JDK1.8)
ConcurrentHashMap扩容的详细介绍以及多线程测试(基于JDK1.8) ConcurrentHashMap是Java中线程安全的哈希表实现。它使用了锁分段技术,将哈希表分成多个Segment(默认为16),每个Segment都是一个独立的哈希表,每个Segment内部维护一个ReentrantLock锁,对于不同的Segment,它们可以被并发访问。当进行put、get等操作时,只需要获取对应Segment的锁即可,大大提高了并发访问的效率。
|
5月前
|
缓存 安全 Java
从CPU的视角看 多线程代码为什么那么难写!
当我们提到多线程、并发的时候,我们就会回想起各种诡异的bug,比如各种线程安全问题甚至是应用崩溃,而且这些诡异的bug还很难复现。我们不禁发出了灵魂拷问 “为什么代码测试环境运行好好的,一上线就不行了?”。 为了解决线程安全的问题,我们的先辈们在编程语言中引入了各种各样新名词,就拿我们熟悉的Java为例,不仅java语言自带了synchronized、volatile、wait、notify… ,jdk中各种工具包也是层出不穷,就比如单一个Lock,就可以有很多种实现,甚至很多人都谈锁色变。
45 0
|
5月前
|
Java 测试技术 BI
一文告诉你CPU分支预测对性能影响有多大
CPU分支预测本身是为了提升流水线下避免流水线等待的手段,其实本质上是利用了局部性原理,因为局部性的存在,大多数情况下这个技术本身给性能带来的是正向的(要不然它今天也不会存在了),所以我们大多数情况下都不需要关注它的存在,还是放心大胆的写代码吧,不要因为我们这篇博客就把所有的if改成?:三目运算,可能对代码可读性的影响远大于性能提升的收益。再次强调下,我今天只是构造了一个极端的数据来验证其性能差异,因为局部性的存在大多数情况下分支预测都是对的。
55 0
|
7月前
|
缓存 Java 大数据
深入解析JVM调优:解决OutOfMemoryError、内存泄露、线程死锁、锁争用和高CPU消耗问题
深入解析JVM调优:解决OutOfMemoryError、内存泄露、线程死锁、锁争用和高CPU消耗问题
90 0