X-Authentication-Warning: howard.softserv.dynip.com: tyoung owned process doing -bs Date: Tue, 6 Oct 1998 16:29:37 -0400 (EDT) From: tyoung X-Sender: tyoung AT howard DOT softserv DOT dynip DOT com To: Eli Zaretskii , oti AT phys DOT uu DOT nl, nate AT cartsys DOT co DOT softserv DOT dynip DOT com cc: djgpp AT delorie DOT com Subject: Re: Slooooww Iooooo -- Please help. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Gentlemen, Thanks for all your suggestions. I am trying to update you all without messaging Usenet until I have solved or bypassed the problem. I tried cprintf with no apparent difference. In fact redirecting stdout to nil ( "ric.exe testroth > nil" ) had little effect on timing. I also ran with RAMDRIVE to minimize file IO times. The jobs ran in about half the time with RAMDRIVE as they did from disk. I do not intend to spend much more time on DOS performance. I will announce a new Linux/DOS version soon, with or without performance improvements. My conclusions are: . Linux caches I/O superbly . Scrolling stdout to the screen is slow and avoidable. I intend to include functions to invoke curses routines for screen I/O. I now have a working DJGPP curses library for the cross-compiler. . There remains a large DOS penalty for this particular program which may not be excessive for those with more disk/memory/CPU power than I have on my Gateway 2000/P66 with 16meg. . A different profiler might help to pin down problem areas. I reply to Mr. Zaretskii points below. On Tue, 6 Oct 1998, Eli Zaretskii wrote: > > On Sun, 4 Oct 1998, tyoung wrote: > > > Actually, I have run with a RAMDRIVE under DOSEMU and a typical > > job runs about twice as fast. > > RAMDRIVE is not a disk cache, it's a RAM disk. I understand. I think a RAM disk should be at least as fast as a cache. > I also don't understand what does ``twice as fast'' means. Twice as > fast as what? In your original message you said that Linux is 10 > times faster than Windows 95. My experience with well-tuned > DOS/Windows systems is that they are about 40% slower than Linux on > the same platform. Twice as fast with RAMDRIVE as without it. 40% slower would be nice. The original message was '... about ten times faster ..., so with DOSEMU/RAMDRIVE the times are about five times as long as Linux run times on the same platform. > > > So it > > looks like the int's and accompanying real/protected mode switching > > is the problem. > > This can only happen if your program doesn't do much except > reading/writing large files, or if you use disk I/O inefficiently. It > might be a good idea to describe in more detail what the program does. An older Linux version and description is freely available, without source, at ftp.softserv.dynip.com/pub/linux/ric/ric.tgz. Use nlist, not ls or dir. There are no large files, only a number of small ones. It is the same disk, the same machine, and the same program (only cross-compiled for msdos). Disk IS used inefficiently, in that no attempt is made to save information from include'd files. The same file may be re-read and re-interpreted many times. However, the same is true under Linux. Since it seems Linux caches file I/O more efficiently, this might account for the much faster times under Linux, but then I would expect the RAM disk to perform better than it did. The program uses yacc/flex to run as a calculator, interpreting functions from a file (and included files), printf'ing strings to stdout, and freeing the strings. There are a number of complex, financial functions (runroth, for instance), but they do no I/O. Profiling does not materially affect the overall performance under DOS or Linux except at the end while writing 'gmon.out'. That is to say the screen scrolls by at about the same rate with a version compiled with profiling as a version compiled without profiling. The latest Linux profile follows: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 50.00 0.02 0.02 922 21.69 21.69 lookup 25.00 0.03 0.01 382 26.18 26.18 sstaxable 25.00 0.04 0.01 1 10000.00 10000.00 initlife 0.00 0.04 0.00 1225 0.00 2.96 yylex 0.00 0.04 0.00 382 0.00 26.18 incometax 0.00 0.04 0.00 72 0.00 0.00 normal 0.00 0.04 0.00 66 0.00 0.00 allroth 0.00 0.04 0.00 23 0.00 0.00 yy_load_buffer_state 0.00 0.04 0.00 22 0.00 0.00 yy_flex_alloc 0.00 0.04 0.00 20 0.00 0.00 yy_flex_free 0.00 0.04 0.00 18 0.00 1347.86 networth 0.00 0.04 0.00 18 0.00 0.00 stgain 0.00 0.04 0.00 18 0.00 1321.68 taxondeferredincome I spent time eliminating all flex backups, inlining routines, etc. (there are no YACC conflicts). This improved the Linux performance marginally but with no noticable effect on MSDOS times. Regards, Tom ICQ# 4891876 -- tyoung AT netaxis DOT com -- softserv AT dynip DOT com Check Public Key Server for PGP key.