X-Authentication-Warning:	howard.softserv.dynip.com: tyoung owned process doing -bs
Date:	Tue, 6 Oct 1998 16:29:37 -0400 (EDT)
From:	tyoung <tyoung AT netaxis DOT com>
X-Sender:	tyoung AT howard DOT softserv DOT dynip DOT com
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, 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:	<Pine.SUN.3.91.981006142307.17118H-100000@is>
Message-ID:	<Pine.LNX.3.96.981006144407.25720C-100000@howard.softserv.dynip.com>
MIME-Version:	1.0
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.

- Raw text -