From: Isaac Waldron <waldroni AT lr DOT net>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP too slow!
Date: Sat, 22 Nov 1997 15:07:41 -0500
Organization: The Computer Nerd
Lines: 63
Message-ID: <34773B8D.B6D38BF9@lr.net>
References: <34755A66 DOT 1845 AT trash DOT lip6 DOT fr>
Reply-To: waldroni AT lr DOT net
NNTP-Posting-Host: plym1-10.worldpath.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Fabrice ILPONSE wrote:

> Hi!
> Here's the topic back.
>
>         That time have made a new test concerning video memory access.
>
>         TEST: DISPLAY THE DATA SEGMENT/SELECTOR directly to the video memory
> (BLIT) 32000 words.
>
>         For comparison: BC 3.1 and DJGPP.
>
>         Befor ALL: even in BC 3.1, i've used 32 bits inline assembly.
>                    i haven't used any existing libraries!
>
>         The  PROG:
>
>                 - switch to video mode 320x200x256
>                 - loop
>                         - change color 0 to red
>                         - BLIT
>                         - change color 0 to black
>                         - wait retical retrace
>
>         I've got a 486 DX2 66.
>
>         Results:
>                 - BC 16 bits red takes  40% of screen height
>                 - BC 32 bits 45 - 50%
>                 - DJGPP      90 - 95%
>
>         Those values are approximated. (humain looking)
>
>         I repeat it, i do not say anything about the djgpp generated code. I
> think it's as good as the BC one. But what else can slow down the
> performances?
>
>         Protected mode perhaps!
>
>         SOON: i'll  try to do the same under my modified protected mode BC 3.1
> version.
>
> Bye
> --
>         ^ ^ ^
>         | | |
>         +-+-+   Fabrice ILPONSE
>           |     <fabrice AT asim DOT lip6 DOT fr>
>           |
>           |
>           -

  I had sort of the same problem with my 3D graphics program.  I was using a for
loop to call _farpokeb(blah) 64000 times.  As you can probably figure, this was
quite slow.  However, when I switched to using movdata(blah) for both blitting a
page and clearing my draw_buffer, my program was suddenly 5 times faster!
movedata() is very well optimized, and so it works well for blitting pages to vid
mem.

Isaac Waldron <waldroni AT lr DOT net>
http://www.geocities.com/SiliconVally/Lakes/3574/index.html