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

qzwqzw

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

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

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

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

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

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

qzwqzw

第一张正方回复仅为测试
请不要在此投票

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

CrLf

我在想，如果乘法是通过加法实现的，那1*10000000和100000000*1的效率是否有别呢？对人来说，这是荒谬的，但是假如电脑是很死板的把X加N次，那二者效率很可能有所不同，当然了，估计就算真的是把某个数加N次，也很可能是先判断二者大小
手上尚无测试结果，暂且中立

CrLf

构造了两个个数十兆的超大bat，有了理论支持，果断反方：

@echo off&setlocal enabledelayedexpansion
for %%a in (1 40000) do (
set s=%%a*%%a
set /a n+=1
for /l %%a in (1 1 9) do set s=!s!,!s!
(
echo @echo off
echo echo %%time%%
for /l %%l in (1 1 10000) do echo set /a !s!
echo echo %%time%%
echo pause)>test!n!.bat
)
pause
复制代码

测试结果（进行了两次）：
test1.bat   20.08秒  19.07秒
test2.bat   28.60秒  28.67秒

这很说明问题了，当然了，这是上万次的set叠加才有这么明显的落差，少量使用时差别必定不明显。可惜没时间进行大量测试，无法描绘函数图象，否则应可猜测set /a的工作原理

随风

猜：应该不一样快吧，除非是有现成的答案只要读取，否则计算的话总有个过程吧，2位数和1位数应该都会有区别，只是不明显。

Batcher

这个要查一查《计算机组成原理》、《汇编语言》等教材了吧
看看它是怎样把乘法转换成加法、实际计算的时候在几个寄存器里面是怎么倒腾的
^_^

wc726842270

个人认为这很明显是取绝于数据复杂程度。电脑的开发也不外乎来自人类的自身思维，我想就这两个数据来看是看不出什么的。“CPU的计算率很高”。这也许需要计算机的低级语言了（或从原理着手），个人认为使用代码计算是不可取的

qzwqzw

嗯，现在正反双方战力是1：2
我是个伪正方
误点击了“支持正方”

3楼的代码自有可取之处
只是需要根据情况再优化一下

4楼的思路是个方向
希望能够更深入

6楼的“CPU的计算率很高”让我很迷惑
看来也需要再答疑解惑一下了

wc726842270

中央处理器的工作速度与工作主频和体系结构都有关系。中央处理器的速度一般都在几个MIPS（每秒执行100万条指令）以上。有的已经达到几百MIPS 。
百度刚找到的，可能不在点子上。从极值的角度来说是差不多的（关键是这个点是什么还不清楚）

caruko

一般来说，电脑处理数值计算跟数值的字节长度有关系。

电脑的二进制加法器电路是通过“异或门”电路跟“与门”电路来计算结果的。
一般的高级语言在计算时都要指定数值精度，比如 8字节的int型数值是0-255。
电脑每次处理8字节int型数值计算时，都需要从最低位计算加到最高位。
所以字节数一样的数，计算时间一样，1+1 跟1+100是一样的。

在一般的程序语言中，“1234567”这个数比“1”明显字节长度更长，加法器需要花更多时间计算。
虽然不确定批处理转换后的数字是多少字节，因为字符跟数字没有分开，不知道如何转换的，或者存储结构是特殊设计的。
但3楼代码可以看出批处理在解释数字时，还是会自动匹配合适字节的数。

CrLf

又做了几个测试：

1*1000000,1000000*1
没有大于0.3秒的差别，但是几次测试，后者始终稍快，说明计算前可能并未比较数字大小

而805306366*2却比127867*12596（乘积均为1610612732）
前者快了近两秒，说明确实与复杂度有关，看来有可能真的是用加法，不过究竟具体操作的时候倍增还是指数增长就不得而知了。

536870912*3,1073741823*3（两个大数分别为10000.....00和11111.....11，二进制位数相同）
没有大于0.3秒的差别，数次测试中，前者始终稍快，说明速度和二进制形态或者十进制字节数有关。

1073741824/2,2147483647/2（同上，只比前一个例子的数多一位二进制位数）
前者快了将近半秒，说明同样的字节（包括十进制和二进制）长度下，速度可能由这个数的二进制形态决定。

qzwqzw

很可惜！
辩论没有向我想象的那个方向发展

好吧
既然选了正方
我就抛出一些正方的观点和证据

下面这段测试代码中
将set /a m=1换成set /a m=1234567
既可以进行对照测试
在我的环境下
总体运行时间在31~32秒之间
而两段程序的时间差小于1.7秒
也就是说两段程序的时间性能差距在%5之间
这个跟四楼的代码大于40%的差距相比
应该算不上明显的差距吧？

@echo off&setlocal enabledelayedexpansion
set /a m=1
echo %time%
for /l %%i in (1,1,1000) do (
	for /l %%j in (1,1,1000) do (
		set /a s=m*m
	)
)
echo %time%
echo %s%
pause
复制代码

CrLf

楼上考虑过for /l循环本身的用时吗？

CrLf

不过仔细想想，也许正是因为语句的字符长度不同导致预处理时间相异，所以4楼代码才会有这么明显的差别。
仅仅个人猜测而已，未验证

qzwqzw

嗯，预处理
终于有人想到了这个
嗯再贴一段ANSI C代码
把1234567*7654321换成1*1
即可进行比照测试
我使用WinTC2编译链接后
放在批处理中测试
两段程序的耗时均为59.06秒
时间性能差距小于10ms
这又说明什么问题呢？

#include "Stdio.h"

int main(void)
{
 long i,j,s;
 i=j=s=0;
 for (i=0;i<100000;i++)
   for (j=0;j<100000;j++)
     s=1234567*7654321;
}
复制代码