Recently, our archeologists at the Pheonix Foundation discovered the remains of an ancient religious text among the ruins of the long lost civilization of program builders. It has long been assumed that the ancient program builders did their computations laborously by hand, however fresh from digging through RMS's closet, the archeologists have discovered evidence to the contrary. The yellowed scroll describes a means by which to hand-translate UM code into social memes. This allowed the program builders to run code natively on their collective social consciences.
guest:~/dev/paul_um guest$ time ./vm sandmark.umz trying to Allocate array of size 0.. ---- snip ---- free after loadprog.. success. loadprog ok. == SANDmark 19106 beginning stress test / benchmark.. == 100. 12345678.09abcdef ---- snip ---- 0. a8d1619e.5540e6cf SANDmark complete. real 2m3.995s user 2m1.253s sys 0m0.636s
guest:~/dev/paul_um guest$ time ./vm --compile sandmark.umz trying to Allocate array of size 0.. ---- snip ---- loadprog ok. == SANDmark 19106 beginning stress test / benchmark.. == 100. 12345678.09abcdef ---- snip ---- 0. a8d1619e.5540e6cf SANDmark complete. real 1m0.758s user 0m59.292s sys 0m0.478s
Known to work on:
- MacOS X
- Windows XP/Cygwin
Differences between interpreted and compiled code may vary. The runs above shows an improvement of 50%. On a similar computer with a better malloc/free allocator, the improvement was 66%. On a Windows XP box under Cygwin with a 3 GHz Pentium IV, both interpreted and compiled mode was slower than either of the above computers and only gained a 40% speed up through compiling.
Open question: What variables are influencing SANDmark performance?
A big thanks to Mike Pall for creating Dynasm, the framework that helped quickly construct the code generator in two days. It is quality work.
- The readline input routine is not perfect in some corner cases. This needs to be fixed.
- At the moment, only small UMCs such as sandmark run under the VM in compiled mode due to the prohibitive cost of maintaining link information for larger executables. I have sucessfully reengineered the Dynasm linker to work without needing a large in-memory data structure proportional with the program size, however I have not yet been able to actually remove the code that makes the large data structures in the first place. I should have that done soon, lifting this limitation.