有人说笔记本i7多线程意义不大，真相了？【显卡吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：2,474,457贴子：
有人说笔记本i7多线程意义不大，真相了？收藏
隐形车衣PPF车漆透明膜什么价格？上海隐形车衣贴膜哪里好?
笔记本上i3，i5，i7差距大么？
超低电压的除外
那得看你干什么了如果只是一般的家用那确实意义不大，还不如换个SSD来的实在但如果玩多开 渲染之类i7优势太大了
谁有事没事拿笔记本来算科研压视频啊工作站除外等过几年架构落后了 睿频超线程多出来的TDP就是个散热负累
存在即是有价值的 产品有自身的定位——来自 诺基亚 Lumia 920
笔记本i5开个网页工人物就被爆了
i7 2635qm+640m玩个gta4 cpu可达99摄氏度。撸主选i5得了吧 i7 温度太大
顺便问下，i7工作温度100摄氏度指的是最高100度还是100℃是正常温度？
办公用和i3区别真不大，好吧，我没用过i7本，也没用本玩过游戏。
之前出风口被灰堵住的时候i7 2612qm 103度竟然没死机，真是霸气
显卡,正品行货低价促销!货到付款,全国联保,满99元免运费!全场超低价格,货到付款,配送极速,京东给您不一样的购物新体验!
如果拿来玩游戏 超线程用处确实不大
玩游戏也需要四核的好不好有钱尽量i7四核
i3i5差距不大i5i7差距不小
预算够就上I7 一分钱一分货
差距很大好不好 I3跟I5差距不大 都是双核心四线程但是I7是四核心八线程 相当于台式机I7跟I3的差距 你说大不大
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或2231人阅读
多进程/线程编程（35）
&&&&&&&多线程好处多多，都列举出来就没有意思了，下面仅从一个方面来闲扯一下：
&&&&&& 如果你熟悉VC++6.0或者BCB6.0, 你可以做这样一个实验：在按钮对应的方法中，让程序睡眠10秒钟，在这10秒钟之内，你无法移动窗体，也无法改变窗体大小，因为你用的是单线程呗。
&&&&&& 书上，网上有不少地方在说多线程好，多线程有效率，有时候，你会发现一头雾水，下面，我来模拟用户界面线程和后台线程，旨在说明多线程为什么高效，程序如下:
#include &stdio.h&
#include &time.h&
#include &windows.h&
// 模拟用户界面操作的耗时
void UserInput()
Sleep(5000);
// 后台线程入口
DWORD WINAPI Fun(LPVOID lpParameter)
int sum = 0;
for(i = 0; i & 30000; i++)
for(j = 0; j & 30000; j++)
sum++;
printf(&sum is %d\n&, sum);
// 界面线程(主线程)入口
int main()
HANDLE h = CreateThread(NULL, 0, Fun, NULL, 0, NULL);
int t1, t2;
t1 = clock();
UserInput();
t2 = clock();
printf(&total time is %d\n&, t2 - t1);
&&&& 结果为：
total time is 5000
&&&&& 可见，用户操作后（用户操作时间为5s），立即可以看到结果，不用等。我们再来看看单线程下的情况：
#include &stdio.h&
#include &time.h&
#include &windows.h&
void UserInput()
Sleep(5000);
void fun()
int sum = 0;
for(i = 0; i & 30000; i++)
for(j = 0; j & 30000; j++)
sum++;
printf(&sum is %d\n&, sum);
int main()
int t1, t2;
t1 = clock();
UserInput();
t2 = clock();
printf(&total time is %d\n&, t2 - t1);
&&&&&& 结果为：
total time is 8437
&&&&&& 可见，单线程确实费时间。因为单线程让CPU有了更多的闲暇时间，效率自然就低了。
&&&&&& 最后，我用一个非常通俗的例子结束本文：
&&&&&& 假设一套数学练习试卷有10个题目，题目有难有易，如果第一个题目比较难，你傻傻地在那个地方死死地纠结，你很可能会卡住，此时老师又不在你身边，所以固执的你，一个题目也没有做出来，老师来了，发现你一个题目也没有做，你的效率自然就很低。这就是单线程模式，傻傻地直接往下做。如果采取多线程模式就好了，不会做，先跳过，先做容易的，等老师回来后，你再做难的，最根本的是要你处于忙碌状态，而不是死死地纠结在第一个问题上，那样，其实你没有在忙碌，你在浪费时间，效率自然就低。
&&&&&& 人生又何尝没有夹杂着单线程模式和多线程模式？
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2893716次
积分：40584
积分：40584
排名：第81名
原创：1585篇
转载：130篇
评论：1669条
(12)(32)(52)(8)(10)(28)(56)(32)(26)(15)(42)(63)(38)(39)(75)(43)(4)(20)(33)(17)(11)(7)(48)(53)(51)(52)(35)(20)(53)(41)(35)(13)(32)(36)(7)(1)(47)(23)(26)(4)(13)(4)(19)(72)(13)(2)(14)(45)(32)(7)(3)(28)(53)(106)(68)4851人阅读
Java技术（12）
我们可以在计算机上运行各种计算机软件程序。每一个运行的程序可能包括多个独立运行的线程（Thread）。
线程（Thread）是一份独立运行的程序，有自己专用的运行栈。线程有可能和其他线程共享一些资源，比如，内存，文件，数据库等。
当多个线程同时读写同一份共享资源的时候，可能会引起冲突。这时候，我们需要引入线程“同步”机制，即各位线程之间要有个先来后到，不能一窝蜂挤上去抢作一团。
同步这个词是从英文synchronize（使同时发生）翻译过来的。我也不明白为什么要用这个很容易引起误解的词。既然大家都这么用，咱们也就只好这么将就。
线程同步的真实意思和字面意思恰好相反。线程同步的真实意思，其实是“排队”：几个线程之间要排队，一个一个对共享资源进行操作，而不是同时进行操作。
因此，关于线程同步，需要牢牢记住的第一点是：线程同步就是线程排队。同步就是排队。线程同步的目的就是避免线程“同步”执行。这可真是个无聊的绕口令。
关于线程同步，需要牢牢记住的第二点是 “共享”这两个字。只有共享资源的读写访问才需要同步。如果不是共享资源，那么就根本没有同步的必要。
关于线程同步，需要牢牢记住的第三点是，只有“变量”才需要同步访问。如果共享的资源是固定不变的，那么就相当于“常量”，线程同时读取常量也不需要同步。至少一个线程修改共享资源，这样的情况下，线程之间就需要同步。
关于线程同步，需要牢牢记住的第四点是：多个线程访问共享资源的代码有可能是同一份代码，也有可能是不同的代码；无论是否执行同一份代码，只要这些线程的代码访问同一份可变的共享资源，这些线程之间就需要同步。
为了加深理解，下面举几个例子。
有两个采购员，他们的工作内容是相同的，都是遵循如下的步骤：
（1）到市场上去，寻找并购买有潜力的样品。
（2）回到公司，写报告。
这两个人的工作内容虽然一样，他们都需要购买样品，他们可能买到同样种类的样品，但是他们绝对不会购买到同一件样品，他们之间没有任何共享资源。所以，他们可以各自进行自己的工作，互不干扰。
这两个采购员就相当于两个线程；两个采购员遵循相同的工作步骤，相当于这两个线程执行同一段代码。
下面给这两个采购员增加一个工作步骤。采购员需要根据公司的“布告栏”上面公布的信息，安排自己的工作计划。
这两个采购员有可能同时走到布告栏的前面，同时观看布告栏上的信息。这一点问题都没有。因为布告栏是只读的，这两个采购员谁都不会去修改布告栏上写的信息。
下面增加一个角色。一个办公室行政人员这个时候，也走到了布告栏前面，准备修改布告栏上的信息。
如果行政人员先到达布告栏，并且正在修改布告栏的内容。两个采购员这个时候，恰好也到了。这两个采购员就必须等待行政人员完成修改之后，才能观看修改后的信息。
如果行政人员到达的时候，两个采购员已经在观看布告栏了。那么行政人员需要等待两个采购员把当前信息记录下来之后，才能够写上新的信息。
上述这两种情况，行政人员和采购员对布告栏的访问就需要进行同步。因为其中一个线程（行政人员）修改了共享资源（布告栏）。而且我们可以看到，行政人员的工作流程和采购员的工作流程（执行代码）完全不同，但是由于他们访问了同一份可变共享资源（布告栏），所以他们之间需要同步。
前面讲了为什么要线程同步，下面我们就来看如何才能线程同步。
线程同步的基本实现思路还是比较容易理解的。我们可以给共享资源加一把锁，这把锁只有一把钥匙。哪个线程获取了这把钥匙，才有权利访问该共享资源。
生活中，我们也可能会遇到这样的例子。一些超市的外面提供了一些自动储物箱。每个储物箱都有一把锁，一把钥匙。人们可以使用那些带有钥匙的储物箱，把东西放到储物箱里面，把储物箱锁上，然后把钥匙拿走。这样，该储物箱就被锁住了，其他人不能再访问这个储物箱。（当然，真实的储物箱钥匙是可以被人拿走复制的，所以不要把贵重物品放在超市的储物箱里面。于是很多超市都采用了电子密码锁。）
线程同步锁这个模型看起来很直观。但是，还有一个严峻的问题没有解决，这个同步锁应该加在哪里？
当然是加在共享资源上了。反应快的读者一定会抢先回答。
没错，如果可能，我们当然尽量把同步锁加在共享资源上。一些比较完善的共享资源，比如，文件系统，数据库系统等，自身都提供了比较完善的同步锁机制。我们不用另外给这些资源加锁，这些资源自己就有锁。
但是，大部分情况下，我们在代码中访问的共享资源都是比较简单的共享对象。这些对象里面没有地方让我们加锁。
读者可能会提出建议：为什么不在每一个对象内部都增加一个新的区域，专门用来加锁呢？这种设计理论上当然也是可行的。问题在于，线程同步的情况并不是很普遍。如果因为这小概率事件，在所有对象内部都开辟一块锁空间，将会带来极大的空间浪费。得不偿失。
于是，现代的编程语言的设计思路都是把同步锁加在代码段上。确切的说，是把同步锁加在“访问共享资源的代码段”上。这一点一定要记住，同步锁是加在代码段上的。
同步锁加在代码段上，就很好地解决了上述的空间浪费问题。但是却增加了模型的复杂度，也增加了我们的理解难度。
现在我们就来仔细分析“同步锁加在代码段上”的线程同步模型。
首先，我们已经解决了同步锁加在哪里的问题。我们已经确定，同步锁不是加在共享资源上，而是加在访问共享资源的代码段上。
其次，我们要解决的问题是，我们应该在代码段上加什么样的锁。这个问题是重点中的重点。这是我们尤其要注意的问题：访问同一份共享资源的不同代码段，应该加上同一个同步锁；如果加的是不同的同步锁，那么根本就起不到同步的作用，没有任何意义。
这就是说，同步锁本身也一定是多个线程之间的共享对象。
Java语言的synchronized关键字
为了加深理解，举几个代码段同步的例子。
不同语言的同步锁模型都是一样的。只是表达方式有些不同。这里我们以当前最流行的Java语言为例。Java语言里面用synchronized关键字给代码段加锁。整个语法形式表现为
synchronized(同步锁) {
// 访问共享资源，需要同步的代码段
这里尤其要注意的就是，同步锁本身一定要是共享的对象。
Object lock1 = new Object(); // 产生一个同步锁
synchronized(lock1){
// 代码段 A
// 访问共享资源 resource1
// 需要同步
上面这段代码没有任何意义。因为那个同步锁是在函数体内部产生的。每个线程调用这段代码的时候，都会产生一个新的同步锁。那么多个线程之间，使用的是不同的同步锁。根本达不到同步的目的。
同步代码一定要写成如下的形式，才有意义。
public static final Object lock1 = new Object();
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 A
// 访问共享资源 resource1
// 需要同步
你不一定要把同步锁声明为static或者public，但是你一定要保证相关的同步代码之间，一定要使用同一个同步锁。
讲到这里，你一定会好奇，这个同步锁到底是个什么东西。为什么随便声明一个Object对象，就可以作为同步锁？
在Java里面，同步锁的概念就是这样的。任何一个Object Reference都可以作为同步锁。我们可以把Object Reference理解为对象在内存分配系统中的内存地址。因此，要保证同步代码段之间使用的是同一个同步锁，我们就要保证这些同步代码段的synchronized关键字使用的是同一个Object Reference，同一个内存地址。这也是为什么我在前面的代码中声明lock1的时候，使用了final关键字，这就是为了保证lock1的Object Reference在整个系统运行过程中都保持不变。
一些求知欲强的读者可能想要继续深入了解synchronzied(同步锁)的实际运行机制。Java虚拟机规范中（你可以在google用“JVM Spec”等关键字进行搜索），有对synchronized关键字的详细解释。synchronized会编译成 monitor enter, … monitor exit之类的指令对。Monitor就是实际上的同步锁。每一个Object Reference在概念上都对应一个monitor。
这些实现细节问题，并不是理解同步锁模型的关键。我们继续看几个例子，加深对同步锁模型的理解。
public static final Object lock1 = new Object();
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 A
// 访问共享资源 resource1
// 需要同步
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 B
// 访问共享资源 resource1
// 需要同步
上述的代码中，代码段A和代码段B就是同步的。因为它们使用的是同一个同步锁lock1。
如果有10个线程同时执行代码段A，同时还有20个线程同时执行代码段B，那么这30个线程之间都是要进行同步的。
这30个线程都要竞争一个同步锁lock1。同一时刻，只有一个线程能够获得lock1的所有权，只有一个线程可以执行代码段A或者代码段B。其他竞争失败的线程只能暂停运行，进入到该同步锁的就绪（Ready）队列。
每一个同步锁下面都挂了几个线程队列，包括就绪（Ready）队列，待召（Waiting）队列等。比如，lock1对应的就绪队列就可以叫做lock1 - ready queue。每个队列里面都可能有多个暂停运行的线程。
注意，竞争同步锁失败的线程进入的是该同步锁的就绪（Ready）队列，而不是后面要讲述的待召队列（Waiting Queue，也可以翻译为等待队列）。就绪队列里面的线程总是时刻准备着竞争同步锁，时刻准备着运行。而待召队列里面的线程则只能一直等待，直到等到某个信号的通知之后，才能够转移到就绪队列中，准备运行。
成功获取同步锁的线程，执行完同步代码段之后，会释放同步锁。该同步锁的就绪队列中的其他线程就继续下一轮同步锁的竞争。成功者就可以继续运行，失败者还是要乖乖地待在就绪队列中。
因此，线程同步是非常耗费资源的一种操作。我们要尽量控制线程同步的代码段范围。同步的代码段范围越小越好。我们用一个名词“同步粒度”来表示同步代码段的范围。
在Java语言里面，我们可以直接把synchronized关键字直接加在函数的定义上。
… synchronized … f1() {
// f1 代码段
这段代码就等价于
synchronized(this){ // 同步锁就是对象本身
// f1 代码段
同样的原则适用于静态（static）函数
… static synchronized … f1() {
// f1 代码段
这段代码就等价于
…static … f1() {
synchronized(Class.forName(…)){ // 同步锁是类定义本身
// f1 代码段
但是，我们要尽量避免这种直接把synchronized加在函数定义上的偷懒做法。因为我们要控制同步粒度。同步的代码段越小越好。synchronized控制的范围越小越好。
我们不仅要在缩小同步代码段的长度上下功夫，我们同时还要注意细分同步锁。
比如，下面的代码
public static final Object lock1 = new Object();
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 A
// 访问共享资源 resource1
// 需要同步
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 B
// 访问共享资源 resource1
// 需要同步
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 C
// 访问共享资源 resource2
// 需要同步
synchronized(lock1){ // lock1 是公用同步锁
// 代码段 D
// 访问共享资源 resource2
// 需要同步
上述的4段同步代码，使用同一个同步锁lock1。所有调用4段代码中任何一段代码的线程，都需要竞争同一个同步锁lock1。
我们仔细分析一下，发现这是没有必要的。
因为f1()的代码段A和f2()的代码段B访问的共享资源是resource1，f3()的代码段C和f4()的代码段D访问的共享资源是resource2，它们没有必要都竞争同一个同步锁lock1。我们可以增加一个同步锁lock2。f3()和f4()的代码可以修改为：
public static final Object lock2 = new Object();
synchronized(lock2){ // lock2 是公用同步锁
// 代码段 C
// 访问共享资源 resource2
// 需要同步
synchronized(lock2){ // lock2 是公用同步锁
// 代码段 D
// 访问共享资源 resource2
// 需要同步
这样，f1()和f2()就会竞争lock1，而f3()和f4()就会竞争lock2。这样，分开来分别竞争两个锁，就可以大大较少同步锁竞争的概率，从而减少系统的开销。
同步锁模型只是最简单的同步模型。同一时刻，只有一个线程能够运行同步代码。
有的时候，我们希望处理更加复杂的同步模型，比如生产者/消费者模型、读写同步模型等。这种情况下，同步锁模型就不够用了。我们需要一个新的模型。这就是我们要讲述的信号量模型。
信号量模型的工作方式如下：线程在运行的过程中，可以主动停下来，等待某个信号量的通知；这时候，该线程就进入到该信号量的待召（Waiting）队列当中；等到通知之后，再继续运行。
很多语言里面，同步锁都由专门的对象表示，对象名通常叫Monitor。
同样，在很多语言中，信号量通常也有专门的对象名来表示，比如，Mutex，Semphore。
信号量模型要比同步锁模型复杂许多。一些系统中，信号量甚至可以跨进程进行同步。另外一些信号量甚至还有计数功能，能够控制同时运行的线程数。
我们没有必要考虑那么复杂的模型。所有那些复杂的模型，都是最基本的模型衍生出来的。只要掌握了最基本的信号量模型——“等待/通知”模型，复杂模型也就迎刃而解了。
我们还是以Java语言为例。Java语言里面的同步锁和信号量概念都非常模糊，没有专门的对象名词来表示同步锁和信号量，只有两个同步锁相关的关键字——volatile和synchronized。
这种模糊虽然导致概念不清，但同时也避免了Monitor、Mutex、Semphore等名词带来的种种误解。我们不必执着于名词之争，可以专注于理解实际的运行原理。
在Java语言里面，任何一个Object Reference都可以作为同步锁。同样的道理，任何一个Object Reference也可以作为信号量。
Object对象的wait()方法就是等待通知，Object对象的notify()方法就是发出通知。
具体调用方法为
（1）等待某个信号量的通知
public static final Object signal = new Object();
synchronized(singal) { // 首先我们要获取这个信号量。这个信号量同时也是一个同步锁
// 只有成功获取了signal这个信号量兼同步锁之后，我们才可能进入这段代码
signal.wait(); // 这里要放弃信号量。本线程要进入signal信号量的待召（Waiting）队列
// 可怜。辛辛苦苦争取到手的信号量，就这么被放弃了
// 等到通知之后，从待召（Waiting）队列转到就绪（Ready）队列里面
// 转到了就绪队列中，离CPU核心近了一步，就有机会继续执行下面的代码了。
// 仍然需要把signal同步锁竞争到手，才能够真正继续执行下面的代码。命苦啊。
需要注意的是，上述代码中的signal.wait()的意思。signal.wait()很容易导致误解。signal.wait()的意思并不是说，signal开始wait，而是说，运行这段代码的当前线程开始wait这个signal对象，即进入signal对象的待召（Waiting）队列。
（2）发出某个信号量的通知
synchronized(singal) { // 首先，我们同样要获取这个信号量。同时也是一个同步锁。
// 只有成功获取了signal这个信号量兼同步锁之后，我们才可能进入这段代码
signal.notify(); // 这里，我们通知signal的待召队列中的某个线程。
// 如果某个线程等到了这个通知，那个线程就会转到就绪队列中
// 但是本线程仍然继续拥有signal这个同步锁，本线程仍然继续执行
// 嘿嘿，虽然本线程好心通知其他线程，
// 但是，本线程可没有那么高风亮节，放弃到手的同步锁
// 本线程继续执行下面的代码
需要注意的是，signal.notify()的意思。signal.notify()并不是通知signal这个对象本身。而是通知正在等待signal信号量的其他线程。
以上就是Object的wait()和notify()的基本用法。
实际上，wait()还可以定义等待时间，当线程在某信号量的待召队列中，等到足够长的时间，就会等无可等，无需再等，自己就从待召队列转移到就绪队列中了。
另外，还有一个notifyAll()方法，表示通知待召队列里面的所有线程。
这些细节问题，并不对大局产生影响。
绿色线程（Green Thread）是一个相对于操作系统线程（Native Thread）的概念。
操作系统线程（Native Thread）的意思就是，程序里面的线程会真正映射到操作系统的线程，线程的运行和调度都是由操作系统控制的
绿色线程（Green Thread）的意思是，程序里面的线程不会真正映射到操作系统的线程，而是由语言运行平台自身来调度。
当前版本的Python语言的线程就可以映射到操作系统线程。当前版本的Ruby语言的线程就属于绿色线程，无法映射到操作系统的线程，因此Ruby语言的线程的运行速度比较慢。
难道说，绿色线程要比操作系统线程要慢吗？当然不是这样。事实上，情况可能正好相反。Ruby是一个特殊的例子。线程调度器并不是很成熟。
目前，线程的流行实现模型就是绿色线程。比如，stackless Python，就引入了更加轻量的绿色线程概念。在线程并发编程方面，无论是运行速度还是并发负载上，都优于Python。
另一个更著名的例子就是ErLang（爱立信公司开发的一种开源语言）。
ErLang的绿色线程概念非常彻底。ErLang的线程不叫Thread，而是叫做Process。这很容易和进程混淆起来。这里要注意区分一下。
ErLang Process之间根本就不需要同步。因为ErLang语言的所有变量都是final的，不允许变量的值发生任何变化。因此根本就不需要同步。
final变量的另一个好处就是，对象之间不可能出现交叉引用，不可能构成一种环状的关联，对象之间的关联都是单向的，树状的。因此，内存垃圾回收的算法效率也非常高。这就让ErLang能够达到Soft Real Time（软实时）的效果。这对于一门支持内存垃圾回收的语言来说，可不是一件容易的事情。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：173971次
排名：千里之外
原创：23篇
转载：16篇
评论：19条
(1)(4)(6)(4)(6)(9)(9)转一篇关于多线程的作用的帖子_图拉丁吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：1,251,201贴子：
转一篇关于多线程的作用的帖子收藏
神牛摄影器材--为专业摄影者打造,你值得拥有!
以下情况下,HT是完全没起作用:多开很多应用程序(如WOW/word/Chrome/Mozilla Firefox/etc.);任何不支持2线程以上的游戏;以下情况下HT会发挥作用,但是仍然不会影响性能(性能影响基本可以忽略)任何支持超过2线程的游戏;以下情况下HT会发挥显著作用(HT的真正用法):同步冗余校验计算(就是两个线程算同样的东西,然后比较结果来确定计算没有出错);任何能把CPU彻底灌满100%的程序,比如Pr/AE/VMware/gcc/etc.;
下面是解释,可能会有错误,欢迎批评指导.主要理论依据为和wiki的文献;什么是HT?HT是intel对自家处理器SMT技术的称呼;什么是SMT?SMT叫做"同步多线程",是指单个处理器可以同时处理多个线程(Thread)的技术,这项技术依赖的底层是Superscaler(超纯量/超标量(是"标量",不是"超标"));什么是Superscaler(超标量) CPU?简单地说,就是一个CPU核心内有多个更小的处理单元,比如3-4个整数ALU,1-2个FPU等等,如果这些单元可以同步工作,同时处理无关的指令(也就是CPU同时能够处理多个指令),那么这个处理器就叫超标量处理器;反之,如果没有Superscaler的支持,一个CPU核心将会只有一个ALU和FPU--你放多了也没用,反正一次只能处理一条指令,一条指令是很难填满多个ALU和FPU的.SMT做了什么?SMT在Superscaler上的修改很小,Superscaler依赖编译器和CPU本身来判断指令的无关性,比如B=A+1;然后C=B+2;显然这是有顺序要求的,先算C=B+2结果就错了,所以这两条指令不能同时计算,这时候Superscaler的局限性就凸显了--Superscaler是全自动的,没有手动挡,我(程序员)想人工标记某两条语句没有关系,就没有办法了.这时候SMT就诞生了,SMT让CPU对外宣称能同时处理两个线程,程序员只要把无关的指令分别放到两个线程里去,就能手动控制优化Superscaler的性能.但是要注意SMT对于CPU实际处理指令是没有影响的,两个线程进了CPU之后,还是利用superscaler来同步处理.通常,SMT的两个线程是没有优先级的,是完全平等的,没有那个线程是物理的,另一个是虚拟的这种说法.
我看晕了,有没有形象的解释?我们把CPU看成一个小工厂,工厂里有拧螺丝的,电焊的,拼插元件的等等员工,这个工厂靠一个小窗口收集订单,有一个订单队列(但是外面看不见),有人按照订单要求分配工作,员工能同时为不同的订单工作,这就叫Superscaler,突然有一天,来了一个订单,要组装一个天线,然后又来了一个订单,要组装一台用那个天线的收音机,这时候这个工厂就有很多员工空闲了.这时候工厂升级了一下,里面都不变,但是窗口改成了两个,只要提供订单的人稍微花点时间细分一下订单,把组装收音机中的电路板这个订单单独送到新窗口里去,里面的员工就知道,这个可以和天线同时生产了--这就是SMT现在应该都能理解SMT的作用了,说明白就是让CPU全速运转,不浪费性能,下面是SMT带来的问题:还是刚才那个工厂,生产天线和电路板都需要电焊,但是只有一个电焊工,这时候由于资源的原因,势必有一个订单要拖慢一点,等一下别人占用的资源,但是整体效率提高了.对于游戏来说,这种等是不能接受的--等待就是卡顿!如果关键线程(比如WOW负载最重的主线程)被其他次要线程阻塞了,那就会造成性能的下降.但是从全局看,这种卡顿是性能提高的表现....游戏玩家估计不能理解"卡"居然等于性能提高这个情况....所以解释在这里:SMT用时间换取空间,让每个线程都稍微慢一点,但是提高效率,总吞吐量上升.这在需要很长时间连续计算的(比如视频转码/渲染这种一跑好几个小时的长期非实时计算)应用看来是没有负面影响的,他们不在乎每个指令是不是执行得快,而是希望天文数字级别的一大堆指令执行得快,可以早日完工.现在我想大家应该已经很明白了,为什么游戏在HT上有时候性能会下降...而且,由于HT是提高CPU占用率的技术,如果这个CPU核心没达到100%的占用,HT是不会有任何效果的.对于4c8T来说,任何游戏都不可能让他4个核心8线程同时100%满载,就算CPU是瓶颈且游戏支持8线程,也是卡在某一个核心100%,其他的60%-80%左右的情况下,这时候只有一个核心的HT是发挥效力的(就是那个100%负载的核心,而且还不知道是正效果还是反效果,囧),剩下的3个核心的HT完全是摆设,没有起实际作用再看一下为什么Cinebench渲染可以用好HT,4c8T跑Cinebench的时候4个CPU的8线程统统100%,这时候4个核心的HT都在优化superscaler并行,所以可以获得显著的性能提高(最高可达20%).而且由于Cinebench不在乎每个线程的工作速度,只看重整体速度,所以HT有可能降低单线程性能这件事在这里完全忽略了.PS:额外结论:HT效率被利用的越高,单线程性能就越容易降低.所以深度优化HT=完全抛弃单线程计算,只要一个程序还存在重载的主线程,他就不可能是HT优化的程序,为HT优化的程序的样子应该是这样的:一个线程负责任务分配,动态的负载均衡,剩下的线程一视同仁,被灌入各种任务.显然,这种模型和现代游戏开发完全就不在一条路上.....所以游戏优化HT属于坑爹行为,不可能真的去优化HT的.
虽然看不太懂，但是感觉LZ好厉害啊
看懂了-。-但是我是追求单核性能的基佬-。-所以我一般都关掉超线程
部分转码软件也能100%占满
简单地说，如果你CPU不是跑到100%占用，HT技术没什么用处。而用到100%占用，就是那些CAD/EDA设计软件，代码编译器，3D渲染
在CPU没跑到100%的时候，任何有理由HT的应用，都可以不必须开HT，CPU有冗余时间片去处理，CPU没有load到100%之前，HT多开会降低总线占用时间，降低吞吐量。在CPU load到100%的时候，总线带宽已经完全占用，这个时候 pipe line没有时间去reload更多，但pipe line，有可能是hold在最后一个work position。于是可以把pipe line重新组织，分配成两条，前半条释放出来做reload。但这种做法不会增加吞吐量，由于reload的L1是指令cache，对于非线性控制代码应用来说，可能miss加大。对于线性解码，渲染，编译来说，指令重复性高，L1指令cache不必重新刷新就可以load进HT新开出来的半个pipe line
亚马逊AWS-云创计划.最高可达10万元免费云资源!
我来说下吧，昨天我测试的，没有i7或者超线程u的人是没资格发言的。。就拿跑分来说，i5跟i7跑个象棋就有很大的差异，我的2600k大约27左右，i5在22上下，都是默认，而i5视型号而定。。而这点差异就是因为超线程所引起的，而我想说的是，由超线程所引起的这点差异是会起作用的。。昨天我关掉超线程开虚拟机，开csol，只能开3个虚拟机和一个游戏本体，u就满载了，之后就卡掉线2个号。。一共4个号，而且还不稳定。。而平时，我开5个虚拟机和一个游戏本体，u只占用90%。。一共开到6个号，非常稳定虽然有点枪，但是这是我真实体验，而且以后我买u都只会买有超线程的，贵点是有道理的，intel卖贵点是有道理的，下面放图
还是觉得I5好
HT与真正的应用是矛盾的。而且，HT技术只有在高频，高管线级数的架构中体现出来。为了能够让HT技术达到性能上的可观指标，通常都会用到高倍频的某些型号，而管线中也故意加大延迟，加长管线级数。你想一个13级管线的CPU，能分配出多少剩余工位？一个管线级就代表一个工位。而故意加长管线，原来一个工位用两个工位，这样就能把一条管线在适当的时候劈开变成两条管线。这就是HT技术
多线程能防卡死。是这个意思吧？？？？？
4个虚拟机+游戏本体，因为活动，我只需要开4个号就行了。。平时我都不玩游戏的
4G同频 有超线程和无超线程 30%真是太多了
所以我觉得 BIOS应该有一个人性化的动态开启HT的设置。根据 CPU占用比去判断是否开启HT。如果CPU占用90%以上，就开HT这样性能最佳化。在轻载情况下，开HT会损失实时性
偶二奶用的i3 3220表示开ht玩游戏很给力，文章只是理论
这就可以解释为什么我用G620和用I3觉得差别不大。因为我很少让CPU100%，按楼主的说法，I3两线程闲置等于只是频率和缓存的差距。那我把P4 2.4换成3.06b感觉提升很大。这是因为P4在这个时代很容易100%，这是超线程发挥作用吗？
可以手动分配核心，这时候多线程有意义了
网吧i3玩星际帧数暴跌至个位数。任务管理器cpu占用不到30。四个框框不如家里的两点框框。亲身体验！
超线程技术广泛应用于LinX，象棋，superPI领域，而且拥有卓越的成效（好吧我继续自重。。。）不过比起AMD的缩线程技术，这个还是挺实用的。。毕竟AMD的8核关都关不掉
回19楼的图
楼上的2个图跟19楼的图足以说明理论终究是理论,跟实际情况差别很大,4开i5满载,7开e3满载,你可能会说还有主频上的差距,为了试验e3的多开极限,我又开了2个eve,就是第二张图,居然占有率下降了很多,太令人费解了.另外补张装备图吧大师终究不专业,把我的主副硬盘都能认错,任何理论一旦到实际用上了,很可能因为实际情况的原因而有非常大的出入,按照我跟19楼的图示,实际效果翻了至少一倍了
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或}