TEXT 36

results-vm

Guest on 26th July 2022 01:01:21 AM

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.

Raw Paste

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.

Login or Register to edit or fork this paste. It's free.