干货 | 理解 ProgPoW 算法

Ajian   |     |   879 次阅读

1.png

概述

ProgPoW——是 Programmatic Proof-of-Work 的缩写(口头上习惯称之为 ProgPoW 或者 ProgyPoW,Prog 来源于电影《星球大战七:最后的绝地武士》中的角色形象),是一种 Ethash 算法经过 GPU 调试后的扩展,可以缩小特定功能的硬件之间的效率差。

作为一篇设计文章,本文介绍了常见 GPU 的技术规格和性能指标,但无理论依据或辩护。我们鼓励每一个币种自行研究 ProgPoW 是否适合其网络。

设计

“我们通常认为,POW 挖矿存在一个固定的算法,可以设计硬件适应它,让其在执行算法的时候变得有效。在 ProgPoW 中,情况是相反的,我们先有硬件,然后修改算法来匹配它。”

对于硬件来说,一个有效的算法需要匹配访问模式与足够的硬盘空间。这就是为什么 AMD GPU 通过修改固件后可以大量提升挖 ETH 的表现。因为内存芯片的访问模式和Ethash的访问模式相同。

Ethash,即 Ethereum 使用的 PoW 算法,是一个内存密集型(memory-hard)的工作量证明算法,在商用 GPU 上可以很好地运行。Ethash 需要相当大的帧缓存(framebuffer,目前为 2.5GB)和越大越好的带宽,这些要求在商用 GPU 上都得到了满足。然而,这两者就是 Ethash 需要的全部要求了,并且在被配置进ETH挖矿软件时会变得更加明显。

2.png

- GTX1070执行Ethash的表现——图片源自NSight Profiler -

流式多处理器,SM(streaming multiprocessor, NVIDIA 显卡的计算核心,可并行地创建,管理,编排和执行来自多线程的指令)占据了 GPU 的大多数的模片区(die area),但只有 30% 不到的使用率。

即使在 CodeXL 上没有很多详细信息,但可以看到类似的表现。向量算术逻辑单元,(Vector ALUs,arithmetic logic units 是执行算术和按位运算的数字电路)也以不到30%的利用率在运作。

3.png

- RX 580 执行 Ethash 的表现——图片源自 CodeXL -

Ethash 有一个不足在于它会从主内存做 128 byte 大小的读取。这个访问规模使得 GDDR5X 内存的 GPU 在执行 Ethash 时效率较低。公共版的 ETHlargement 给 GDDR5X 做了 Ethash 访问匹配,可以让 128 byte 的载入全速运行。

4.png

- Titan X (Pascal) 和 1080Ti 类似——因为 128 byte 的载入,运行 Ethash 极其低效-

另一个问题是,GPU 核心利用率被夸大了。Keccak 是在 Ethash 开始和结束时调用的哈希函数,在 FPGA 或 ASIC 上可以更有效地执行。Acorn 系列 FPGA 专为卸除 Keccak 计算而设计,以节省系统功耗并提高性能。 对移除 Keccak 的 Ethash 进行分析表明,显卡的计算核心实际上只有 20% 的利用率,还有 10% 的效率可以提升。

5.png

-将 Keccak 移除后,GTX1070 执行 Ethash 的性能-

总结分析数据显示,超过 20% 的指令是 Keccak,可以卸载。

6.png

-从 gtx1070-ethash-source.csv 总结得到-

这些结果表明,可以设计针对 Ethash 的专用 ASIC,其包含以下属性:

  • 一个高带宽内存接口(一般来说是 GDDR6 或者 HBM2)
  • 一个 keccak 引擎
  • 一个小型计算核心,用于执行内部循环 FNV 和模运算。

由此产生的ASIC将比现有的商用GPU体积更小且能耗更低

ProgPoW 的设计始于 Ethash 并对其进行修改以尽可能多地提高商用 GPU 利用率。针对的是区块链消费者社区最常用的显卡,目前是 AMD 的 Polaris 和 Vega 系列显卡,以及 NVIDIA 的 Pascal 系列显卡。

在 Ethash 开始和结束时用到的 Keccak hash 从 f1600(字数为 64)减少到 f800(字数为 32)。 由于 GPU 具有 32 位数据路径,因此 f1600 至少需要两倍的指令才能在显卡上执行。 Ethash 本身不使用由 1600 处理的外部数据,因此减少处理的数据量对算法的安全性没有影响。 但是,这降低了从 GPU 卸除 Keccak 计算可能带来的效率提升。

7.png

- ProgPow.h -

访问DAG 的次数(也是迭代运算的次数)保持不变,与 Ethash 一样是 64 次。

DAG 数据读取的大小从 128 byte 增加到 256 byte,这样 ProgPoW 可以在所有当前 DRAM 设备上更有效率地执行而无需超频,运气好的话在一段时间内都是如此。

8.png

- ProgPow.h -

GPU 内核在执行 16 byte(4 字)载入时效率最高。 为了具有 256 字节的载入,必须有 256 字节/ (16 字节/通道) = 16 通道并行工作。

从帧缓存接口返回,GPU 拥有 L2,L1 和纹理缓存(Texture caches)。遗憾的是,我们还没有发现一种利用这些缓存的方法,这些缓存在 GPU 架构中都具有高性能和可移植性。 ProgPoW 没有针对它们,它们只是通过 DAG 加载。

紧接着 L1 缓存,GPU 具有少量高速暂存器内存(scratchpad memory),这部分高速内存用于临时存储计算、数据和其它正在处理的工作。 NVIDIA 和 CUDA 将此称为共享内存(shared memory),而 AMD 和 OpenCL 将其称为本地内存(local memory)。该存储器具有较大的交叉开关(crossbar),允许快速处理对随机地址的访问。

