Julia生成BigInt向量执行powermod时内存占用过高问题求助

• Julia的BigInt是基于GMP实现的引用类型，每个实例除了存储实际数值位，还包含结构体元数据（分配长度、有效长度、数据指针）和独立的堆内存分配，实际内存开销远高于你预估的1024bit/个的纯数据成本。你测试的2^24（共1677万）个BigInt实例加上计算过程中的临时对象，总分配达到4GB属于正常现象，不是操作错误。
• 额外冗余开销：你调用了collect(1:2^N)，会先生成一个长度为2^N的Int类型临时数组再传入广播计算，进一步增加了不必要的内存占用。

1. 基础语法优化 #

去掉多余的collect调用，直接把范围作为广播参数，省去临时数组的分配开销：

v = powermod.(1:2^24, e, n)

2. 替换存储类型降低内存占用 #

不要用BigInt数组存储固定位宽的模运算结果，改用值类型的固定长度大整数/字节数组，消除引用类型的元数据和单独分配开销：

• 针对你当前测试用的1024位n，可以用StaticArrays.jl的SVector{16, UInt64}存储1024位结果，每个元素仅占128字节纯数据，内存占用直接降低60%以上，同时完全消除GC压力。
• 如果你实际作业要破解的是64位模数的RSA，模运算结果仅需8字节存储，2^24个元素总内存仅需128MB，和当前4GB的开销有量级差距。

3. 算法逻辑优化 #

你当前计划的2^{34长度数组完全没有可行性：按当前内存占用推算，2}34个BigInt需要至少4TB内存，远超出常规硬件能力。建议调整中间相遇攻击的拆分逻辑：

• 64位搜索空间的中间相遇攻击最优拆分是拆分为两个2^32的子空间，如果你是破解64位RSA密钥，调整拆分阈值后内存需求可以降到32GB以内（按每个结果8字节计算）。如果普通PC内存不足，可以拆分为3段做三阶段中间相遇，内存需求可以进一步降到几百MB。
• 不需要全量存储所有计算结果再排序匹配，可以边计算边写入磁盘，后续用外排序做匹配，内存占用可以降到MB级。

4. 性能优化 #

• 开启Julia多线程，把计算范围拆分给多个线程并行计算，针对e=65537的模幂运算可以获得线性提速效果。
• 可以预分配数组空间，避免广播的自动扩容开销。

内容的提问来源于stack exchange，提问作者Ruben