B计划之大数的表示

无心人

很久没动这个了 写点新的感受 我想如果是32位CPU 分配的最小单位是1024bit也就是32个32位 为什么呢？ 因为，正好是8个128位，无论使用什么方法 都可以做最大8路的展开算法了 ：） 另外，对未来使用64位，也能符合一次8个128位或者16个64位的展开要求 我想，这是比较合适的选择

liangbch

还是以前的观点，不建议采用这么大的单位。 比如RSA,常常使用512bit的整数，你用这么大的单位，存储空间整整浪费了1倍，计算乘法时，乘法运算的次数增加到原先的4倍。 浪费太严重了！！！ 浪费太严重了！！！ 浪费太严重了！！！

无心人

你太激动了啊 1024是底层的bit块大小 但初始的长度是32位啊 也就是说 参与运算的实际大小以实际值参与运算 选择1024不过方便操作而已

gxqcn

大数运算免不了要“左移”、“右移”运算（许多加速算法有此需求）， 如果说需要“左移”一个基本单元， 正常的不过是在数据结构的头或尾插入一个基本单元， 而如果是采用1024bit的大单元， 必须在插入后还有进行额外的数据的迁移， 使高效的“移位”运算效率大打折扣！

无心人

两位老大 我的1024是最小分配单位 而不是最小操作单位 我敢用这么大数据运算么？

gxqcn

我在 14# 说的还有另一层意思： 如果考虑16bytes对齐（或更高的1024bits对齐）， 有时需要额外大数据迁移，非常不划算。 至于内存分配管理模式，似乎与“大数的表示”不相关了吧？ 它更多的是一种策略，目的仍然是尽可能地减少数据迁移次数。

无心人

1024只是一个尺度 而不是一个对齐的依据 对齐还是以16字节为准的好 你说的数据迁移的具体含义是什么？

gxqcn

所谓的“数据迁移”，主要发生在： 1、数据的正常备份 2、无法直接插入新的（或删除旧的）数据单元时 3、为字节对齐（可选项） 其中： 第1项应尽可能避免不必要的次数； 第2项可通过合理的数据结构减少数据迁移的发生频次（但也要兼顾读写效率）； 第3项如果仅为了内部实现的便利，如果效率提升轻微，不用也罢。

无心人

1、和1024无关，备份只备份有效数字就可，源和目的的1024仅是分配块大小 2、大数核心运算不存在插入删除操作，即使外围有，也是1的变形啊 3、有关系，有很大关系，有的操作16字节对齐的效率提升明显，最简单的是逻辑运算、复制、比较大小、清零等

gxqcn

插入：乘以 内部进制的若干次方 删除：除以 内部进制的若干次方（也可仅移动首指针） 如果为了16字节对齐， 那么，在用Karatsuba、Toom等算法分段时不得不考虑必须16字节整数倍分段， 而且分段后首部或尾部某些连续的“0”也不得不参与运算。