多线程实际没有少线程的速度快

笨来无一悟

问答区遇到一个迷信多线程的小伙伴 不使用线程池的情况 更合理的做法是启动4到16个线程 然后线程里面用变量循环跑循环 速度比多线程快得多得多得多多线程多了一堆线程嗷嗷待哺 造成拥堵了

  

窗口程序集名	保 留	保 留	备 注
窗口程序集_启动窗口
变量名	类 型	数组	备 注
是否完毕	逻辑型	0

子程序名	返回值类型	公开	备 注
__启动窗口_创建完毕

子程序名	返回值类型	公开	备 注
_按钮1_被单击

变量名	类 型	静态	数组	备 注
T	整数型
计次	整数型

调试输出 (“开始1”)
T ＝ 取启动时间 ()
重定义数组 (是否完毕, 假, 10000)  ' 100*100=10000
计次循环首 (取数组成员数 (是否完毕), 计次)
启动线程 (&线程1, 计次, )
计次循环尾 ()
循环判断首 ()
处理事件 ()  ' 避免卡界面
延迟 (1)  ' 检测间隔时长根据任务强度灵活修改
循环判断尾 (执行完毕 (是否完毕) ＝ 假)
调试输出 (取启动时间 () － T, “多线程”)

子程序名	返回值类型	公开	备 注
_按钮2_被单击

变量名	类 型	静态	数组	备 注
T	整数型
计次	整数型

调试输出 (“开始2”)
T ＝ 取启动时间 ()
重定义数组 (是否完毕, 假, 100)  ' 100*100=10000
计次循环首 (取数组成员数 (是否完毕), 计次)
启动线程 (&线程2, 计次, )
计次循环尾 ()
循环判断首 ()
处理事件 ()  ' 避免卡界面
延迟 (1)  ' 检测间隔时长根据任务强度灵活修改
循环判断尾 (执行完毕 (是否完毕) ＝ 假)
调试输出 (取启动时间 () － T, “少线程”)

子程序名	返回值类型	公开	备 注
执行完毕	逻辑型		全真 返回真
参数名	类 型	参考	可空	数组	备 注
任务状态	逻辑型				真 假

置入代码 ({ 54, 139, 117, 8, 62, 139, 54, 131, 198, 4, 62, 139, 14, 133, 201, 116, 13, 62, 139, 4, 142, 133, 192, 116, 5, 73, 227, 2, 235, 243, 201, 194, 4, 0 })
返回 (假)  ' 全真 返回真 否则 返回假
' MOV ESI, DWORD PTR SS:[EBP+8]
' MOV ESI, DWORD PTR DS:[ESI]
' ADD ESI, 4
' MOV ECX, DWORD PTR DS:[ESI]
' TEST ECX, ECX
' JE END
' XH:
' MOV EAX, DWORD PTR DS:[ESI+ECX*4]
' TEST EAX, EAX
' JE END
' DEC ECX
' JECXZ END
' JMP XH
' END:
' LEAVE
' RET 4

子程序名	返回值类型	公开	备 注
线程1
参数名	类 型	参考	可空	数组	备 注
编号	整数型

变量名	类 型	静态	数组	备 注
计次	整数型
结果	双精度小数型

计次循环首 (100, 计次)
结果 ＝ 结果 × 计次
计次循环尾 ()
是否完毕 [编号] ＝ 真

子程序名	返回值类型	公开	备 注
线程2
参数名	类 型	参考	可空	数组	备 注
编号	整数型

变量名	类 型	静态	数组	备 注
计次	整数型
结果	双精度小数型

计次循环首 (100, )  ' 100*100=10000
结果 ＝ 0
计次循环首 (100, 计次)
结果 ＝ 结果 × 计次
计次循环尾 ()
计次循环尾 ()
是否完毕 [编号] ＝ 真

i支持库列表	支持库注释
spec	特殊功能支持库
EThread	多线程支持库

