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

qzwqzw

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

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

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

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

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

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

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位数应该都会有区别，只是不明显。

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（同上，只比前一个例子的数多一位二进制位数）
前者快了将近半秒，说明同样的字节（包括十进制和二进制）长度下，速度可能由这个数的二进制形态决定。

CrLf

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

CrLf

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

CrLf

但是楼上似乎忽略了set命令本身也有启动耗时，一次计算耗时和一次启动耗时应该相差很大的，我写了以下代码验证，结果证明1*1与1234567890*1234567890的耗时分别为13秒与17秒

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

CrLf

set本身也有启动耗时，并且应该远远大于计算耗时，所以需要以set /a n*n,n*n的形式来尽量缩小启动用时所占的百分比
我写了一段代码来证明，1*1与1234567890*1234567890耗时分别为13秒与17秒，证明计算耗时是存在的，并且相差很大

@echo off&setlocal enabledelayedexpansion
set s=1234567890*1234567890
title %s%
for /l %%a in (1 1 9) do set s=!s!,!s!
echo %time%
for /l %%i in (1,1,20000) do (
     set /a %s%
)
echo %time%
pause
复制代码

CrLf

好吧，那我们来总结一下，暂时把一句set /a的耗时划分为六部分：
1、语块的预处理耗时
2、变量延迟耗时
3、set命令的启动耗时
4、算式的预处理耗时
5、读取变量耗时
6、计算耗时（实际操作的时候不知道是否和第四部分同时完成）
7、赋值耗时

在这几部分中，1、2、3部分的耗时浮动可以多次测试用平均值尽量排除，而第5、7部分在我的测试代码中不存在，也就是说，我们现在争论的焦点是不同情况下“算式的预处理耗时”之间和“计算耗时”之间的差异。
这一点用批处理似乎没办法验证吧？

CrLf

这个是我没考虑周全，我原以为读取变量会慢些，所以当时没细想。但是楼上既然知道启动耗时大于一次计算耗时，那为什么一次set中只计算一次呢？这样一来计算耗时之差会被set启动耗时淹没，自然不明显了。我用set /a 1*1,1*1,1*1,1*1....的办法就是为了让计算耗时所占比重最大化。

@echo off&setlocal enabledelayedexpansion
set n=1&set s=n*n
for /l %%a in (1 1 9) do set s=!s!,!s!
title %n%
echo %time%
for /l %%i in (1,1,10000) do (
     set /a %s%
)
echo %time%
pause
复制代码

结果n=1时耗时39秒，n=1234567890时耗时44秒，这又作何解释呢？

CrLf

至于15楼的代码，我不懂编程，但是从vbs和bat的差别中猜测编程的计算方法、赋值方式完全不同于bat，所以exe的计算速度远快于cmd，生命游戏就是一个例子，可以exe版和bat版生命游戏来对比出同尺寸图、同样代数的用时

caruko

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

呃，我说的是15楼

CrLf

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

CrLf

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