CrLf

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

wc726842270

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

jinzeyu

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

mxxcgzxxx

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

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

mxxcgzxxx

为了证实这个推论,首先要做出计算公式,另外要有科学的验证观,不可以只凭一次数据就下结论,
因此我发现计算机的其它软件也会影响结果,我运行时把网络和所有的应用程序都退出了.
为了更加准确我把程序写了两次,将计算互换位置以验正计算结果的真实性与无干涉性.
并做了反复循环以让大家利用平均数来进行验正.
另外为了不受开程序时鼠标点击和键盘的缓冲影响特加了多行空显,所以所有语句都是有用的!

@echo off
:xx
echo.
echo.
echo.
echo.
echo.
echo.
echo 开始计算 1*1 用时如下：
set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
for /l %%i in (1,1,10000) do set/a b=1*1
set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
set/a t2="%t1%"-"%t%"
echo 用时0.%t2%秒
echo.
echo.
echo.
echo.
echo 开始计算 1234567*134567 用时如下：
set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
for /l %%i in (1,1,10000) do set/a b=1234567*134567
set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
set/a t2=%t1%-%t%
echo 用时0.%t2%秒
pause
echo.
echo.
echo.
echo.
echo.
echo.
echo 开始计算 1234567*134567 用时如下：
set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
for /l %%i in (1,1,10000) do set/a b=1234567*134567
set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
set/a t2="%t1%"-"%t%"
echo 用时0.%t2%秒
echo.
echo.
echo.
echo.
echo 开始计算 1*1 用时如下：
set t=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
for /l %%i in (1,1,10000) do set/a b=1*1
set t1=%time:~0,2%%time:~3,2%%time:~-5,2%%time:~-2,2%
set/a t2=%t1%-%t%
echo 用时0.%t2%秒
pause
goto xx
复制代码

我的结果是10000次1*1在0.22秒左右,1234567*134567在0.26秒左右.
发现这个程序还可以用来测试当前计算机的运行能力,如果时间加长了一定有什么软件在占用内存呵!
希望能满意我的答复!

neorobin

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 位及以上
的机器上已经实现(或将会实现)耗时完全相同.

neorobin

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

neorobin

以下引用 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个时钟周期内运行一条甚至多条指令。