8000 Contracting 2 Ideas · Issue #278 · Lamden/contracting · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Contracting 2 Ideas #278

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.

Sign up for GitHub

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

Jump to bottom
Open
StuartFarmer opened this issue Feb 6, 2020 · 2 comments
Open

Contracting 2 Ideas #278

StuartFarmer opened this issue Feb 6, 2020 · 2 comments

Comments

@StuartFarmer
Copy link
Contributor

There are several ideas to work towards after mainnet and V1 on Contracting. The biggest issue I see is with Contracting is that it is slow, as Python is just slow in general. Yes, we have multiprocessing, but Python is still extremely slow in general and we might not be taking advantage of conflict resolution because of this.

However, because it's in Python, we can add infinite extensions via Python and it will take a few hours versus several weeks. This is the tradeoff.

  1. How important is speed?
    Do we even have any benchmarks of the network usage? Are users feeling that the network is bogged down? How many transactions are generally in the queue of a masternode? Etc.

  2. How important is feature development speed?
    Are people going to want new features ASAP?
@StuartFarmer
Copy link
Contributor Author

Another option would be to introduce a new programming language. This is probably not ideal.

However, for brainstorming purposes, let's assume it is...

LuaJIT is a variant of Lua that has Just-In-Time compilation of the Lua bytecode. It's similar to the PyPy project for Python. Using PyPy for speedups is also an option here, but I'm going to just talk about LuaJIT for illustration purposes.

Lua vs Python in benchmarks can be seen here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/lua-python3.html

A total breakdown of speeds across all languages can be seen here: https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html

Lua and Python are pretty close to each other, so we can call them 'equivalent.'

LuaJIT vs Lua in benchmarks can be seen here: https://luajit.org/performance_x86.html

Let's assume the numbers are roughly accurate across the spectrum of smart contracts. This would mean that we could get smart contracts running ~27.19x faster per core. Nice!

Problems with this:

  • Interfacing with state would require special plugins.
  • Python is much more popular than Lua
  • Plugins might be harder

Solutions:

  • Use PyPy instead

@StuartFarmer
Copy link
Contributor Author

More problems:

  • Rewritting the metering functionalities might require core changes to the LuaJIT codebase.
  • C programmers are harder to come by and C programming has much higher room for error and is much slower to do.

More solutions:

  • PyPy again??

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@StuartFarmer
0