B计划之大数的表示

无心人

1、我用32位进制， 不存在你说的乘以除以进制方幂问题，只要使用复制操作即可 2、不会的 2.1、1024乃核心库的表示方式 2.1.1、核心数字使用1024最小分配方式 2.1.2、算法内部乃核心数字更深入的层次，完全可以以接近最完美形式使用，和核心数字无关 2.2、我计划使用如下的层次关系 2.2.1、最核心的一系列汇编例程，仅针对以机器字为单位的数字串，32位和64位在这里分开实现，无错误处理 2.2.2、外部是C算法部分，使用C/C++实现一些核心算法，比如普通除法，一些乘法等，此时使用的算法，直接调用2.2.1的汇编，仅简单错误处理 2.2.3、接口部分，使用1024块大小，此时实现一些供外部调用的程序，以C实现，比如通用四则运算，内存分配等，混合调用2.2.1、2.2.2算法，算法调用的基本单位不是数字串，以结构方式传递数字的信息，完全处理任何情况 2.2.4、C++接口，实现类，使用2.2.1、2.2.2、2.2.3的函数 2.2.5、引出接口，以obj、lib等文件引出2.2.1、2.2.2、2.2.3的函数 明白么？

gxqcn

我的说法与10进制、2进制之类的提法毫不相关。 就以你的为例，一个大数 * 2^100，你如何处理？ 反之，一个大数 / 2^100，你如何处理？ 都还要求始终保持16字节对齐吗？

liangbch

因为，正好是8个128位，无论使用什么方法 都可以做最大8路的展开算法了

你还提到，1024bit 是最小内存分配单位，和运算无关

无论采用何种内存分配策略，都可以做8路循环展开，这个1024bit无关。 另外，16字节对齐 带来的效率提升不很明显，但为此付出的代价却异常沉重，你可以能需要大量的内存复制操作（比如应用于kara_mul） 你可以测试一下你的16字节对齐内存复制和清零的速度，并与 memcpy/memset（用intel 编译器编译)，看看速度可提升多少。 http://bbs.emath.ac.cn/thread-348-2-1.html 14#的测试结果表明，当16byte对齐时，使用SSE2的内存复制反而比使用memcpy函数更慢。

无心人

老大 那是数字的移位操作啊 一次可以处理128位甚至一次可以移位4个128位啊

无心人

好吧，我说， 我坦白 因为，如果是大数运算，可能存在数字的膨胀问题 如果一次分配的太小，会出现频繁的重新分配问题 所以我以1024为最小分配单位，以后的分配，逐次加大 这是大数分配 和算法内的分配无关，算法内以手工指定大小

无心人

16字节对齐是编译器做的事情，我？ 我不需要做 我自己分配的内存，编译器或者操作系统 似乎默认就是16字节对齐的吧

liangbch

这也不好，如果一个应用需要 用到大量的大整数，但每个 大整数的值不超过2^96,你这种内存分配方式势必造成很大的内存浪费。

无心人

liangbch我那种说法8个128位也许存在混淆视听的问题 但我的本意不是直接使用1024位操作的 我在这里纠正 但你们其他的疑问，俺坚决反对

无心人

那就使用最低层次的函数吧

无心人

这种应用很少吧