Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tracer.get_var_name returns None instead of default on pypy3 #141

Closed
programmerjake opened this issue Jul 9, 2019 · 3 comments · Fixed by #142
Closed

tracer.get_var_name returns None instead of default on pypy3 #141

programmerjake opened this issue Jul 9, 2019 · 3 comments · Fixed by #142
Labels
Milestone

Comments

@programmerjake
Copy link
Contributor

on pypy3 (pypy 7.2.0-beta0),
tracer.get_var_name returns None when called through Signal.__init__ as follows:

from nmigen import Signal
v = Signal(reset_less=False)
print(v.name)

instead of returning None, it would be better to return default or raise an exception.

having None as the name causes Simulator to crash.

@whitequark
Copy link
Contributor

whitequark commented Jul 9, 2019

I don't think that's the right solution because this way, with PyPy, you cannot generate meaningful Verilog at all. You'd think simulation would be much faster on PyPy, but I've evaluated it in the past (with a workaround for this issue), and it is significantly slower than on CPython.

Since PyPy's bytecode is quite similar to CPython's, the right solution here is to not hack around it but to implement proper support for PyPy bytecode. Because of its slowness I do not think it currently makes any sense to put effort into it, but if you are interested in PyPy I would accept a patch that does that and add it to Travis' build matrix.

programmerjake added a commit to programmerjake/nmigen that referenced this issue Jul 9, 2019
whitequark pushed a commit that referenced this issue Jul 9, 2019
@whitequark whitequark added this to the 0.1 milestone Jul 10, 2019
@programmerjake
Copy link
Contributor Author

You'd think simulation would be much faster on PyPy, but I've evaluated it in the past (with a workaround for this issue), and it is significantly slower than on CPython.

I've found pypy to be much slower at elaborating but much faster at simulation. As an example, running test_core.py in ieee754fpu, which tests part of a div/rem/fdiv/fsqrt/frsqrt pipeline, it takes about 930s using pypy3 (7.2.0-beta0) and 1370s using python3 (3.6.8) on my Ryzen 2600. It tests about 140k simulated clock cycles.

@whitequark
Copy link
Contributor

Interesting. I think the reason here is that the workloads are different. IIRC I benchmarked simulation on small cores, where it might be that the tracing JIT doesn't work as well.

Anyway, that's good to know. In light of this information I think it is worthwhile to support PyPy as a first-class runtime.

Sorry, something went wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants