mu-impl-fast issueshttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues2017-11-21T13:37:05+11:00https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/38Allocation Performance2017-11-21T13:37:05+11:00John ZhangAllocation Performance## Description
Measured allocation performance using following code with `n=10`:
```python
class A:
pass
def alloc(n):
for i in range(n):
a = A()
def target(driver, args):
...
def main(argv):
...
...## Description
Measured allocation performance using following code with `n=10`:
```python
class A:
pass
def alloc(n):
for i in range(n):
a = A()
def target(driver, args):
...
def main(argv):
...
for i in range(iterations):
cb.begin()
for j in range(1000000):
alloc(n)
cb.end()
cb.report(resfile)
return 0
```
Mean of measured results:
| stack | result|
| ----- | ----- |
| RPython Mu Zebu | 0.00072474 |
| RPython C `clang -O0` | 0.00432998 |
| RPython C `clang -O1` | 0.0000008 |https://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/47Trace scheduling2017-09-12T16:32:51+10:00Yi LinTrace schedulingIn fib performance test `python3 -m mubench local ./example/test_mu_fib.yml`, code generated by Zebu is significantly slower than clang. The main reason seems to be that we are generating awful trace for the code, which causes 3 extra ju...In fib performance test `python3 -m mubench local ./example/test_mu_fib.yml`, code generated by Zebu is significantly slower than clang. The main reason seems to be that we are generating awful trace for the code, which causes 3 extra jumps(unconditional or conditional).
[fib-zebu.s](/uploads/7c4e865b48b98ce298c7d65609763241/fib-zebu.s)[fib-c_O1.s](/uploads/3582548c5971039e669ffa73014a74a6/fib-c_O1.s)
Currently Zebu generates basic block trace based on probability. When the branching probability is 50% (by default), it pretty randomly picks blocks. We should have a pass with certain heuristics to generate trace.Yi LinYi Linhttps://gitlab.anu.edu.au/mu/mu-impl-fast/-/issues/39Reduce serialised vm size (large bootimage size)2017-07-12T10:49:35+10:00Yi LinReduce serialised vm size (large bootimage size)For RPySOM interpreter, the boot image (executable) generated by Zebu is 175mb while the executable from the C backend is less than 1 mb. The main reason is that the Zebu's boot image contains a serialised vm (via Rust's serialisation),...For RPySOM interpreter, the boot image (executable) generated by Zebu is 175mb while the executable from the C backend is less than 1 mb. The main reason is that the Zebu's boot image contains a serialised vm (via Rust's serialisation), and I wasn't careful about what should be serialised so that basically everything is included. The serialised VM probably contribute to 99% of the boot image size.
I estimate if I am being careful about what should be serialised (only what will be used at runtime is worth serialising. #18 is part of the issue), the size can be reduced by at least 5-10 times.
And I am not sure how much this may contribute to the big performance slowdown.Yi LinYi Lin