Integer Speed Test
	integer ops in a loop 1234567 times
	tests integer op speed and looping speed
	is O(n) for n = number of iterations

C:      real 0.85       user 0.78       sys 0.01
Java:   real 1.28       user 0.95       sys 0.26
No JIT: real 3.96       user 3.73       sys 0.21
MCJava: real 3.38       user 0.10       sys 0.11
Python: real 17.67      user 17.39      sys 0.06
Perl:   real 13.55      user 13.29      sys 0.01
ZenVM:  real 3.42       user 3.33       sys 0.00
AceVM:  real 3.42       user 3.32       sys 0.01

	As you can see, C is very fast. Java with the JIT switched
	on is also very fast. Java with no JIT is slower than my
	machines, ZenVM (developed for 1999 SE course) and AceVM
	(a Unicode variant which is optimised). The multicomputer
	Java implementation is slower than the local JavaVM, but
	this is due to the time it takes to establish a connection
	to the multicomputer. Python and Perl are slow on plain
	integer operations.


String Speed Test
	string ops in a loop 10,000 times
	tests string ops and looping speed
	is O(n) for n = number of iterations

Java:   real 4.33       user 3.95       sys 0.33
No JIT: real 25.96      user 25.58      sys 0.30
MCJava: real 10.77      user 0.10       sys 0.14
Python: real 2.99       user 2.94       sys 0.05
Perl:   real 2.92       user 2.83       sys 0.01
ZenVM:  real 5.60       user 5.58       sys 0.01
AceVM:  real 2.88       user 2.82       sys 0.00	8-bit chars
AceVM:  real 3.00       user 2.98       sys 0.01	32-bit Unicode chars

	The fastest string operations seem to be:
		AceVM (8-bit version)
		Perl
		Python
		AceVM (32-bit version)

	Java is a bit slower again, and then the multicomputer is
	surprisingly slower, and then local Java with no JIT is
	hideously slow. Why? My guess is that it's a combination
	of integers being slower, and therefore string slicing is
	slower, and this compounds the effect.

	It's interesting that the 32-bit Unicode version of AceVM
	is almost as fast as Python, despite using strings 4 times
	as long. Admittedly the strings used in this test are not
	very long, so there isn't much of an effect.


String Building Test
	build a string 4700 chars long, one char at a time
	tests memory copying and looping speed
	is O(n*n) for n = number of iterations due to memory ops

Java:   real 1.39       user 1.04       sys 0.30
No JIT: real 1.71       user 1.39       sys 0.32
MCJava: real 2.90       user 0.06       sys 0.14
Python: real 0.22       user 0.17       sys 0.04
Perl:   real 0.29       user 0.25       sys 0.04
AceASM: real 0.03       user 0.00       sys 0.01
ZenVM:  real 0.78       user 0.77       sys 0.01
AceVM:  real 0.15       user 0.13       sys 0.02	8-bit chars
AceVM:  real 0.41       user 0.39       sys 0.02	32-bit Unicode chars

	This test builds a string by adding one char to it each
	time through a loop. It's meant to test string allocation
	and memory copying. The fastest results seem to be:
		AceVM (8-bit version)
		Python (it hashes the string each time)
		Perl
		AceVM (32-bit version)

	Java, again, is slower. Interestingly, Java without the JIT
	is a lot faster than the plain String Speed test above.
	Clearly, looping is still efficient even without the JIT,
	but it must be slicing which makes the difference between
	this result and the one above. There is no slicing in this
	test, just string concatenation.

	The AceVM Unicode version is half as fast as Python, but
	this is not surprising, since this test really thrashes the
	memory copying of strings, each time a new string is made.
	Still, at only half as fast, it's doing well, given that the
	strings are 4 times the number of bytes. The Unicode version
	also outperforms the ZenVM, an earlier 8-bit virtual machine.