最初我用一个简单的C程序测试了它,每个没有语言环境信息集,甚至包括头文件,性能差异很小.测试是一个百万次迭代循环,将字符串的每个字符调用到toupper()函数.
包含头文件并包含下面的行之后,它的速度要慢很多,并调用了很多MS C运行时库语言环境特定的函数.这很好,但性能受到了很大影响.在Linux上,这似乎对性能没有任何影响.
setlocale(LC_ALL,""); // system default locale
如果我设置以下它运行速度与linux一样快,但似乎跳过所有语言环境功能.
setlocale(LC_ALL,NULL); // should be interpreted as the same as below? OR setlocale(LC_ALL,"C");
注意:
适用于Windows 10的Visual Studio 2015
G用于运行Cent OS的Linux
尝试过荷兰设置设置和相同的结果,在Windows上没有速度差在Linux上.
我做错了什么或者是否存在Windows上的语言环境设置的错误,或者它是linux没有做它应该做的事情的另一种方式?
我还没有对linux应用程序进行调试,因为我对linux并不熟悉,所以不知道它在内部做了什么.
接下来我应该测试什么才能解决这个问题?
下面的代码用于测试(Linux):
// C++ is only used for timing. The original program is in C. #include <stdio.h> #include <stdlib.h> #include <ctype.h> #include <chrono> #include <locale.h> using namespace std::chrono; void strtoupper(char *strVal); int main() { typedef high_resolution_clock Clock; high_resolution_clock::time_point t1 = Clock::Now(); // set locale //setlocale(LC_ALL,"nl_NL"); setlocale(LC_ALL,"en_US"); // testing string char str[] = "the quick brown fox jumps over the lazy dog"; for (int i = 0; i < 1000000; i++) { strtoupper(str); } high_resolution_clock::time_point t2 = Clock::Now(); duration<double> time_span = duration_cast<duration<double>>(t2 - t1); printf("chrono time %2.6f:\n",time_span.count()); } void strtoupper(char *strVal) { unsigned char *t; t = (unsigned char *)strVal; while (*t) { *t = toupper(*t); *t++; } }
对于Windows,将本地信息更改为:
// set locale //setlocale(LC_ALL,"nld_nld"); setlocale(LC_ALL,"english_us");
您可以在完成的时间内看到分隔符的区域设置更改,完全停止与逗号.
编辑 – 分析数据
正如您在上面看到的,大部分时间都来自_toupper_l的子系统调用.
没有语言环境信息设置,toupper调用不会调用子_toupper_l,这使得它非常快.
解决方法
你的Linux结果是有道理的.你的测试方法可能还可以.使用分析器查看您的microbenchmark在Windows功能中花费的时间.如果Windows实现确实是问题所在,也许有一个Windows函数可以转换整个字符串,比如C boost::to_upper_copy<std::string>
(除非它更慢,见下文).
另请注意,升级ASCII字符串可以非常有效地进行SIMD矢量化.我使用C SSE内在函数为单个向量in another answer编写了一个case-flip函数;它可以适应大写而不是翻盖.如果你花费大量时间来更新超过16个字节的字符串,并且你知道是ASCII,那么这应该是一个巨大的加速.
实际上,Boost的to_upper_copy() appears to compile to extremely slow code,like 10x slower than toupper
.请参阅我的矢量化strtoupper(dst,src)的链接,该链接仅为ASCII,但在检测到非ASCII src字节时可以通过回退进行扩展.
您当前的代码如何处理UTF-8?如果假设所有字符都是单个字节,则支持非ASCII语言环境没有多大好处. IIRC,Windows使用UTF-16进行大多数工作,这很不幸,因为事实证明世界需要超过2 ^ 16个代码点. UTF-16是Unicode的可变长度编码,如UTF-8,但没有读取ASCII的优点.固定宽度有很多优点,但不幸的是你甚至不能假设使用UTF-16. Java也犯了这个错误,并且坚持使用UTF-16.
#define __ctype_toupper \ ((int32_t *) _NL_CURRENT (LC_CTYPE,_NL_CTYPE_toupper) + 128) int toupper (int c) { return c >= -128 && c < 256 ? __ctype_toupper[c] : c; }
来自x86-64 Ubuntu 15.10的/lib/x86_64-linux-gnu/libc.so.6的asm是:
## disassembly from objconv -fyasm -v2 /lib/x86_64-linux-gnu/libc.so.6 /dev/stdout 2>&1 toupper: lea edx,[rdi+80H] ; 0002E300 _ 8D. 97,00000080 movsxd rax,edi ; 0002E306 _ 48: 63. C7 cmp edx,383 ; 0002E309 _ 81. FA,0000017F ja ?_01766 ; 0002E30F _ 77,19 mov rdx,qword [rel ?_37923] ; 0002E311 _ 48: 8B. 15,00395AA8(rel) sub rax,-128 ; 0002E318 _ 48: 83. E8,80 mov rdx,qword [fs:rdx] ; 0002E31C _ 64 48: 8B. 12 mov rdx,qword [rdx] ; 0002E320 _ 48: 8B. 12 mov rdx,qword [rdx+48H] ; 0002E323 _ 48: 8B. 52,48 mov eax,dword [rdx+rax*4] ; 0002E327 _ 8B. 04 82 ## the final table lookup,indexing an array of 4B ints ?_01766: rep ret ; actual objconv output shows the prefix on a separate line
因此,如果arg不在0 – 0xFF范围内(因此这个分支应该完全不被预测),它需要提前输出,否则它会找到当前语言环境的表,其中涉及三个指针解引用:一个来自一个全局的,一个本地的线程,还有一个解引用.然后它实际上索引到256条目表.
这是整个库函数;反汇编中的toupper标签是您的代码所调用的. (好吧,由于动态链接,通过plt间接层,但是在第一次调用后触发了懒惰符号查找,它只是你的代码和库中11个insn之间的一条额外的jmp指令.)
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。