[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA-user: Re: Efficient Memories




On 5 Apr 2007, at 11:22:18 AM, Stephen Williams wrote:

> lingwitt@bellsouth.net wrote:
>> I've made a BMP image format creating module for fun.
>>
>> I maintain a 640x480 24-bits per pixel buffer and then write the data
>> out to a file.
>>
>> At first I used a reg array, but came to find that each element of  
>> such
>> a structure
>> is expressed in vvp assembly as distinct reg. This made the vvp  
>> assembly
>> 32 MB
>> and unrunnable.
>
> Now independent of all the above, I'm surprised that 32Meg makes
> a vvp file "unrunnable". I can believe "slow to load", but unless
> you are very memory constrained, it shouldn't be that much slower
> then in older snapshots before exploded arrays.
>
> Try "vvp -v foo.vvp" to get a bit more detail what might be
> going on.


Here are the results from
	(1) Large reg (byte) array	:	reg [7:0] data [0:sizeImage-1]; 		//  
sizeImage =   640*480*3 bytes
	(2) Large reg vector		:	reg [sizeImage*8-1:0] data;


(1) (a) Running iverilog produces in 11.6 seconds the file a.out,  
which is 35 MB:

	Using language generation: IEEE1364-2001+Extensions,specify,xtypes
	PARSING INPUT
	LOCATING TOP-LEVEL MODULES
	   test
	... done, 0.02 seconds.
	ELABORATING DESIGN
	... done, 0.68 seconds.
	RUNNING FUNCTORS
	-F cprop ...
	-F nodangle ...
	... 1 iterations deleted 0 dangling signals and 0 events. (count=0)
	... done, 0.01 seconds.
	CODE GENERATION -t dll
	... invoking target_design
	... done, 11.6 seconds.
	STATISTICS
	lex_string: add_count=44 hit_count=123


(1)	(b) 	Running vvp -v a.out takes 1.22 hours to compile
		and 15.3 seconds to run (fill all locations and write file).
	
	Compiling VVP ...
	Compile cleanup...
	... Linking
	... Removing symbol tables
	...        0 functors
	                  0 table
	                  0 bufif
	                  0 resolv
	                  0 variable
	...      901 opcodes (16384 bytes)
	...   921630 nets
	...        0 memories
	...        5 scopes
	... 4404.64 seconds, 0.0/0.0/0.0 KBytes size/rss/shared
	Running ...
	... 15.3602 seconds, 0.0/0.0/0.0 KBytes size/rss/shared
	Event counts: (event pool = 0)
	       20007 thread schedule events
	           0 propagation events
	           0 assign events
	           0 other events




(2) (a) Running iverilog produces in 0.03 seconds the file a.out,  
which is 32 KB:
	
	Using language generation: IEEE1364-2001+Extensions,specify,xtypes
	PARSING INPUT
	LOCATING TOP-LEVEL MODULES
	   test
	... done, 0.01 seconds.
	ELABORATING DESIGN
	... done, 0.01 seconds.
	RUNNING FUNCTORS
	-F cprop ...
	-F nodangle ...
	... 1 iterations deleted 0 dangling signals and 0 events. (count=0)
	... done, 0 seconds.
	CODE GENERATION -t dll
	... invoking target_design
	... done, 0.03 seconds.
	STATISTICS
	lex_string: add_count=47 hit_count=123
	

(1)	(b) 	Running vvp -v a.out takes 0.02812 seconds to compile
		and 11.7084 seconds seconds to run (fill all locations and write  
file).

	Compiling VVP ...
	Compile cleanup...
	... Linking
	... Removing symbol tables
	...        0 functors
	                  0 table
	                  0 bufif
	                  0 resolv
	                  0 variable
	...      907 opcodes (16384 bytes)
	...       33 nets
	...        0 memories
	...        5 scopes
	... 0.02812 seconds, 0.0/0.0/0.0 KBytes size/rss/shared
	Running ...
	... 11.7084 seconds, 0.0/0.0/0.0 KBytes size/rss/shared
	Event counts: (event pool = 0)
	       20007 thread schedule events
         	   0 propagation events
	           0 assign events
	           0 other events

In other words, exploding the arrays has a significantly bad impact  
on performance.

As comparison:
	import time
	time1=time.time(); a = range(1024*768*3*8); print time.time() - time1

gives:

	1.99313998222 seconds

and:

	time1 = time.time()
	
	for i in xrange(1024*768*3*8):
     		a[i] = 0;
	
	print time.time() - time1

gives:

	13.961877107620239 seconds.

Why not go ahead and compile vvp assembly?
What makes python faster?

Thanks for your time.


_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user