On 05/01/2013 1:37 PM, Patrick Walton wrote:
> First off, I do not see any way we can improve *general* compiler
> performance by an order of magnitude.
I don't feel this sort of quantitative statement can be made, from where
we are now. When I say "I expect we should be able to get it an order of
magnitude faster" I'm just talking comparatively, against codebases of
similar size/complexity in similar-abstraction-level languages, it
builds too slowly and produces artifacts that are too big.
The landscape of possible changes is IMO too complex to judge the
particulars in quantitative terms yet. And I'm not going to address the
abstract arguments about upper bounds of speed; in particular, thingsl
ike "we can't typecheck the way $LANGUAGE does" in a big-O sense is just
not the level I want to be looking at the problem. I'm mostly concerned
about residual systemic taxes / technical debt:
- Non-use of arenas and &, pervasively
- Allocating and freeing effectively constant data we don't properly
constify. Note: _no_ expression-level constant folding happens
presently outside of const item initializers.
- Tag discriminant values loaded from memory (!)
- Implicit copying
- Inefficient representations: as you point out, our memory manager
probably uses 2x-3x more memory than it needs to, especially for
small allocations
- Allocator locking, fragmentation, general non-optimality
- Refcounting traffic
- Stack growth and task lifecycle stuff that may be optional or
obsolete
- Landing pads
- Cleanup duplication in _any_ scope-exit scenario
- Redundant basic blocks
- The match code translation, which (in our own admission) nobody is
comfortable enough with to hack on presently
- Glue code (not just visitor; we still generate drop and free)
- Falling off fastisel
- Not annotating functions correctly
(noalias/nocapture/nounwind/readonly/readnone/optsize)
- Metadata encoding, organization, I/O paths
- Use of dynamic closures rather than traits and/or vtables, &Objects
- Wrong inline settings in libs (we don't capture or measure this)
- Wrong monomorphization settings (likewise; count copies of vec::foo
in any resulting binary)
- Non-optimality / taxes of:
- fmt!
- assert and fail
- bounds checks
- / and % checks, idiv on []
That's just off the top of my head. My general rule with perf work is
that you don't even discover the worst of it until you're knee deep in
solving "curious unexplained parts" of such problems. Given how many of
the items on that list have direct consequences in terms of how much
code we throw at LLVM, I'm not confident saying anything is "optimal" or
"not able to be improved" yet.
All I see are lots of areas of performance-related technical debt
juxtaposed with too-big binaries and too-slow compiles. I'm not doing
any arithmetic beyond that.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
