purego: avoid reflect.MakeFunc in RegisterFunc fast path by tmc · Pull Request #441 · ebitengine/purego

tmc · 2026-03-18T10:21:15Z

What issue is this addressing?

What type of issue is this addressing?

feature

What this PR does | solves

RegisterFunc currently uses reflect.MakeFunc to build closures, which allocates per-call for argument packing. This PR detects common signatures (up to 15 integer/pointer/bool args, with optional float32/float64 args) and installs concrete typed closures that call the assembly trampoline directly — zero allocations on the hot path.

Scope:

Pure integer/pointer/bool signatures (1-15 args): zero-alloc concrete closures
Trailing float32 or float64 (e.g. func(int64, int64, float32)): zero-alloc concrete closures
Interleaved floats (e.g. func(int64, float32, int64)): reflect.MakeFunc wrapper that still avoids per-arg boxing
Non-Windows, amd64/arm64 only (Windows uses syscall.Syscall15 which takes a different path)
SyscallN and RoundTrip paths are unchanged

Results

Apple M4 Max, arm64, Go 1.24, benchstat -count=8 -benchtime=5s:

RegisterFunc calling C functions (direct call, no callback)

                   │  main ns/op  │  fast ns/op  │   delta    │ allocs old → new │
1 arg                   145          26            -82%         3 → 0
2 args                  167          26            -84%         4 → 0
3 args                  184          27            -86%         5 → 0
5 args                  226          29            -87%         7 → 0
10 args                 828          30            -96%        22 → 0
14 args                1735          53            -97%        40 → 0
15 args                1904          72            -96%        43 → 0

RegisterFunc calling C functions (with Go callback round-trip)

                   │  main ns/op  │  fast ns/op  │   delta    │ allocs old → new │
1 arg                   347         165            -52%         5 → 2
2 args                  527         206            -61%         7 → 3
3 args                  835         232            -72%         8 → 3
5 args                  707         270            -62%        10 → 3
10 args                1290         400            -69%        25 → 3
14 args                2215         508            -77%        43 → 3
15 args                2358         592            -75%        46 → 3

SyscallN / RoundTrip

No statistically significant change (expected — these paths are not modified).

Copilot

Pull request overview

This PR introduces a new “fast path” for RegisterFunc to avoid reflect.MakeFunc overhead for common ABI-compatible signatures, aiming to eliminate per-call allocations and significantly reduce call overhead on supported platforms.

Changes:

Adds signature detection in RegisterFunc to select a faster closure installation path for integer/pointer/bool args (and limited float cases).
Introduces a new fast_func.go implementation that installs concrete closures and uses a pooled syscall15Args + runtime_cgocall backend.
Expands the benchmark C fixture and adds tests validating correctness and (for key cases) zero allocations.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
`func.go`	Adds fast-path eligibility detection and dispatch to the new fast closure installers before falling back to `reflect.MakeFunc`.
`fast_func.go`	New implementation of fast-path closures and low-overhead call helpers.
`func_test.go`	Adds tests covering fast-path correctness, allocation behavior, and float/interleaved-float scenarios.
`testdata/benchmarktest/benchmark.c`	Adds C functions used by the new float/interleaved-float tests and benchmarks.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

tmc · 2026-03-19T03:53:43Z

+// SPDX-License-Identifier: Apache-2.0
+// SPDX-FileCopyrightText: 2026 The Ebitengine Authors
+
+//go:build darwin || freebsd || linux || netbsd || windows


Good point. Will tighten the build tag to exclude Windows since the fast path is runtime-gated to non-Windows anyway.

hajimehoshi · 2026-03-21T05:06:28Z

 package purego

 //go:generate go run wincallback.go
+//go:generate go run gen_fast_func.go


I prefer genfastfunc.go

Refactor emit functions in the code generator to use Go backtick (raw) string literals instead of line-by-line WriteString/Fprintf calls. This makes the generated code templates easier to read and maintain. The generated zz_fast_func.go output is byte-identical.

hajimehoshi · 2026-03-22T08:18:44Z

Hmm, would it be difficult to use text/template for code generations?

Replace fmt.Fprintf/WriteString code generation with text/template. Templates now look like the Go code they produce, making the generator much easier to review and maintain. The generated zz_fast_func.go output is byte-identical.

tmc · 2026-03-23T04:00:50Z

Adopted text/template -- open to any suggestions to improve readability/maintainability

hajimehoshi · 2026-03-23T10:34:06Z

The tests fail now

tmc · 2026-03-23T23:41:57Z

The tests fail now

fixed the gofmt issue

Use var declarations for zero-value variables in tryRegisterFastPath per reviewer preference (var numFloats int instead of numFloats := 0). Add gofmt -s -w as a go:generate step for safety.

hajimehoshi

LGTM, thanks!

@TotallyGamerJet PTAL

TotallyGamerJet · 2026-04-10T13:31:02Z

+	return *(*uintptr)(unsafe.Pointer(&buf[0]))
+}
+
+func flattenStructFields(v reflect.Value, buf []byte) {


Why isn't this just copy(buf, unsafe.Slice((*byte)(v.UnsafePointer()), v.Type().Size()))?

TotallyGamerJet · 2026-04-10T13:31:35Z

+func flattenStructToUintptr(v reflect.Value) uintptr {
+	var buf [8]byte
+	flattenStructFields(v, buf[:])
+	return *(*uintptr)(unsafe.Pointer(&buf[0]))


This definitely breaks unsafe rules. We can't return a pointer to a slice that may get GCd

TotallyGamerJet · 2026-04-10T13:38:32Z

I'm not sure I feel comfortable with this change. It's a lot of extremely dense code to parse and review. Even the generator code is difficult. If I can't review it I can't be confident there isn't parts of it that break unsafe rules. I believe I've already found one in my cursory review. I lean towards rejection.

hajimehoshi · 2026-04-10T18:35:56Z

Hmm, as this can be a maintainer burden, we should not go with this route. @tmc What do you think? Is this code complexity inevitable?

tmc · 2026-04-10T18:37:49Z

I'm.looking into that unsafe violation now.

I'm using (attempting to use) purego for some ML operations and need zero allocation paths to make performance viable.

Open to any ideas for how to make this achievable, this has been my best cut at it so far.

tmc · 2026-04-10T18:47:19Z

I'm not sure I feel comfortable with this change. It's a lot of extremely dense code to parse and review. Even the generator code is difficult. If I can't review it I can't be confident there isn't parts of it that break unsafe rules. I believe I've already found one in my cursory review. I lean towards rejection.

That’s fair. I found and am fixing a real liveness gap in one of the Reflect fallback paths while reviewing this, so I agree the PR is carrying too much unsafe/ABI surface to review comfortably as-is.

I’m going to reduce the scope and make the safety argument more explicit. In particular, I’ll keep the mechanically generated pieces aligned with focused tests, avoid unsafe byte-buffer casts in the struct path, and either remove pointer signatures from the forceFuncPtr fast path or document a tighter argument before asking you to review that part again.

tmc · 2026-04-20T20:12:23Z

I can work around this with a go:linkname kludge and may open a PR to expose a lower level api that is zero alloc (or just vendor or re-implement). Closing.

tmc force-pushed the fast-func branch from 0ed72df to 8ac4676 Compare March 18, 2026 10:42

hajimehoshi requested a review from Copilot March 19, 2026 02:45

Copilot AI reviewed Mar 19, 2026

View reviewed changes

hajimehoshi reviewed Mar 19, 2026

View reviewed changes

Comment thread func.go Outdated

tmc force-pushed the fast-func branch from 387bac2 to d484978 Compare March 20, 2026 22:10

hajimehoshi reviewed Mar 21, 2026

View reviewed changes

purego: add zero-allocation RegisterFunc fast path

6574853

tmc force-pushed the fast-func branch from d484978 to 6574853 Compare March 21, 2026 18:20

hajimehoshi reviewed Mar 21, 2026

View reviewed changes

Comment thread genfastfunc.go Outdated

genfastfunc: adopt text/template for code generation

ef3741b

Replace fmt.Fprintf/WriteString code generation with text/template. Templates now look like the Go code they produce, making the generator much easier to review and maintain. The generated zz_fast_func.go output is byte-identical.

genfastfunc: fix struct field alignment (gofmt)

5539b37

hajimehoshi reviewed Mar 24, 2026

View reviewed changes

Comment thread gen.go

Comment thread genfastfunc.go

Comment thread genfastfunc.go

Comment thread genfastfunc.go Outdated

Comment thread func.go

Comment thread func.go

tmc added 3 commits March 25, 2026 07:43

genfastfunc: address review feedback

bf540be

Use var declarations for zero-value variables in tryRegisterFastPath per reviewer preference (var numFloats int instead of numFloats := 0). Add gofmt -s -w as a go:generate step for safety.

flattenStructFields: handle Uintptr, Pointer, UnsafePointer kinds

7a625c3

fastCallIF: document that callers zero-initialize unused ints elements

fcf5319

hajimehoshi approved these changes Mar 25, 2026

View reviewed changes

TotallyGamerJet reviewed Apr 10, 2026

View reviewed changes

tmc closed this Apr 20, 2026

Conversation

tmc commented Mar 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What issue is this addressing?

What type of issue is this addressing?

What this PR does | solves

Results

RegisterFunc calling C functions (direct call, no callback)

RegisterFunc calling C functions (with Go callback round-trip)

SyscallN / RoundTrip

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

tmc Mar 19, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

hajimehoshi Mar 21, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hajimehoshi commented Mar 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tmc commented Mar 23, 2026

Uh oh!

hajimehoshi commented Mar 23, 2026

Uh oh!

tmc commented Mar 23, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

hajimehoshi left a comment

Choose a reason for hiding this comment

Uh oh!

TotallyGamerJet Apr 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TotallyGamerJet Apr 10, 2026

Choose a reason for hiding this comment

Uh oh!

TotallyGamerJet commented Apr 10, 2026

Uh oh!

hajimehoshi commented Apr 10, 2026

Uh oh!

tmc commented Apr 10, 2026

Uh oh!

tmc commented Apr 10, 2026

Uh oh!

tmc commented Apr 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tmc commented Mar 18, 2026 •

edited

Loading

hajimehoshi commented Mar 22, 2026 •

edited

Loading

TotallyGamerJet Apr 10, 2026 •

edited

Loading