@Nazz
在你的 github 这个代码中，BufferReset2 虽然用了 unsafe 但是操作的都是 Buffer 结构体内定义的字段，没有越界访问或对未初始化内存的操作，所以现在没有安全上的问题。
BufferReset2 中，更改了 buf 、off 和 lastRead 字段，在 BufferReset1 中仅更改了 off 字段。可能是更多字段引起额外的内存分配导致的。

@Nazz
Go 语言中的结构体是将 Field 按照声明的顺序进行内存布局。
如果没有使用 unsafe.Offsetof 之类的方法，unsafe.Pointer 获取到的地址就是该结构体的首地址。
结构体的首地址就是其第一个字段的地址，等同于访问该结构体的第一个字段。

BufferReset2 不仅重置了 buf 和 off ，还重置了 lastRead 。

```
package main

import (
"fmt"
"unsafe"
)

type MyData struct {
length int
data int
}

func main() {
data := MyData{
length: 5,
data: 100,
}

fmt.Println("Before:", data)

// 获取 MyData 结构体的地址，并转换为通用指针
ptr := unsafe.Pointer(&data)

// 模拟不加偏移量的修改操作
*(*int)(ptr) = 200

fmt.Println("After:", data)
}
```

如果你错误地修改了结构体的私有字段，可能会导致数据状态的不一致。例如，可能会影响缓冲区（ buffer ）的长度和容量，使其不匹配。

bytes.Buffer 的实现在未来版本中发生变化也会出现问题。

@shunia
你说得对，恶劣这个词现在来看确实用的不妥，但我不明白这和应润尽润之间有什么逻辑关联；
另外关于你认为的有价值的回复，这一点我持保留意见，也不是面向产品与开发者的。

这个帖子的回复楼层，十分贴切的展示的国内开源环境的恶劣。
开源项目，代码和订阅地址都开源了，对代码不放心可以自己 Code review ，对编译不放心可以自己编译；
觉得订阅源不好可以自己部署一个订阅源。

flush 操作会给 ES 集群带来压力，尤其是在高并发的情况下。
可以引入一个缓存层（如 Redis ），缓存部分高频查询的结果。

有没有一种可能，这些问题可以直接在 V2EX 上面聊

@xiaocaiji111
你是懂多进程的

@letitbesqzr
这个现在有公开的代码地址了吗？

@elonmask
哦明白了，是我误解了，不过和你想的不太一样，我们没有使用完整的 CLIP ，只是使用 CLIP 的 embedding 部分。
包括文字搜索，也只是使用到输出 CLS Token 部分。

CLIP Base 做到 200M 甚至 100M 完全是有可能的。

目前与仅使用 CLIP 落地的项目还是不太一样的。
当然这并不是说我们不能做离线私有化部署，正如上面我对其人的回复中，优先做一个单机的的落地版本我占时还不清楚能够帮助到哪些人。如果在这方面你有更好的建议我们可以深入探讨。

「当我的车速超过 100 公里 /小时」
当你车速低于 100 公里 /小时前在哪个车道？
是否有规范使用超车道、行车道？

「前车太慢而且允许超车的情况，我也会超车，并且超车后重新保持车距。」
按你 100 米以上的安全距离，是超车后在拥有前后车都会保持 100 米的车距间隙才会插入吗？
如果只满足前车间隙 100 米，你期望后车自行刹车保持车距间隙吗？

「对于我来说，安全>速度。」
在超车道低于 100 公里 /小时真的安全吗？
如果你超车不满足第二条，那你的超车行为在你的标准中是否给其它人造成安全隐患？

「其实跟哪条道是没关系的」
高速上大车的最高时速和车道要求和家用乘用车是不一样的，而且很多人不喜欢大车在自己车道的前方和后方。

@melovto
应该是此问题，但是又不太准确，下午测试是在 MBP 15 Retina 屏幕上进行的，在 Windows 的 100%屏幕渲染下依旧有此问题，这可能涉及到了多倍屏渲染的问题。


另外刚才我还发现一个问题，在 Demo https://vue-skia.netlify.app/ 中，圆角矩形的线条处，直线的像素与弧线的像素的显示上似乎存在的一些区别。这个问题在 MacOS 与 Windows 上都存在。
对于圆角矩形有以下该问题：
1 、直线似乎并不是一根完整的 1px 宽度，而是两个带有透明通道的 1px 像素；（ round-rect 和 line 不一样的是 line 是 2px 的不透明线条）
2 、round-rect 弧形线处的渲染结果和直线处的方法不一样，弧形处的为正常的 1px 。

针对这个问题我进行了搜索找到以下内容：
https://www.jianshu.com/p/c71aa4debba8

因为我不会相关方面的代码，但是结合表现情况下来，可能为相同的问题；但是文中的解决方案可能存在潜在的风险并且会增加代码的复杂度，例如需要处理移动的单位时，所以对单位进行放大和缩小时，对于坐标对齐的问题会有麻烦。

@elonmask
追求的不是 paper 是工业化落地

项目没有针对屏幕进行像素点对点渲染优化吗？
而且 1 像素的 line 并不是 1 像素；
<v-surface :width="360" :height="360">
<v-line :strokeWidth="1" color="black" :p1="[100, 260]" :p2="[50, 260]" />
<v-line :strokeWidth="1" color="black" :p1="[100, 262]" :p2="[50, 262]" />
</v-surface>

@qztx
在储存的压力上，未必要保持原图，需要记录的是这张图的特征；
但也这意味着这套模式下需要得到这张图，所以只能针对特定的资源数据进行处理；
是可以做到本地化部署的，在无加速设备上是模型数据处理录入处理速度快慢的区别，在搜索上 Faiss 的性能还不错。

这几天我问过一些从事剪辑师的朋友，这个产品的特性确实能帮助到他们，但是对于他们目前的工作流来说也有一些侵入，如果想要推广到团队中需要进行一些调整。

对于画师的朋友，目前存在这么一个困境，本地的储存的资源真的比 pixiv 更丰富吗？如果我基于 pixiv 作为数据库，为每个用户提供自定义 tag 的功能，是否可以提供更好的图片搜索。在搜索完成后下一步再提供图片的链接。

这里我总结一下，用户的需求分为两种：
1 、期望根据手头上的信息，找到该信息的出处的精准信息，并且提供该信息的站外搜索或者直达链接。
2 、根据想要信息的描述，找到多个符合该信息特征的相关信息。

@bqn
是的，功能上与这些产品并没有太大的区别，只是在精度上取得了进展

@elonmask
在边缘设备上运行 CLIP 目前还是有很大的挑战，能跑在无加速器的 NAS 上已经很勉强了。