[新手上路]批处理新手入门导读[视频教程]批处理基础视频教程[视频教程]VBS基础视频教程[批处理精品]批处理版照片整理器
[批处理精品]纯批处理备份&还原驱动[批处理精品]CMD命令50条不能说的秘密[在线下载]第三方命令行工具[在线帮助]VBScript / JScript 在线参考
返回列表 发帖

[其他] [已结束]电脑处理1*1和1234567*134567一样快吗?

结束时间: 2011-4-30 17:27 ,裁判: qzwqzw

评判时间: 2011-4-30 17:27

裁判观点: 对于非计算机原理专业的论坛
能讨论到如此程度
我是十分意外并且高兴的
主要是因为几位重量级人物的参与
包括
持支持意见的理论派wc726842270
持中立意见的技术流neorobin
持反对意见的实证家zm900612
最佳辩手我选择非常勤勉的zm
不论观点是否正确
负责任的态度和积极参与的热情值得肯定

至于最后的结论
我想是不用总结的
任何论点都会受到多方面因素的影响
包括它所处的环境和所讨论的深度
不过就此论点来说
目前为止反对派占明显的大多数
而且正方的意见到目前为止都不够有力
这说明反对和中立的意见是当前的主流意识

最佳辩手: zm900612

本帖最后由 qzwqzw 于 2011-4-30 17:25 编辑

辩论已结束
对于非计算机原理专业的论坛
能讨论到如此程度
我是十分意外并且高兴的
主要是因为几位重量级人物的参与
包括
持支持意见的理论派wc726842270
持中立意见的技术流neorobin
持反对意见的实证家zm900612

至于最后的结论
我想是不用总结的
任何论点都会受到多方面因素的影响
包括它所处的环境和所讨论的深度
不过就此论点来说
目前为止反对派占明显的大多数
而且正方的意见到目前为止都不够有力
这说明反对和中立的意见是当前的主流意识
——————————————————————
首先声明
这并非批处理编程直接相关的问题
而是因为一个批处理而衍生的问题
版主大大不要见怪

理所当然
对于人脑来说
1234567*1234567明显比1*1消耗更多的能量和时间
那么对于电脑来说
也是如此吗?

请大家畅所欲言——
注意:
据我的测试
一旦选择“支持正方”或“支持反方”后
即选定了辩论立场且无法中途改变
所以请谨慎选择支持立场!


另外,
如果觉得某个回复很棒很合自己心意
请不要忘记投上自己赞成的一票

[ 本帖最后由 qzwqzw 于 2011-3-15 11:01 编辑 ]
正方

嗯,几乎是一样快

反方

不,差别相当明显

1

评分人数

    • Batcher: 感谢给帖子标题标注[已解决]字样PB + 2
天的白色影子

以下引用 wikipedia 对 RISC 和 CISC 的相关阐述 进一步阐明我的观点: 1*1和1234567*134567, 因机器字长及CPU核心电路设计 以及 核心指令设计方案而不同, 可能耗时差异很大, 也可能都只需要耗时 1 个时钟周期.
http://zh.wikipedia.org/wiki/%E7%B2%BE%E7%AE%80%E6%8C%87%E4%BB%A4%E9%9B%86

...
另一方面,目前最常见的复杂指令集x86 CPU,虽然指令集是CISC的,但因对常用的简单指令会以硬件线路控制尽全力加速,不常用的复杂指令则交由微码循序器“慢慢解码、慢慢跑”,因而有“RISCy x86”之称。
...
复杂指令集(CISC)
例如:Intel的奔腾系列中央处理器属于复杂指令集(x86)结构,而IBM的PowerPC 970(用于苹果机Power Mac G5)中央处理器属于精简指令集(POWER)结构。但是自从 Intel Pentium Pro(P6)之后,x86复杂指令集的CPU也开始采用内核精简指令集,而在外围布置从复杂指令集到精简指令集的译码电路动态译码方式,籍此提高CPU的性能,使复杂指令集CPU也有可能在1个时钟周期内运行一条甚至多条指令
1

评分人数

TOP

各位想要实际测试的朋友: 至少 要用同样的 汇编代码 分别在一个 <=32位的机器 和 一个 >=64位的机器上分别做测试

TOP

1. 1*1 这在任何一台电脑上都不会超出 单字节(8 位) 整型数运算范围, 也不会超出最小字长 8 位
所需要的时间无疑是 乘法运算里 最少的.

2.
两个大数以及它们的积的十六进制表示如下:

1234567
12D687

134567
20DA7

166131977489
26AE3CCD11

两个大乘数都在 4 字节以内, 而积却超出了 4 字节(32 位).
现在我们使用的多数 PC 机都是 32 位机, 直接作为整型数计算会产生溢出, 这种情况下会是很不一样的.

用 32 位机的 RISC 指令集肯定是不能直接计算得到结果的, 得有程序支持才行.

而在 64 位(8字节)及 64 位以上的机器上, 乘数和积的存储长度都没有超出,
运算器的设计就可能让 1*1和1234567*134567 都是花费一个同样的最少的计算时间, 换而言之,
现在的 CPU 核心电路设计和 RISC 指令可以(或将会)实现:
当 操作数 和 理论计算结果 在同一个 整型数据类型 的计算范围内时, 任何小的数的运算和任何大的数的运算
都将花费同样多的时钟周期, 也就是费时一样长.

