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

Potential optimizations #70

Open
o-jasper opened this issue Mar 11, 2015 · 1 comment
Open

Potential optimizations #70

o-jasper opened this issue Mar 11, 2015 · 1 comment

Comments

@o-jasper
Copy link
Contributor

Compiler macros are general functions that apply on an expression first, and return nothing if they do not apply, or the resulting expression.

A lot can already be achieved with the replacement rules already, of course.

Find-the-function.

Perhaps instead of having a lot of (when (eq (ge '__funid) ...) you can see if (lt (ge '__funid ...) < ) and go through branches of the Tree. Is log2(N) instead of N, no disadvantage that i see.

I think it is probably best if LLL has a (case ...) and then you make case figure it out.

unless (iszero..)

What's wrong with when?

Orring:

As observed.(whitespace altered)

(with '_temp_10201 (slt (get 'i) 1) 
    (if (get '_temp_10201) 
        (get '_temp_10201) 
        (sgt (get 'i) (sload 5))))

This might be fine for a value-or, returning the first non-false value. But if the value is just used as a boolean, should use the bitwise or. For simpler cases compiler macros can recognize it.

Memory values

Mark variables that the compiler makes and you know wont change.(For instance in the above or case.)

When can variables be substituted with their expressions?

  1. Variable is never set before that.
  2. Expressions are constant. (no call, mload, sload(AFAIK) although you might be able to check whether the latter two matter in this case)
  3. Expressions do not make changes. (no call, sstore, mstore(AFAIK))

If you know when substituting is allowed, choosing whether to do it is figuring out what is more efficient.

I think i.e. (calldataload ..constant..), (number), (timestamp), constant all qualify if the variable is not changed. This might already help a lot!

More complicatedly, could estimate the gas cost. Either for contract creation or when running the code. (can 'settings' wrt optimization at branch in the AST-tree. I.e (optimize-for-run and (optimize-for-codelen?) Or (optimization-ratio r, i.e. saving r running gas is worth 1 creation-gas.

Arrays

Not sure.. If there is just one array with no particular length you can just use (+ (* itemsz i) last_index) instead of going the sha3 route?

Or do low indexes cause pain? ("continuous area?") Another argument against is that it makes where-things-are-stored less predictable. (dont think that is very important tho)

Powers of two

That is 2224 ... Probably better to denote that way?

(with '__funid 
    (div (calldataload 0)
        26959946667150639794667015087019630673637144422540572481103610249216)
    ....

Right EXP is not expensive. Could be cheaper though, if there was a EXP2

@vbuterin
Copy link
Contributor

Thanks a lot for this!

unless (iszero..)

What's wrong with when?

When ultimately has to compile into unless(iszero(...)...) anyway (at
least, to preserve the norm that outputted EVM code has clauses in the same
order as incoming serpent code, which I really like; otherwise, of course,
we could transform unless(x, a, b) into when(x, b, a)). But that can
certainly be done at the LLL-to-EVM level.

Not sure.. If there is just one array with no particular length you can
just use (+ (* itemsz i) last_index) instead of going the sha3 route?

Yeah, that would work.

That is 2224 ... Probably better to denote that way?

Yeah, the math optimizer can definitely be fine-tuned more to exclude those
kinds of situations.

Find-the-function.

Sure, that's a good idea, it can probably be made log(n)

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

No branches or pull requests

2 participants