数学研发论坛

 找回密码
 欢迎注册
楼主: gxqcn

[讨论] 重启大整数库 HugeCalc 的研发工作

  [复制链接]
 楼主| 发表于 2020-2-4 13:43:35 | 显示全部楼层
我想继续保留:兼容 MBCS / UNICODE 字符格式,

但又不想用 std::string 这些 STL 容器,
主要是担心其不同编译器厂商实现的源码不一致,怕有兼容性问题,
毕竟,我无法强迫调用 HugeCalc.dll 的用户必须得在 VC 下开发。
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
发表于 2020-2-4 14:14:49 | 显示全部楼层
gxqcn 发表于 2020-2-4 13:43
我想继续保留:兼容 MBCS / UNICODE 字符格式,

但又不想用 std::string 这些 STL 容器,
这是个问题.

C++11里的Unicode支持力度还是挺大的. 有字符串字面量u8, u,  U,char16_t  char32_t 类型,, u16string , u32string .还有codecvt库,支持各种转换.
不过,在C++17里,codecvt 库很多函数都废弃了.  http://www.open-std.org/jtc1/sc2 ... s/2017/p0618r0.html
不过, 有人说,不要慌:c++ : codecvt deprecated. panic?
https://dbj.org/c17-codecvt-deprecated-panic/

不过,讲真心话, 一旦涉及到unicode了,基本上都跟上层的UI扯上关系了, 这个时候,一般的UI库都会对unicode有大量丰富的支持,底层的库可以不用操心.

..
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
 楼主| 发表于 2020-2-4 15:23:16 | 显示全部楼层
输入输出,向来是一个很繁琐的环节,且大多与平台相关。

我现在用的是 char 及 wchar 数组来表达字符串,
且 数字<-->字符 之间的相互转换,完全是由自己编写的代码来完成,以期获得足够高的效率。

不知,改用 std::string 或 std::wstring 之类的容器后,
若仅内部使用,自不成问题;
但在 DLL 导出时,是否有问题?
谁创建?谁拷贝?谁销毁?
拷贝的数据格式是否匹配?

点评

个人觉得底层库 专注于计算的功能, 不用考虑各种字符编码. unicode支持交由 上层来做.  发表于 2020-2-5 21:44
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
发表于 2020-2-5 00:57:33 | 显示全部楼层
如果使用VC,当心local heap问题。例如,如果在dll创建一个std::string,在exe中析构这个对象时可能导致程序崩溃。
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
 楼主| 发表于 2020-2-5 09:10:20 | 显示全部楼层
嗯,正因为 DLL 有此限制(非 VC 的锅),所以我才决定导出的接口,必须是 POD 类型。

点评

即便同一个编译器,不同版本的 STL,其数据结构也可能不一致,所以不适合作为 DLL 的导出接口,这是当初 CSDN 上的一位网友提醒我的。  发表于 2020-2-6 20:39
Linux中的so没有这个问题。另外,在VC中sizeof(std::string)以debug编译和以release编译,结果是不同的。而gcc编译则没有这个问题。  发表于 2020-2-6 19:54
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
发表于 2020-2-5 21:42:25 | 显示全部楼层
gxqcn 发表于 2020-2-5 09:10
嗯,正因为 DLL 有此限制(非 VC 的锅),所以我才决定导出的接口,必须是 POD 类型。

是的, std::string不是pod类型.  
一般非pod类型的数据类型往往会因为编译器的实现不同 内存布局可能不同. 所以不宜作为跨语言的接口.
===
在我看来, 如果C++的API设计充分利用OOP, 以及RAII特性的话,就可以不用特别在意pod这种考虑了.
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
发表于 2020-2-7 20:34:55 | 显示全部楼层
说两点,
第一、AVX512下,SSE2上有ADCX/ADOX, MULX等专注于大整数计算的指令,相对AVX512,支持的处理器,普及度是很高的
第二、汇编直接写独立汇编文件即可,64位下,win平台,linux平台各有一套自己的函数参数,寄存器规则调用,
而且64只有这两套,win的可以在微软网站查到,遵循这个规则,就可以无缝链接汇编和C++

这里有相关研究文档

这个网站专门研究汇编和处理器优化相关资料


Intel处理器文档卷1:Basic Architecture


Intel处理器文档卷2:Instruction Set Reference, A-Z



点评

ELF格式支持PIC, PIC(位置非依赖代码)方式主要用于编写so文件,访问全局变量和函数调用与普通的方式有所不同。要很好的支持Linux和windows,就要使用条件编译,Linux可支持PIC方式,而windows则不用。  发表于 2020-2-24 09:51
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
发表于 2020-2-7 21:20:31 | 显示全部楼层
MULX是BMI2扩展
MULX ra, rb, r/m
rb:ra = (r/m)*(rdx|edx)

该指令4代haswell处理器架构引入
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
 楼主| 发表于 2020-2-7 21:21:02 | 显示全部楼层
谢谢指点!

ADCX, MULX 将尽可能用上(我前年买的 i7-8550U 应该支持吧),
并有可能将此两个指令作为用户可用 CPU 必须支持的最低条件。

关于汇编,我打算先安装 Intel C++ Compiler,它允许内联汇编,看看效果;
如不行,再考虑独立汇编。
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
发表于 2020-2-7 21:24:51 | 显示全部楼层
ADCX/ADOX是ADX扩展
ADCX  r, r/m
CF:r = r + (r/m)+ CF

ADOX  r, r/m
OF:r = r + (r/m)+ OF

该指令7代SkylakeX处理器架构引入
毋因群疑而阻独见  毋任己意而废人言
毋私小惠而伤大体  毋借公论以快私情
您需要登录后才可以回帖 登录 | 欢迎注册

本版积分规则

小黑屋|手机版|数学研发网 ( 苏ICP备07505100号 )

GMT+8, 2021-9-21 21:58 , Processed in 0.057691 second(s), 16 queries .

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表