中国DOS联盟

其实，我的主要意思是这段话：

Originally posted by zyl910 at 2006-7-11 15:20:
而且现在是调用中断
时间主要耗在中断服务程序上
即此时的瓶颈是硬盘读写速度

Originally posted by asbai at 2006-7-11 20:46:
具体来说，使用了垃圾回收和自动存储管理；无类型变量；反射等机制的语言本身就是低效的。这样的语言即使直接编译成机器码也快不起来，有意思的是，这样做甚至会更慢，IBM知识库里有一篇文章专门测量了各种情况下，Java运行的效率：Weighing in on Java native compilation（http://www-128.ibm.com/developerworks/library/j-native.html）。

既然那些因素会影响程序效率，那为什么不绕开它呢。优化的技巧是多种多样的，必须结合平台和编程语言特性，扬长避短。

垃圾回收机制的确会影响性能，但它也有好处的。
先不用STL等数据结构库情况下用那些纯编译型的编程语言写个链表程序
再用Java、.Net写同样的程序（当然不是使用它们的类库，而是自己一个个地new出链表节点）
现在填充大量节点数据看看
你会郁闷的发现，那些纯编译的代码居然没有虚拟机速度快
这是因为，一般编程工具的内存分配函数调用的是操作系统的内存分配功能，而操作系统的堆分配函数本来就不是为分配大量小型对象服务的。所以许多数据结构经典教材会推荐我们自己写个内存分配器，专门处理链表节点这样的小型对象内存分配，这就是为什么现在推崇STL。
而那圾回收机制，最初就是为了解决这样的问题而设计的，能够应付i这样的大量小型对象分配问题。


其实我也不喜欢像Java、.Net，因为它们是专门为Web服务设计的，所以许多测试结果具有欺骗性。但就是因为这样，我曾经认真分析过它们性能。结果发现，对于现在那些编程初学者所接触的那些领域，Java、.Net已经优化到了极致，看起来似乎确实速度很快。而对于传统领域，那当然不能比的。

[ Last edited by zyl910 on 2006-7-11 at 22:25 ]

我的印象中 BASIC 有解释型的也有编译型的，GWBASIC、QBASIC 就是解释型的，QuickBASIC 是编译型的，但 GWBASIC 在保存源程序的时候可以以P参数把源程序以加密的形式保存起来，即看到的不再是文本文件。不知 "zyl910" 所说的P代码是不是指的就是这个。QBASIC 好象没这个功能。QuickBASIC 我想应该是编译成独立的可执行文件，运行的时候不需要 QuickBASIC 的环境支持，由于我没用过，所以只是我想编译型的应该就是这样的。到底怎样，还是请咱们的 "qb45" 来说一下吧。呵呵

Re: gogo
不知你找到的 UDMA 驱动是哪里下的，确实是有一个 UDMA for DOS 的驱动只能用在 VIA 芯片组的主板上，因为它就是 VIA 开发的，不过已经很老了，在我694X的主板上都不能用。我目前用的 UDMA 驱动确实如 "johnsonlam" 所说的是 Jack Ellis 开发的。而且在它的说明中说

This is a set of four DOS UltraDMA hard-disk drivers. All the drivers run UltraDMA disk(s) on PC mainboards using a "South Bridge" controller chip from Intel, VIA, SiS, ALi and other vendors.

我用的是 UDMA.SYS 而不是 UDMA2.SYS 。现在，又试用了一下你最新改进过的程序（在你30楼的回帖之前），发现完全可以在我的内存配置环境下得到所要扇区的正确内容！而且没有感觉上的任何延迟。之前的延迟我认为还是和你的程序错误有关。不过我只测试了读，没测试写。呵呵。
顺便说一下，就种类型的小程序而言，我认为执行的速度与什么CPU速度，所使用的编程语言，甚至算法的关系不大。即使有也不是人可以感觉得到的。
另外我大致模模糊糊的看了一下你对不支持 Int13h ext 而用 CHS 方式处理的换算，如果我没理解错的话，你的换算是以假定每道扇区数为63，磁头数为255为基础的，严格的说这是不严密的，你怎么能肯定所有硬盘的每道扇区数都为63，磁头数都为255呢。至少在老硬盘（<8.4G）和新硬盘（>137G）上出现这样参数的可能性几乎没有。即使在这个范围以内的硬盘也只能说大多数的 BIOS 中的 HS 参数如此，因为很有可能由于种种原因，BIOS 识别该硬盘或该硬盘的分区表中的 CHS 参数不是以 LBA 方式识别出的参数出现的。这时候如果你还是以 H=255，S=63 的死参数去换算的话很可能读写的扇区不是所要的扇区。

TO DOSforever:
关于 UDMA：
为了获得跟你一样的问题，我特地下了一些DMA DOS 驱动，试了WENGIER的
UDMA。DYS。 加载后，一切正常，没有你说的错读扇区
下了个UDMA2，说是只用于VIA
不知道你用的是什么UDMA？
关于 扇区换算：
没错，我只是以 H=255，S=63 的参数 去处理的。 当然可能会遇到不兼容的情况，我也考虑过。。
其实，较完善的方式当然是先获取硬盘的参数，再根据此参数去读写
不过，这种 H=255，S=63的实用性还是很广的，大部分的老硬盘都支持，还有新硬盘也支持（因为，新硬盘的控制器，能翻译各种读写方式）
不过，如果老硬盘设成了不兼容H=255，S=63模式，那就有问题了。。
有时间再改进吧。。

关于 我改进过的程序解决了问题：
确实改善更新了好几次（解决了几个BUG），不过，目前还不知道，是哪里代码的改变，解决了你的这个问题。。

刚才 解决了 基本INT13出错提示不显示的BUG。。。很高兴，装上了坏硬盘，都能显示出错原因了！。。。
真想用你的UDMA试一下。。
不是WENGIER的UDMA。SYS 吗？

[ Last edited by GOTOmsdos on 2006-7-12 at 01:52 ]

回zyl910兄：

既然那些因素会影响程序效率，那为什么不绕开它呢。优化的技巧是多种多样的，必须结合平台和编程语言特性，扬长避短。
■ 呵呵，让兄台见笑了，其实我这是有感而发。记得兄台说过汇编如果不用MMX和SSE等扩展指令，效率和VC比没优势，还举了一个完全使用不同算法的图像处理例子。当时就想说那是因为兄台的算法比起对手当算出神入化，并不是语言之间的公平比较。

垃圾回收机制的确会影响性能，但它也有好处的。
先不用STL等数据结构库情况下用那些纯编译型的编程语言写个链表程序
再用Java、.Net写同样的程序（当然不是使用它们的类库，而是自己一个个地new出链表节点）
现在填充大量节点数据看看
你会郁闷的发现，那些纯编译的代码居然没有虚拟机速度快
这是因为，一般编程工具的内存分配函数调用的是操作系统的内存分配功能，而操作系统的堆分配函数本来就不是为分配大量小型对象服务的。
■ 兄台用的是什么编译器？竟然拥有不带 small heap 的 malloc 和 new ？
■ .net 里似乎没有指针，用它实现链表的话。。。。。

所以许多数据结构经典教材会推荐我们自己写个内存分配器，专门处理链表节点这样的小型对象内存分配，这就是为什么现在推崇STL。
■ STL的容器统统使用标准 operator new 分配空间，对于list来说是每对象调用一次，这方面并不比自己手写的代码有什么优势。只有一个例外是 sgistl 里的池分配策略，不过该策略只是一个备选分配策略，默认不启用，并且不是C++标准兼容的。
■ STL之所以被推崇，是因为它为面向算法的程序设计思想（泛型编程）提供了一个高效的、可扩展的、规范的设计框架。
■ 当年的经典教材之所以推荐写自己的memory pool，主要目的不仅仅是O(1)+的分配效率，更重要的是内存碎片问题。该问题在所有使用分页内存管理的系统中已解决。而且所有现代编译器的标准库里也都有了small heap。

而那圾回收机制，最初就是为了解决这样的问题而设计的，能够应付i这样的大量小型对象分配问题。
■ 解释型语言的垃圾回收算法是伴随着大面积内存扫描的，兄台想说的是预分配和small heap？
■ 垃圾回收的效率是如此的底，而且其内存开销又是如此的高。在C里即使每次内存分配都没有small heap的帮助而直接向操作系统申请内存，其效率也应该垃圾回收。当然，这里有两个问题需要考虑：

■1. 程序运行了多久：垃圾回收是一种轮询机制，在2种情况下，垃圾回收会启动：
1. 内存耗尽－扫描整个内存段以释放不再使用的存储。
2. 轮询间隔到时－扫描所有正在使用的内存段以释放不再需要的存储。
因为伴随着大量扫描，所以垃圾回收的效率相当低。不过，对于一个运行时间不长、内存开销不大的应用来说，因为以上2点恰好都没满足，所以看不出来它的低效。

■2. 正在使用的操作系统：像DOS这样对内存管理较差的系统，在没有small heap帮助时高密度分配小量内存可能确实会比较慢。不过现在没有small heap的标准库已经很少了，而且现代操作系统的页式内存管理机制对这样的情况效率也高很多。

其实我也不喜欢像Java、.Net，因为它们是专门为Web服务设计的，所以许多测试结果具有欺骗性。但就是因为这样，我曾经认真分析过它们性能。结果发现，对于现在那些编程初学者所接触的那些领域，Java、.Net已经优化到了极致，看起来似乎确实速度很快。而对于传统领域，那当然不能比的。
■ 呵呵，窃以为，对于初学者来说，主要错误都发生在算法和程序逻辑上。

