som 4.1 w  (lex in vm)

test compiler, the old vm (som41.exe + som41.obj) 

input file is som41.txt (in dir som41) noi 4531929.

input file som3 (in som-31) (to be comparable to old benchmark) noi 4798780.

I suspect that the detailed analysis of the compiler benchmark is done on this som-31, but I am not sure as the figure here is less then the reported one (4919878, 30 July 2008).  I guess that the compiler has been improved.

30 Aug 2009

test new compiler (som41w.exe + som42.obj)
input: som31.txt  (dir som-31) noi 3757236

this is the new compiler compiled som v3.1

summary

  som v4.1 compiler  vs   som v4.2 (lex in vm)   
 
  noi v42/v41 = 0.78
  speedup 1-v42/v41 = 0.217

runtime: 
  v42  265 ms (on hp n6400, core2 2 GHz, profiling)
  v41  266 ms

9 Sept 2009

I suspect that the reason the running is not different between v41 and v42 is that it is i/o bound.  The trend is there, that when v41 compiler is improved (noi) 20% (compared to itself before improving the code), the running is also not different.  So, the next target should be trying to understand this i/o bound.  For example, reducing the amount of i/o will make it faster.  However, input cannot be changed so the aim should be at the output.  Two big files are generated: listing and object code.  Their sizes are (som v 4.2 compiler):

source:  2379 lines 45098 bytes
listing: 77824 bytes
object:  45056 bytes

If we can reduce these sizes, i/o will be faster.  Compress listing is unlikely (otherwise it can not be read by human). So, only object file is possible.  When I zipped the object file, it becomes 16384 bytes.  It is 36% of the original, or ~1/3.  With a simple compression scheme 50% is possible.

10 Sept 2009


som 42a  (with lex and fprints) compile som-31 noi 3410289

noi v42a/v41  (3410289/4798780) = 0.71
noi v42a/v42  (3410289/3757236) = 0.91
speedup noi v42a/v41 = 29%
speedup noi v42a/v42 = 9%
runtime  v42a  219 ms (this is faster than v42 265ms)

xsys 7.324 ms 73635 hits
a lot of fprintc occurs for fspace and fnl

19 sept 2009

