heiyeluren / xmm Goto Github PK

请给我一个我会引入这个库的一个具体理由。

• 是否有对比实验证明这个库在某种tradeoff的情况下比golang自带的好？好多少？我自己是否可以在我的机器上运行这类对比实验？

• 看描述似乎这个库本身也带一个gc功能。那么在与官方golang的gc做的事情一样的情况下如何还能比官方golang的gc还好，就值得怀疑。

• 另外 单机（6 核心 KVM 或物理机）内存分配性能达到 350w+ alloc/s；（每秒内存分配速度）； 好像官方的golang的分配速度也是这个水平上（没有具体的机器谈具体的性能算扯淡哈），那边必然是在其他方面有优化，比如没有 gc 对吞吐量的延时影响？具体优化了啥？文档上没讲。

我目前才刚接触xmm，还不清楚不支持windows是什么意思，是指以下哪种情况呢？

1. 无加速效果但可正常运行
2. 编译不通过
3. 接入后在windows下无法运行

我的程序会在linux上跑，但我是在windows下开发的

https://github.com/heiyeluren/XMM/blob/9cfb6823ead7fe2868fe35bb10598313f63db80f/src/xmm.go#L65-L68
会考虑支持空结构体的内存分配吗？类似 go 官方给个 zerobase
https://github.com/golang/go/blob/badbc52d82b1f97861bf30457014fc9ea19dfcb2/src/runtime/malloc.go#L909-L916

package main

import (
"log"
"sync"
"unsafe"

"github.com/heiyeluren/xmm"

)

func main() {
print("Start\n")

f := xmm.Factory{}
m, err := f.CreateMemory(0.6)
if err != nil {
	panic(err)
}

lock := sync.Mutex{}

wg := sync.WaitGroup{}
for i := 0; i < 2; i++ {
	wg.Add(1)

	go func() {
		defer wg.Done()

		for i := 1; i <= 1024; i++ {
			lock.Lock()
			addr, err := m.Alloc(uintptr(i * 4096))
			lock.Unlock()

			if err != nil {
				log.Fatalf("%s", err)
			}

			s := (*[1024 * 4096]byte)(addr)[:uintptr(i*4096):uintptr(i*4096)]

			for idx := range s {
				s[idx] = 255
			}

			lock.Lock()
			err = m.Free(uintptr(unsafe.Pointer(&s[0])))
			lock.Unlock()

			if err != nil {
				panic(err)
			}
		}
	}()
}

wg.Wait()

}

如题

项目看起来很酷，但是在阅读完README之后并没有看到关于「取舍」、「适用场景」及 「不适用场景」 的描述。

一些比较好奇的点：

1. 请问有不同情景下（对象大小、堆使用量etc）的benchmark吗？
2. XMM的GC性能与go自带GC的比较？GC的频率以及单次GC耗时？
3. “在面对成千上万的小对象场景中，不会因为 Go 本身 GC 机制带来任何的抖动” -- XMM的GC带来的抖动呢？如果是手工free的话，手工free部分的开销是多少？
4. “不会内存泄露，并且内存管理不是粗糙的，而颗粒度细致的，完全尽量可媲美行业主流的内存管理分配器。” -- 有数据支撑吗？
5. 大对象/小对象/大小混合对象下的内存占用overhead是多少？对比go？

总结起来是：单从性能的角度，忽略额外的编码复杂度来讲：何时使用XMM而不使用go自带内存管理？更重要的是，何时使用go自带的内存管理而不使用XMM？

建议直接将src下面的源码，拿到项目根目录下，这样包的导入路径最后一个分段与module名/包名一致。

另外go.mod中module path改为github.com/heiyeluren/xmm，方便用户go get。

1. 如果项目中GC频率较低，或者说运行时golang的GC对项目不会产生任何抖动，是否也没太大必要使用XMM这个项目来手动管理内存？
2. 这个项目是否主要适用于小对象过多造成的频繁GC导致cpu抖动这种场景，这种场景下手动管理就可以避免这种情况了？
3. 比如说，像一个长期使用的sync.Pool，是否使用XMM管理就比较合适？

package main

import (
"sync"
"unsafe"

"github.com/heiyeluren/xmm"

)

func main() {
print("Start\n")

f := xmm.Factory{}
m, err := f.CreateMemory(0.6)
if err != nil {
	panic(err)
}

wg := sync.WaitGroup{}
for i := 0; i < 4; i++ {
	wg.Add(1)

	go func() {
		defer wg.Done()

		addr, err := m.Alloc(65535)
		if err != nil {
			panic(err)
		}

		s := (*[65535]byte)(addr)[:65535:65535]

		s[0] = 1

		err = m.Free(uintptr(unsafe.Pointer(&s[0])))
		if err != nil {
			panic(err)
		}
	}()
}

wg.Wait()

}

Using xmm in the package name will cause abnormal installation of dependencies, it should be updated to github.com/heiyeluren/xmm

the error is as follows:

$ go mod vendor
go: finding module for package github.com/heiyeluren/xmm/src
go: found github.com/heiyeluren/xmm/src in github.com/heiyeluren/xmm v0.1.1
go: xmm/example imports
        github.com/heiyeluren/xmm/src: github.com/heiyeluren/[email protected]: parsing go.mod:
        module declares its path as: xmm
                but was required as: github.com/heiyeluren/xmm