*sigh* This is bad enough to be called a bug. If you have a small example that triggers this "aspect", can you file it as a bug report? You have my permisison to nudge its priority up to "6" because this is actually quite embarrassing:-(
[EMAIL PROTECTED] wrote: > > On 5 Apr 2007, at 11:22:18 AM, Stephen Williams wrote: > >> [EMAIL PROTECTED] 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 > -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user