actonlang
Path to a faster language
Order is a mix of low-hanging-fruit and large-impact. Like we expect witness inlining to be huge but #1493 is probably much easier yet with some decent results.
- #1493
- #1677
- #1045
- #145
- #1502
- #2403
- witness inlining
- use global witnesses for common types?
- placing objects on stack
- with escape analysis we can determine objects with a known lifetime
- and can place such objects on the stack instead of the heap, reducing GC / scanning etc
- arena allocations
- the stack is limited, so we cannot put everything on the stack
- an alternative is to have arenas
- based on same or similar escape analysis + some heuristics, temporary / working objects but with perhaps slightly longer lifetime than a stack frame can be placed in an arena
- arenas per actor? per continuation or longer?
- new GC
- not mark & sweep across whole stack - generational
- per Actor
@nordlander @sydow I would appreciate your input here. I made a list but maybe it's just entirely wrong. Feel free to make adjustments or just comment on how you see things. What have I missed? Is the order wrong?
I think that your list is a good start. Witness inlining certainly deserves a place at the top. We do already use global static wtnesses for most builtin types. The exceptions are for situations where we have constraints on type parameters, so we cannot use global witnesses; the canonical example is dicts (or sets) where the key type must be Hashable. But we could certainly do better than we do today, so this is a good thing to start work on now. I have started to look into it a little.
Memory allocation is also important, and our current GC has some problems, but here I have nothing to add to the discussion Kristian and Johan had the other day in a related issue.
I would add sorting out how best to do subtyping for the various integer types so that we can get faster and still convenient range iteration, indexing, slicing etc. This also a necessary precondition for progress with unboxed values. We should also review types in builtin; e.g. hash values should probably be u64 and not int; the same for values of the len function etc. This is part of a general policy to get programmers to use type int less often.
Less important is to get comprehensions working, but maybe it deserves a place on this list.