■ 差点忘记一条重要说明：俺其实很喜欢java和basic，并且对basic感情尤其深厚（大部分人编程基本都是从basic开始学起吧）。这里没有贬低任何语言的意思，每种语言本身就是为了解决不同的问题诞生的（不过俺对.net比较反感，嘿嘿）。这里只是想说，公平的比较的话，说basic、java的运行效率可以达到与C/C++并肩的程度，个人感觉有欠妥当。

当然，从另一个角度讲，只比效率也不公平。时空效率本身就不是这些语言的强项，使用简便、构造快速、可移植性强、丰富的功能/控件库等等才是这些语言的强项。

[ Last edited by asbai on 2006-7-12 at 07:56 ]

BASIC 有解释型的也有编译型的，GWBASIC、QBASIC 就是解释型的，QuickBASIC 是编译型的，我用的是版本是QuickBASIC4。5的版本，所以我给自己起网名就叫qb45，我只是一个爱好者，当初选择语言的时候，也是很犹豫，由于自己有工作，只是业余爱好编程，并不想当职业什么的，就选择了最简单的qb。

网友zyl910说的很对。确实编译成P代码。

对于一个使用者而言，可以说没有什么障碍。
在使用者眼中，qb可以编译成一个独立运行的EXE文件，也可以编译成需要qb库运行的程序。quick系列的basic支持中断调用、内嵌机器码，对于我这样的业余爱好者来说足够了。

我发现编程语言并不是主要的限制，对计算机原理、硬件、文件系统方面的深刻了解才能做出一些底层运用的软件

我的照片与简历希望大家能看看，最好能看完，谢谢大家。
http://www.programfan.com/club/showbbs.asp?id=82092

谢谢GOTOmsdos制作的好东东！！！

[ Last edited by wang6610 on 2006-7-12 at 20:46 ]

Originally posted by qb45 at 2006-7-12 08:38 AM:
BASIC 有解释型的也有编译型的，GWBASIC、QBASIC 就是解释型的，QuickBASIC 是编译型的，我用的是版本是QuickBASIC4。5的版本，所以我给自己起网名就叫qb45，栮..

你的那个页面还是不要宣传为好，对己对人都有以益。

完全同意楼上的看法，关于 轮子 的事情，能躲多远就躲多远，何必呢，自己倒无所谓，还连累家人。也没听说 洪战辉 是学这个的呀！

程序作了较大更新了。。

更新的内容请参看主贴的补充。。

[ Last edited by GOTOmsdos on 2006-7-13 at 00:05 ]

程序做了更新，估计能兼容老硬盘了！
也加入了读写 "非1.44mb"软盘的功能， 说明见主帖。。。

[ Last edited by GOTOmsdos on 2006-7-13 at 18:48 ]

虽说更新为可读写老硬盘，老软盘（非1.44MB格式），单自己没有这些古董，试不了
如果谁有机会碰到的话，可以试一试，看看运行的情况怎样？
如果一切正常那当然好，如果有问题，就把出错贴出来，以便解决。。

刚发现我的这个程序可以作为 GHOST 和HD-COPY 的迷你版 来使用
之所以叫迷你版，是因为：
GHOST：
本程序由于没有文件压缩功能（或分卷功能），所以最大只能处理4GB内的文件（也就是说，如果你要处理的分区在4GB内，就可以试用本程序了，当然你必须知道他的开始扇区位置和总扇区个数。。另外，如果是FAT16，那只能处理2GB内了）
HD-COPY：
HD-COPY有很多其他功能，而本程序只有读写主功能。

[ Last edited by GOTOmsdos on 2006-7-17 at 17:05 ]

哈哈，以后要解压镜象或制作镜象就用自己写的这个东东就解决啦！
好爽！

刚刚把注释掉的代码全清理掉了，并整理了代码，补充了注释，用VC 的对齐功能对齐了，看起来清爽了。
更新了。

发现这个程序在获取老硬盘参数时的BUG，这个BUG导致读写老硬盘失败
已更正。

原BUG如下：
cylinder=regs.h.ch+1; /* 寄存器的 CH +1 为柱面数 应该是CL的高2位为高2位，CH的8位为低8位 */
sector=regs.h.cl; /* 寄存器的 CL 为每道扇区数 应该是 CL 的低6位 */

改为：
cylinder=((((unsigned int)regs.h.cl)>>6<<8) | regs.h.ch) + 1;
sector=regs.h.cl & 0x3F;

在取值时，没有用指针甚至一般运算，用高效而好玩的位运算。。

现在读写老硬盘就可以了。。
如果有老硬盘的，可以试玩试玩，我自己还没有呢。。

[ Last edited by GOTOmsdos on 2006-7-20 at 20:52 ]

移除

[ Last edited by GOTOmsdos on 2006-7-22 at 14:58 ]