Skip to content

Commit

Permalink
Merge branch 'Dev'
Browse files Browse the repository at this point in the history
  • Loading branch information
rwxe committed Oct 1, 2023
2 parents f3151fd + fb8d4dc commit db49c96
Show file tree
Hide file tree
Showing 2 changed files with 9 additions and 5 deletions.
6 changes: 4 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -115,13 +115,15 @@ There's a good case to be made that a panic is an unidiomatic but proper respons

### Performance considerations

Compared with the integer type safety libraries of other languages (such as C++), this library uses some seemingly slow operations, such as division. But this does not mean that these methods will be slow, on the contrary, it will be faster than complex implementations in other languages. The reason is that Go does not allow forced inlining, and any complex functions will be abandoned for inlining, resulting in additional calling overhead. Short functions are lightning fast due to automatic inlining. For example, for unsigned 64-bit integer multiplication overflow detection, when inlining is disabled, division takes five times as long as long multiplication, but after automatic inlining is allowed, division takes 1/5 of long multiplication.
Compared to integer safe libraries in other languages (e.g. C++), this library uses some seemingly slow operations, such as division. But that doesn't mean these methods will be slow. In fact, because of Go's automatic inlining strategy for short functions and compiler optimizations, these operations are actually very fast in benchmark tests, lightning fast.

In addition, Go defines the overflow behavior of signed integers, making the detection of signed integer overflow simple and efficient.

Note that using `//go:noinline` in your business function will not affect the inlining of the library function. Only disabling global inlining through `-gcflags="-l"` will affect the inlining of this library function.

### Basis and dependencies

This library is based on Go's official compiler implementation and language specification, which defines the behavior when integer overflow occurs.
The library is developed based on Go's official compiler implementation (gc) and language specifications.

### License

Expand Down
8 changes: 5 additions & 3 deletions README.zh_CN.md
Original file line number Diff line number Diff line change
Expand Up @@ -102,7 +102,7 @@ func main() {
fmt.Println(overflow.Abs64(k2))
}
```
yields the output
输出
```go
9007199254740992 // Mantissa overflow, precision lost
9007199254740993
Expand All @@ -120,13 +120,15 @@ yields the output

### 性能考虑

与其他语言(例如C++)的整数类型安全库相比,该库使用了一些看似缓慢的操作,例如除法。 但这并不意味着这些方法会很慢,相反,它会比其他语言中的复杂实现更快。 原因是Go不允许强制内联,任何复杂的函数都会被抛弃内联,导致额外的调用开销。 而短函数由于自动内联将快如闪电。 例如,对于无符号64位整数乘法溢出检测,当禁用内联时,除法所需的时间是长乘法的5倍,但允许自动内联后,除法所需的时间是长乘法的1/5。
与其他语言(例如C++)的整数类型安全库相比,该库使用了一些看似缓慢的操作,例如除法。 但这并不意味着这些方法会很慢,实际上,因为Go为短函数自动内联的策略以及编译器优化,这些操作实际上在基准测试里非常快,快如闪电。

此外,Go定义了有符号整数的溢出行为,使得对于有符号整数溢出的检测简单而高效。

请注意,在业务函数中使用 `//go:noinline` 不会影响本库函数的内联。 只有通过 `-gcflags="-l"` 禁用全局内联才会影响该本库函数的内联。

### 基于和依赖

该库基于Go的官方编译器实现和语言规范,其定义了整数溢出发生时的行为
该库基于Go的官方编译器实现(gc)和语言规范开发

### 许可

Expand Down

0 comments on commit db49c96

Please sign in to comment.