Skip to content

Fast Array Initialization #1890

Open
Open

Description

@dmbarbour

What Bend should do

Bend should initialize arrays faster, or enable users to discharge to a proof of initialization before access.

Why

I'm currently modeling a language runtime in Bend, using arrays to model stacks/continuations. Array initialization and resizing (to double size) is currently running about 8 instructions per word, or about 15% of my current benchmark loads.

Array initialization should not be the performance bottleneck.

Activity

  1. raramos9 commented on Oct 28, 2026

    @raramos9
    Contributor

    Hello i'd like to take this on. I'll start by investigating the current array initialization implementation and benchmarking the overhead to identify potential optimizations.

  2. raramos9 commented on Oct 28, 2026

    @raramos9
    Contributor

    I investigated this on an Apple M1 using the C backend and found a potential optimization opportunity in blk_new.

    A standalone Array.new(U32, 24n, value) is already efficient (~0.27 instructions/cell), but repeatedly doubling an array through ANode{a, Array.new(...)} costs ~5.76 instructions/cell of the final array.

    Looking at the generated assembly, the inlined blk_new initialization loop remains scalar (~5 instructions per U32 cell), while the subsequent blk_fill copies are vectorized.

    The relevant code appears to be in bend2/comp.ts, around lines 4354–4372.

    I'm planning to investigate whether simplifying the fill loop (particularly the index conversion and modulo operations) allows the compiler to vectorize it in the growth case.

    I'll benchmark the change against the current implementation and run the existing correctness tests.

  3. YidaWeng commented on Oct 29, 2026

    @YidaWeng
    Contributor

    Following up on the multi-field case left open in #1928.

    I'd like to take the next slice of #1890: reshape blk_new's fill for lgs >= 1 so clang can vectorize growth of multi-word elements (the Array<Pt> / two-U32-field case from #1928's benches, which stayed ~13–15 instr/cell after the trip-count fix).

    Plan:

    @raramos9 — if you're already working that follow-on, say so and I'll stand down or help on a different slice. Otherwise I'll claim this piece and report back with numbers.

  4. raramos9 commented on Oct 29, 2026

    @raramos9
    Contributor

    Thanks for picking this up @YidaWeng ! I saw you already have #1938 in draft so feel free to continue with the follow-up. Happy to help review or benchmark it once it's ready!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions