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

proposal: Add functions to convert between uints and byte arrays #39078

Closed
geraldss opened this issue May 14, 2020 · 7 comments
Closed

proposal: Add functions to convert between uints and byte arrays #39078

geraldss opened this issue May 14, 2020 · 7 comments
Labels
Milestone

Comments

@geraldss
Copy link

@geraldss geraldss commented May 14, 2020

I propose adding functions to convert between uints and byte arrays of the same size. At a minimum, two new functions to convert between uint64 and [8]byte. For symmetry, there can be functions to convert between uint32 and [4]byte, and between uint16 and [2]byte. These functions would go into math/bits.

func Uint64ToBytes(x uint64) [8]byte
func BytesToUint64(x [8]byte) uint64

or

func Uint64ToArray(x uint64) [8]byte
func ArrayToUint64(x [8]byte) uint64

The implementation can be inlined and compiled down to a single word copy. It is essentially a type cast.

@gopherbot gopherbot added this to the Proposal milestone May 14, 2020
@gopherbot gopherbot added the Proposal label May 14, 2020
@randall77
Copy link
Contributor

@randall77 randall77 commented May 14, 2020

We already have functions very much like this in encoding/binary.

@geraldss
Copy link
Author

@geraldss geraldss commented May 14, 2020

The functions in encoding/binary are more expensive than these.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 14, 2020

Using encoding/binary forces you to specify the desired endianness, which seems desirable.

Using native host endianness is a path to trouble in the long run. I don't think we should encourage it.

@geraldss
Copy link
Author

@geraldss geraldss commented May 14, 2020

Fair point. Can we add functions that avoid slicing, even when specifying endianness? Slicing introduces overhead when the goal is to convert a single word.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 14, 2020

Are the encoding/binary functions inlinable? If they are, the slicing costs should disappear in practice.

Do you have a benchmark comparing your suggested functions and the encoding/binary functions?

@randall77
Copy link
Contributor

@randall77 randall77 commented May 14, 2020

If encoding/binary is too expensive, we should optimize it, not jump immediately to adding new API. That starts with a benchmark demonstrating the problem.

This code:

func f(x [8]byte) uint64 {
     return binary.LittleEndian.Uint64(x[:])
}

already compiles to just 2 instructions (2 MOVQ, from the input stack slot to a register, and from the register to the output stack slot).

@geraldss
Copy link
Author

@geraldss geraldss commented May 14, 2020

Ok, thanks. Given that the encoding/binary functions are being inlined, please feel free to close this, or lmk and I'll close it.

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

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.