I am looking at my generated code, and yes, it produces a lot. I'll stick with it, for now, but I can but help wonder about the bloat of it. Below, a gross oversimplification.
Say you have n number of constructs, which binary encoded, take N bits. Say your program consists out of m of these constructs. Say for each of these constructs you need E bits to evaluate them. Then the difference in size between interpreted and compiled code is the decision between m*N+n*E (the binary size of m constructs + the size of the interpreter) or m*N*E (the binary size of compiling each construct). This balance is skewed in the sense that N*E can be made small, so I should concentrate on that I think.
It affects speed too. Given caches and all, if the size of the interpreted code is sufficiently smaller than the size of the compiled code, the interpreted code just might run faster.
Second, a change I'll implement anyway. I generate a lot of constants, my assumption is that the C compiler is smart enough to collapse a large number of the same constant to one unique constant. I think I was wrong, the const tag in C denotes a read-only value, not a constant value, so I guess -a minor adoption,- at some point I'ld need to factor constants out myself.
Last thing is locality. If a group of functions define a module, than that group of functions should be placed close together in memory, such that the program doesn't jump 'all over the place.' I think I am good in that respect, the namespaces help there too, but I might look at select statements which are general, and used a lot.
No comments:
Post a Comment