From: Larry Swanson <laswanson AT mwci DOT net>
Newsgroups: comp.os.msdos.djgpp,comp.graphics.algorithms
Subject: Why are screen pixels faster than double buffer?
Date: Thu, 08 Jan 1998 16:51:43 -0600
Organization: MidWest Communications, Inc.
Lines: 45
Message-ID: <34B5587E.C14B18B8@mwci.net>
NNTP-Posting-Host: dial-71.man.mwci.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

I recnetly started profiling my code using the rdtsc command in a NASM
procedure. I was suprised to see exactly how many cycles things took to
happen.  For example:

-----Procedure--------------------------How many
Cycles---------------------
Pixel to screen: 			250 cycles
Pixel to double buffer in ram		1500 cycles
Fill screen 16bit			290000 cycles
Fill RAM double buffer			330000 cycles

	As you can see, it takes  8 times as long to plot to memory.  I'm just
curious as to why, because I've always read that VRAM is slower than
RAM.  Also, doesn't  250 cycles seem like a long time for a pixel plot
any way?  I always thought it would be at least less than 75.

	I'm using far pointers so the code is the same for each procedure. 
Here's how I profile kjust in case i'm doing it all wrong...

----profile.asm---
section .text
global _Cycle_Fv

_Cycle_Fv:
       rdtsc;
       ret

------my c++ file (relevant porion at least)----
    extern unsigned volatile long long Cycle();


    	
    DISABLE();//so interrupts don't slow us down
    unsigned long long before = Cycle();
    Test .Pixel(0);// or the_screen.Pixel();
    unsigned long long after  =Cycle();   
    ENABLE();//turn on interrupts
    cout<< after-before<<endl;	    	


	If anyone could tell me why video memory is so fast compared to ram, or
point out a better way to profile this,  I would be very thankful.

	Thanks for reading this far,
	Jordan Swanson