最终观点: 1*1 和 1234567*134567 在 32 位及以下的机器上会有很大的耗时差异, 而在 64 位及以上
的机器上已经实现(或将会实现)耗时完全相同.

TOP

为了证实这个推论,首先要做出计算公式,另外要有科学的验证观,不可以只凭一次数据就下结论,
因此我发现计算机的其它软件也会影响结果,我运行时把网络和所有的应用程序都退出了.
为了更加准确我把程序写了两次,将计算互换位置以验正计算结果的真实性与无干涉性.
并做了反复循环以让大家利用平均数来进行验正.
另外为了不受开程序时鼠标点击和键盘的缓冲影响特加了多行空显,所以所有语句都是有用的!
  1. @echo off
  2. :xx
  3. echo.
  4. echo.
  5. echo.
  6. echo.
  7. echo.
  8. echo.
  9. echo 开始计算 1*1 用时如下:
  10. set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  11. for /l %%i in (1,1,10000) do set/a b=1*1
  12. set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  13. set/a t2="%t1%"-"%t%"
  14. echo 用时0.%t2%秒
  15. echo.
  16. echo.
  17. echo.
  18. echo.
  19. echo 开始计算 1234567*134567 用时如下:
  20. set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  21. for /l %%i in (1,1,10000) do set/a b=1234567*134567
  22. set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  23. set/a t2=%t1%-%t%
  24. echo 用时0.%t2%秒
  25. pause
  26. echo.
  27. echo.
  28. echo.
  29. echo.
  30. echo.
  31. echo.
  32. echo 开始计算 1234567*134567 用时如下:
  33. set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  34. for /l %%i in (1,1,10000) do set/a b=1234567*134567
  35. set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  36. set/a t2="%t1%"-"%t%"
  37. echo 用时0.%t2%秒
  38. echo.
  39. echo.
  40. echo.
  41. echo.
  42. echo 开始计算 1*1 用时如下:
  43. set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  44. for /l %%i in (1,1,10000) do set/a b=1*1
  45. set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
  46. set/a t2=%t1%-%t%
  47. echo 用时0.%t2%秒
  48. pause
  49. goto xx
复制代码
我的结果是10000次1*1在0.22秒左右,1234567*134567在0.26秒左右.
发现这个程序还可以用来测试当前计算机的运行能力,如果时间加长了一定有什么软件在占用内存呵!
希望能满意我的答复!

TOP

绝对是有差别的,计算机只是算得快并不是算得巧,追朔到最原本的电路开关上不论是什么只有0和1的差别,所以不论是加减还是乘除都是在做加法运算,只是正序还是倒序的问题.
所以虽然在一般计算中时间差别很微小(由于CPU能力太强),但累加到一定数量时还是会出现差别的!

当然程序的编程优化可以改变时间的最终结果,但也只能做到均衡,无法在极端条件下也做到一样快,
从绝对时间观上说是一定有区别的,不论是千分之一秒还是万分之一秒!不论你是否能感觉到!
差别依然还是有的!

TOP

1*1那个
19:39:18.01
19:39:18.29
1234567*1234567那个
19:39:18.31
19:39:18.59

TOP

怎么感觉跑题了。如果使用代码来测试,很可能人为的增加了其复杂程度,对此个人比较相信低级语言(计算机语言,汇编语言),当前我们用的都是32位机(除了服务器外),而CPU也随之强大了。单单从人类的角度来看,这几乎是没有差距的。感觉上就像光走了1000M和走了1M的时间似的。在数学上可以说是相同的
枫中残雪:风停了,我的心却在动,让我心中的寒意走向远方

TOP

至于set命令内部预处理的耗时,请参考11楼测试结果,虽然结果相同时速度仍有差异,但是预处理并非决定性因素。

TOP

stop,要想不跑偏必须先统一一下意见,因为以后的讨论可能是以此为前提的:
1、set 命令读取变量时的速度快于预处理解释字符串的速度,也就是说set /a m=n(此时n=1)真的快于set /a m=1吗?
2、set 命令读取变量的速度是否取决于变量的字符串长度?

暂时没时间做实验,证明这两个假设的工作先交给诸位了哈...

TOP

本帖最后由 qzwqzw 于 2011-3-21 20:37 编辑


现在问题的讨论方向终于有些触及我所思考的核心了

对于23楼的程序我的解释是这样的
虽然你降低了命令启动的次数
但是仍然没有完全排除计算前读取时间的差异
反而是扩张了这部分差异的影响
从一个变量中读一个字符和一个字符串的差异是很明显的

关于这一点你将测试数据改为
123456789*123456789  (=15241578750190521)

987654321*987654321  (=975461057789971041)
就会体会到了
这两组数据的结果差值甚至大于1*1与123456789*123456789结果插着
但实际前两组数据的运行时间几乎是相同的
天的白色影子

TOP

不懂编程,不过我觉得如果乘法只是加法集合成的函数,那不见得速度一样快

TOP

那个, 加法的汇编指令就一条, 乘法的汇编指令也是一条

虽然, 不同指令, 速度很可能不一样, 但是, 运行一条指令, 时间几乎可以忽略不计

而加法, 乘法指令, 是内置的, 速度, 应该差不到哪里去, I see.

TOP

批处理怎么设值变量类型??

TOP

本帖最后由 caruko 于 2011-3-22 12:48 编辑

楼上,你将S设为INT型,差距应该比10MS大

呃,我说的是15楼

TOP

返回列表