[新手上路]批处理新手入门导读[视频教程]批处理基础视频教程[视频教程]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
天的白色影子

测试一下辩论回复

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

[ 本帖最后由 qzwqzw 于 2011-3-15 11:03 编辑 ]
天的白色影子

TOP

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

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

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

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

TOP

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

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

下面这段测试代码中
将set /a m=1换成set /a m=1234567
既可以进行对照测试
在我的环境下
总体运行时间在31~32秒之间
而两段程序的时间差小于1.7秒
也就是说两段程序的时间性能差距在%5之间
这个跟四楼的代码大于40%的差距相比
应该算不上明显的差距吧?
  1. @echo off&setlocal enabledelayedexpansion
  2. set /a m=1
  3. echo %time%
  4. for /l %%i in (1,1,1000) do (
  5. for /l %%j in (1,1,1000) do (
  6. set /a s=m*m
  7. )
  8. )
  9. echo %time%
  10. echo %s%
  11. pause
复制代码
天的白色影子

TOP

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

  1. #include "Stdio.h"
  2. int main(void)
  3. {
  4. long i,j,s;
  5. i=j=s=0;
  6. for (i=0;i<100000;i++)
  7.    for (j=0;j<100000;j++)
  8.      s=1234567*7654321;
  9. }
复制代码
天的白色影子

TOP

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

看不出你的这段代码与以前的有什么本质上的不同
启动耗时当然会有(我这里理解为将命令加载到内存并进行预处理的耗时)
而且也有可能确实大于计算耗时(我这里理解为命令在内存中参与运算和执行的耗时)
但你的代码如何能证明启动耗时与计算耗时相差极大?
你确认你的代码对于1*1和1234567890*1234567890
他们的启动耗时(具体的说就是对命令行的预处理)是一样的吗?
如果不是一样的
你又如何比较计算耗时的差别呢?
天的白色影子

TOP

本帖最后由 qzwqzw 于 2011-3-21 14:22 编辑
不同情况下“算式的预处理耗时”之间和“计算耗时”之间的差异。
这一点用批处理似乎没办法验证吧?

我是否可以理解为
你已经取消了以前“计算耗时是存在的,并且相差极大”的论断?

正如你说
计算耗时与预处理耗时难以严格区分
但是你从我的批处理代码仍然没有看出什么吗?

是的
1*1和1234567*1234567必然会有预处理上的差异
我们所能做的只有尽量减少这部分差异
所有我使用了从内存变量中读取操作数的做法
那比从命令行读取操作数要快很多
相对而言耗时差异也会缩小
天的白色影子

TOP

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


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

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

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

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

TOP

返回列表