NVIDIA 的 Pascal 系列支持最多 96kb 的高速暂存,而 AMD 的 Polaris 和 Vega 系列支持最多 64kb。 AMD OpenCL 内核目前需要额外的暂存区空间才能在通道之间交换数据(如果 AMD 的跨通道操作对 OpenCL 开放了,就不会出现这种情况)。为了在所有现有体系结构上有效执行而不限制占用率,DAG 的缓存部分设置为1 6kb。

9.png

- ProgPow.h -

GPU 的计算核心具有大量暂存器,可为高吞吐量可编程数学单元提供信号。 Ethash 的内部循环先是 DAG 载入,然后用 FNV 将数据合并为小的混合状态。 ProgPoW 添加了一系列随机数学指令和随机缓存读取,合并为更大的混合状态。

910.png

- ProgPow.h -

混合状态的规模大小以及随机数学指令和缓存读取的数量都是根据经验测算来确定的:增加这些参数直到计算利用率与内存利用率相匹配。

结果:GDDR5

通过上述设置,ProgPoW能够立即使计算(即SM)和内存带宽饱和。

911.png

- GTX1070 执行 ProgPoW 的性能-

暂存器内存(或CUDA术语中的共享内存)也已饱和:

912.png

- GTX 1070 的共享内存运行 ProgPoW 的利用率-

RX 580也有相似的计算利用率。

913.png

- RX 580 运行 ProgPoW 的效果-

当 Keccak 计算减半时,ProgPoW 确实添加了一系列 KISS99 计算作为 fill_mix 阶段的一部分来初始化混合状态。Fill_mix 阶段产生的数据太多,FPGA 承载不了,但 ASIC 中的芯片确实能用一个小型加速器来实现它。 不过,这两者仅占计算(SM)利用率的7%左右:

914.png

-移除 Keccak 和 KISS99 后 GTX 1070 执行 ProgPoW 的效果-

这说明,超过 90% 的指令是在 DAG 访问,随机数学和随机缓存访问的内部循环中产生的。 Keccak 和 fill_mix 约占指令的 7%:

915.png

-从 gtx1070-progpow-source.csv 中总结得到-

这些结果表明,专门用于执行 ProgPoW 的 ASIC 需要包括:

  • 高带宽内存接口
  • 具有大型寄存器文件的计算核心
  • 能大量计算整数数学的计算核心
  • 高吞吐量,大存储量的缓存
  • 小型 Keccak + KISS99 引擎

这种专用 ASIC 看起来与现有的商用 GPU 非常相似。 它只会略小一些,能耗比不会有太大差别。

结果:GDDR6

我们还设法开始使用具有 GDDR6 内存的 RTX 2080 来执行初始基准测试。 CUDA 分析工具不完全支持新的 Turing 芯片。因此,许多性能指标(包括帧缓冲器利用率)为 0。

916.png

- RTX 2080 执行 ProgPoW 的表现。请注意,与先前的图像不同,Memory% 与 FB% 不对应。-

对于 Ethash 的 128 byte 载入,GDDR6 内存似乎与 GDDR5X 具有类似的问题。 通过 256 byte 载入,ProgPoW 能够使内存带宽饱和,运行速度比 Titan X (Pascal) 略快,即使内存带宽略小(448 vs 480 GB / s)。

比起 Pascal SM,Turing SM 似乎能够执行更多的数学指令和共享内存访问,核心和共享内存的运行利用率大约是Pascal的一半。

917.png

-执行 ProgPoW 时 RTX 2080 共享内存利用率-

这意味着,鉴于 ProgPoW 的当前调整,Turing ASIC 将比等效的 Pascal ASIC 闲置更多。 因此,Pascal GPU 的每个芯片面积具有更高的性能,这与单位价格的性能大致相关。

将来,ProgPoW 对于 Turing 一代的 GPU,只需改变一些参数(例如 PROGPOW_REGS,PROGPOW_CNT_CACHE 和 PROGPOW_CNT_MATH)。 通过适当的调整,图灵 GPU 将保持相同的性能,而目前的 GPU 将会受限,并且速度变慢。

结果:哈希率(算力)

918.png

-所有卡都以默认频率进行测试-

带宽利用率一列,我们将观察到的算力与理论算力进行比较。其中理论哈希值是假设 100% 的 GPU 内存带宽的数据(虽然这在现实世界中是不可能的)。

理论算力是使用带宽/单位哈希数据(bandwidth/data-per-hash)计算的, Ethash 为 8kb,ProgPoW 为 16kb。

按照一般的推论,ProgPoW 的算力应该是 Ethash 算力的一般左右,因为每次哈希运算的内存访问量变成了两倍。对 RX580 和 GTX1070 这些使用 GDDR5 的 GPU 来说确实如此,但使用 HBM2、GDDR5X 以及 GDDR6 的 GPU 在执行 ProgPoW 时会具有更高的效率。

性能分析报告

以下图像以 .png 格式附加:

注意:您需要放大以清楚地查看数据。

这里还有两个 .csv 文件,包含已用信息注释的源代码:

GTX 1070 — Ethash Source

GTX 1070 — ProgPoW Source

更多参考可以在这里找到

附作者在 DEVCON4 上的首次公开演讲:https://www.youtube.com/watch?v=N-CwGNTQ3hY&frags=pl%2Cwn


原文链接: https://medium.com/@ifdefelse/understanding-progpow-performance-and-tuning-d72713898db3
作者: IfDefElse
翻译&校对: Athur & 阿剑


你可能还会喜欢:

干货 | 加密货币挖矿的现状
干货 | 比特币,概率与随机性
干货 | 加密货币隐私性概述

 
0 人喜欢