.版本 2<br /> .支持库 spec<br /> .支持库 EThread<br /> <br /> .程序集 窗口程序集_启动窗口<br /> .程序集变量 是否完毕, 逻辑型, , "0"<br /> <br /> .子程序 __启动窗口_创建完毕<br /> <br /> <br /> <br /> .子程序 _按钮1_被单击<br /> .局部变量 T, 整数型<br /> .局部变量 计次, 整数型<br /> <br /> 调试输出 (“开始1”)<br /> T ＝ 取启动时间 ()<br /> 重定义数组 (是否完毕, 假, 10000)  ' 100*100=10000<br /> .计次循环首 (取数组成员数 (是否完毕), 计次)<br />     启动线程 (&线程1, 计次, )<br /> .计次循环尾 ()<br /> .循环判断首 ()<br />     处理事件 ()  ' 避免卡界面<br />     延迟 (1)  ' 检测间隔时长根据任务强度灵活修改<br /> .循环判断尾 (执行完毕 (是否完毕) ＝ 假)<br /> 调试输出 (取启动时间 () － T, “多线程”)<br /> <br /> .子程序 _按钮2_被单击<br /> .局部变量 T, 整数型<br /> .局部变量 计次, 整数型<br /> <br /> 调试输出 (“开始2”)<br /> T ＝ 取启动时间 ()<br /> 重定义数组 (是否完毕, 假, 100)  ' 100*100=10000<br /> .计次循环首 (取数组成员数 (是否完毕), 计次)<br />     启动线程 (&线程2, 计次, )<br /> .计次循环尾 ()<br /> .循环判断首 ()<br />     处理事件 ()  ' 避免卡界面<br />     延迟 (1)  ' 检测间隔时长根据任务强度灵活修改<br /> .循环判断尾 (执行完毕 (是否完毕) ＝ 假)<br /> 调试输出 (取启动时间 () － T, “少线程”)<br /> <br /> .子程序 执行完毕, 逻辑型, , 全真 返回真<br /> .参数 任务状态, 逻辑型, 数组, 真 假<br /> <br /> 置入代码 ({ 54, 139, 117, 8, 62, 139, 54, 131, 198, 4, 62, 139, 14, 133, 201, 116, 13, 62, 139, 4, 142, 133, 192, 116, 5, 73, 227, 2, 235, 243, 201, 194, 4, 0 })<br /> 返回 (假)  ' 全真 返回真 否则 返回假<br /> ' MOV ESI, DWORD PTR SS:[EBP+8]<br /> ' MOV ESI, DWORD PTR DS:[ESI]<br /> ' ADD ESI, 4<br /> ' MOV ECX, DWORD PTR DS:[ESI]<br /> ' TEST ECX, ECX<br /> ' JE END<br /> ' XH:<br /> ' MOV EAX, DWORD PTR DS:[ESI+ECX*4]<br /> ' TEST EAX, EAX<br /> ' JE END<br /> ' DEC ECX<br /> ' JECXZ END<br /> ' JMP XH<br /> ' END:<br /> ' LEAVE<br /> ' RET 4<br /> <br /> .子程序 线程1<br /> .参数 编号, 整数型<br /> .局部变量 计次, 整数型<br /> .局部变量 结果, 双精度小数型<br /> <br /> .计次循环首 (100, 计次)<br />     结果 ＝ 结果 × 计次<br /> .计次循环尾 ()<br /> 是否完毕 [编号] ＝ 真<br /> <br /> .子程序 线程2<br /> .参数 编号, 整数型<br /> .局部变量 计次, 整数型<br /> .局部变量 结果, 双精度小数型<br /> <br /> .计次循环首 (100, )  ' 100*100=10000<br />     结果 ＝ 0<br />     .计次循环首 (100, 计次)<br />         结果 ＝ 结果 × 计次<br />     .计次循环尾 ()<br /> .计次循环尾 ()<br /> 是否完毕 [编号] ＝ 真

as06025

使用效果还是杠杠的  太棒了

xf702

处理事件后面加延迟是绝佳搭配吗？

梦之情

别这么说，会被喷的。我当年就被喷过。

1425113841

额, 这不是正常的吗, 要不然你以为的线程池是什么.
线程池就是一次性启动多个线程, 后需要你要执行什么操作, 你直接用这个线程去调用你需要操作的函数. 解决启动线程步骤带来的开销.
线程数量和CPU逻辑处理器的数量一致就可以了, 多了没有作用. 还会带来启动新线程的开销.
CPU逻辑处理器就是线程数, 比如16核24线程的处理器, 最多开24个线程就可以了.

这不得不说一下Golang语言了, 它天然支持高并发就是因为它程序设计本身就是开启了与CPU线程数量一致的P(调度器), 所以使用Golang语言基本上就可以无脑的开协程, 你开一万个协程实际上只有24线程在互相调度. 背后的设计哲学真是非常优秀, 深挖golang源码可以发现抢占式调度, 一万个协程之间互相争抢着上调度器, 防止了有24个线程都是长时任务导致后面的协程一致饿死的情况. 但是更多情况下我们还是会为了防止协程滥用, 还会再设计协程池, 这导致Golang能非常快写出性能强悍的中间件

皮卡秋

哦，知道了

周小杰来也

不是线程不给力  而是cpu不给力