为什么我用 go 写的 sha-1，计算没有 git 的快速 sha-1

[pdxjun]

我计算大概 1 个 g 的文件要 30-40 秒，但是 git 只需要 1-2 秒，有老哥们知道 git 是怎么计算的吗

最终发现是我写的有问题，小文件太多了，没有处理好，不过我优化了一下，现在已经快多了，不过还是没有 git 的快。。。，但是也能接受了

[liuidetmks]

git 有硬件加速吧

[danbai]

试试这个 https://github.com/minio/sha256-simd

[clino]

我用 sha1sum 算一个 1.4G 的花的时间是 5 秒，其实我理解相当多时间是在等磁盘读取
你这个 30-40 秒估计很有优化空间

[shimanooo]

路过问一下现代文件系统有没有文件 hash 的接口? 只使用少量 IO 就能获得文件 hash.

[1423]

显然是你自己不会用
1 个 g 的文件要 30-40 秒, 开什么玩笑

[sardina]

阁下为何不 show code 呢

[zhy0216]

看到这个 https://github.com/avaneev/komihash

[Trim21]

试了一下 go 也只需要 1-2 秒。你贴一下你的 go 代码。

[AoEiuV020JP]

这种常见的劣化方案就是大量申请的临时空间，临时变量用完就丢，一直在申请和释放内存就慢，

[ShuWei]

go 不是很擅长并发么，现代多核处理器加 ssd 的组合，不至于这么慢吧，1g 左右的文件大小，1-3s 属于比较正常的范畴，检查下缓冲区跟异步并发这两块？

[kneo]

不会是你自己实现的吧？如果你不懂任何优化，至少照着算法山寨一个，30s 很正常。

[kneo]

@kneo 不知道怎么修改回复……“至少”=>“只是”。

[nlzy]

你写的程序有问题，SHA-1 在现代 CPU 上不用硬件加速也能跑几百兆每秒，git 算 SHA-1 的性能完全就是合理水平。

既然你是 go 用户，那为什么不看看 go 标准库里的实现呢？手写的汇编，广泛验证的质量，详实的注释，连参考文章都列的清清楚楚。完全值得一看。

[flyqie]

show your go code

[qwerthhusn]

现代 CPU 支持 CPU 指令直接计算 sha ，不过即使软解也没那么慢，你代码问题
https://en.m.wikipedia.org/wiki/Intel_SHA_extensions

[sadfQED2]

代码发出来看看

[lasuar]

代码啊代码

[julyclyde]

@ShuWei 这东西咋并发？

[lysS]

@julyclyde sha 应该不可以，如果是 crc 支持 update ，就可以用并行

[julyclyde]

@lysS “sha 不可以”和我理解的一样，hash 类的计算都有前后依赖

不过 crc 这个我没听懂。主要是我也不懂 crc ，所以缺乏理解你这句话的基础知识

[lysS]

@julyclyde


package main

import (
"fmt"
"hash/crc64"
"sync"
)

func main() {

var data = []byte{
1, 2, 3, 4, 5, 6, 7, 8,
1, 2, 3, 4, 5, 6, 7, 8,
1, 2, 3, 4, 5, 6, 7, 8,
}

iso := crc64.MakeTable(crc64.ISO)

{
r := crc64.Checksum(data, iso)
fmt.Println(r)
}

{ // concurrent
crc := crc64.New(iso)
wg := &sync.WaitGroup{}
wg.Add(3)

go func() {
crc.Write(data[16:24])
wg.Done()
}()

go func() {
crc.Write(data[0:8])
wg.Done()
}()

go func() {
crc.Write(data[8:16])
wg.Done()
}()

wg.Wait()
fmt.Println(crc.Sum64())
}
}