-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
测试不完整/不公正 #436
Comments
腾讯阿里百度华为都有使用C++20的项目,企业不代表老旧代码。等你在C++的学习上的更进一步,就可能会理解iostream的问题所在(或者和少部分人一样永远不能理解,甚至和大部分人一样放弃C++),fastio无疑是目前在安全性,效率和易用性得到了最好的平衡的IO库(好于fmt和iostream)。此外OI的代码不能产生任何价值,OI的代码也不具备任何参考价值。希望你能尽快的度过中二时期,重新审视自身的水平(尤其是C++),以学习为中心,而不是进行这种幼稚而且没营养的讨论,因此关闭该issue。 |
你脑子有病就回家吃药。
首先Intel早就换clang了,intel oneapi compiler早就是clang套壳,有那个时间折腾前端,还不如向llvm贡献代码。
mingw-w64就是windows gcc的libc,这个项目除了自己为了msvcrt补了一部分东西(例如stdio的C99支持以外)其他的东西都是微软提供的,特别是ucrt.
不论什么编译参数,性能都远远快于iostream 不服你自己测去,我们拿数据你自己也不信那就自己测去。
搞笑了。我怎么可能用debug给你测性能?
我当然加了-s,不仅-s还-flto -Ofast gcc根本没有release一说。对你不懂的东西就闭嘴。 我猜你测这玩意连-static-libstdc++选项都不知道加,在这满地打滚。iostream大量的亡虚函数,等于说整个标准库全家桶,全死在编译好的libstdc++.a或是libstdc++-6.dll里了。很多平台根本不能动态链接(例如wasm,各类嵌入式,安卓等)libstdc++,怎么可能不大? #include<fast_io.h>
int main()
{
print("Hello World\n");
} #include<iostream>
int main()
{
std::cout<<"Hello World\n";
}
你告诉我这不是800kb是什么?你眼瞎了?
你的意思是C++标准委员会更新标准叫“抛弃兼容性”。
没有人强迫你用。你不尊重别人的劳动,在这骂人。你不是卢瑟谁是卢瑟。
搞笑了。std::tuple本身就是个笑话。性能都不如直接写个struct.没事找事吧你。
你在这说什么你完全不懂的东西呢? --disable-hosted-libstdcxx是编译构建独立C++,和异常不异常就没毛关系。还有你扯iostream向前兼容,iostream都不独立。你说你连个本地,交叉,加拿大编译都搞不出来,在这扯--disable-hosted-libstdcxx https://en.cppreference.com/w/cpp/freestanding 相反fast_io是独立库,不需要任何宿主功能就能运行。 不懂就拿这个工具链你去看下,看看有没有什么iostream
第一。链表的插入时间是不是O(1)根本没有意义。因为链表虽然按随机访问这种抽象机下插入时间为Θ(1),然而往往遍历到插入的点位本身的时间却是Θ(N)。一个典型的例子就是约瑟夫环,虽然插入是Θ(1)但遍历N次到下一个节点。实际的时间复杂度却是Θ(N+1)=Θ(N). 第二。谁告诉你访问随机地址叫Θ(1)的,没有抽象机有意义?在现代处理器上有多级缓存加页表一类的。访问随机地址的开销实际就不可能是Θ(1) 。有人说是O(sqrt(N))。不管怎样,Θ(1)就不可能严格意义上正确 第三。链表还有其他很多额外的开销。堆分配的开销。内存碎片的开销。本身链表多的指针域也会浪费大量内存空间。这些开销都是巨大的。
搞笑了。fast_io本身就是流式I/O. iostream不过是一种具体的实现。就像标准库list实现了双向链表,你自己写个双向链表就不是双向链表了?
又是I/O性能不重要论。脑残言论不值得一驳。你不用C++23就去更新编译器,不要在我这浪费时间谢谢。 还是这话,没人强迫你用,不服性能就自己测。不服功能就自己写。别浪费别人时间。 |
人没了。我就看到一部分。
你都没吃过这个菜,说人家厨师炒的烂。何况人家请你吃了?爱用用不用滚。 不违法也不代表你有权利在github上发issue。使用github是特权不是你的权利。根据github的规定,到别的项目刷屏完全可以举报你封了。
谁说数组就是在“栈上了”。向量不是一种数组?重新分配又怎样?重新分配以后扩容2倍了。插入平摊后时间复杂度仍然是Θ(1) 就算是重分配,平摊以后单次操作开销仍然远远小于链表。 同样存图邻接表就应该用二维向量,而不是第一维向量第二维链表。因为cache不友好,除非图极度稀疏,一个节点就0条或一条边那种情况(我也就见过一次),只要节点平均至少有2个元素链表就不如向量。根本上链表就扯蛋的。事实上所有用链表的情况都能用向量换掉。
不理解怎么扯到shared_ptr了?事实上双向链表还就不能用shared_ptr,因为会绕环导致整个链表都没被释放。 你给我找出来这个库什么时候用到shared_ptr, unique_ptr等非独立特性了?搞清楚std::array都不能用。 |
这是完全错误的。微软编译器默认就是静态链接ucrt和C++标准库。要加/MD才会动态链接部分代码。而windows10和windows11预装根本就不安装vcruntime 2015-2022,仍然需要用户手工安装vc 2015-2022 redistributable 这就是你所谓的“桌面环境”。这就是为何很多应用都会带着一堆系统库的dll 即便如此微软STL和libc+实现的流仍然要静态链接一部分,并不是都动态链接的,因而现实中仍然开销巨大。 至于说windows上的GCC libstdc++-6.dll的屁事就更多了。且不说libstdc++-6.dll不是微软的东西更不可能安装,光gcc自己线程模型,异常模型就一堆不同的abi,有 win32,posix,mcf之分,三套标准库运行时互相不兼容,还有sjlj dwarf seh一类的屁事。写个程序就拖个2mb的油瓶就不是二进制体积开销了? linux上glibc版本就炸妈,之后还有musl, bionic等的,都是一堆不同的abi,不仅是C++标准库abi不同,C库都不同。 更何况动态链接就代表开销小了?代价小了?动态链接仍然要重定位,即使加-fPIC仍然要重定位非代码段。32位windows全部都是重定位,而到64位windows才强制-fPIC https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/
|
14岁的oj小朋友没事就回去学习,不要在这浪费时间上网打游戏。 何况现在不进国家队也没有保送了,你在这吹个毛B呢。 |
mingw-w64 就是 win 下最常用、有效率的 libc,TDM-GCC nuwen GCC mingw-builds 之类的仍然是用 mingw-w64 作为它的 libc,mingw-w64 不仅可以用 msvcrt.dll 作为 crt,还可以有 msvcr{80,90,120} ucrt(ucrt 听说只支持 x64,msys2 到现在也只提供 ucrt64 版本)。
libstdc++.a 库文件已经生成了,不会再进行任何优化,链接器不会对对象文件汇编进行优化。在 libstdc++ 编译的时候会使用 -fdata-sections -ffunctions-sections 尽量减小 C++ 程序的体积
fast_io 提供了对 stdio iosteam 的标准组件的支持
确实,因为在 libstdc++ 中它有一个全局对象,用来初始化 std::(w)cout std::(w)cin 对象,但是单引入 不会引起二进制的膨胀(编译速度另说) |
This comment was marked as abuse.
This comment was marked as abuse.
你不开优化扯毛蛋呢 iostream本身已经是-O2优化的了。 |
#include<fast_io.h>
#include<fast_io_legacy.h>
int main() {
fast_io::timer tm(u8"fast_io");
fast_io::filebuf_file fbf(u8"fastio.txt",fast_io::open_mode::out);
for(std::size_t i{};i!=10000000;++i)
print(fbf,"Hello World");
} 这么测的小朋友。你测流的性能搞毛呢??? 同时要加-O2 之后甚至可以-fprofile-generate |
连库都没用正确,扯毛??fast_io支持<<输出???那不是fstream的功能??fast_io是用的print,scan 输出输入的。 #include <fstream>
#include <fast_io.h>
#include <fast_io_device.h>
#include <fast_io_driver/timer.h>
int main() {
fast_io::timer tm(u8"fstream");
std::ofstream fout("fstream.txt");
fast_io::filebuf_io_observer fiob{fout.rdbuf()};
for(std::size_t i{};i!=10000000;++i)
print(fiob,"Hello World");
} 所谓的兼容性是这么来的.你不信试试这个。这样它就会直接操纵fstream的缓冲区指针,达到与fstream兼容的作用 |
This comment was marked as abuse.
This comment was marked as abuse.
无所谓。 还有别忘了每次测试的时候先rm *.txt,不然linux内核删文件要时间 |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
对。这样快的多,不信你测试看看。因为它会直接操作fstream缓冲区指针。同时可以使用fast_io自己的很多功能,例如输出时间,本地化,QString winrt::hstring一类的乱七八糟的。 |
同理对于C的FILE*也一样 #include <cstdio>
#include <fast_io.h>
#include <fast_io_device.h>
#include <fast_io_driver/timer.h>
int main() {
fast_io::timer tm(u8"FILE");
FILE* fp =fopen("cfileptr.txt","wb");
if(fp==nullptr)
{
abort();
}
fast_io::c_io_observer_unlocked ciob{fp};
for(std::size_t i{};i!=10000000;++i)
print(ciob,"Hello World");
fclose(fp);//无视异常不析构。只是举例
} |
fast_io文件实际上是这样用的 #include <fast_io.h>
#include <fast_io_device.h>
#include <fast_io_driver/timer.h>
int main() {
fast_io::timer tm(u8"fast_io::u8obuf_file");
fast_io::u8obuf_file u8obf(u8"fastioobf.txt");//输出到fast_io自己提供的输出缓冲类型
for(std::size_t i{};i!=10000000;++i)
print(u8obf,u8"Hello World");
} |
别的不说,部分ostream的operator<<会调用sprintf,sprintf可是自己写个循环都能超过的存在。即使没用sprintf,用的也是循环再逆序的实现。而jeaiii/itoa在此方面可以带来巨大的提升。
测出这种离谱的结果先反思自己测试程序有没有写对。用的operator<<明明是ostream的。。。流都没玩明白就别说了。
加-Oz都没用,libstdc++-v6.a的体积一点少不了。
搞笑了,这话就不存在。微软都不敢说它向前兼容怎么样。建议试试win10上跑一个需要msvc++2005的vocaloid3,不装旧版库能跑得起来算我输。你觉得兼容只是装了很多版本的库。实际上自带fast_io/在系统里安装fast_io同样可以兼容。 |
链表在内核中是有广泛的应用(但也不是io),但在用户的io这种场合下是淘汰的,不应该把要io的数据放链表里。
有没有可能,就是输出到默认设置的流并不能体现fast_io::obuf_file大缓冲区的优势。
那就学习去,工程和OI不是一个东西。OI的东西没用实际意义。
"JavaScript function + Type description / interface"可不是什么值得推广的东西,而且,该淘汰的是JavaScript,给JavaScript加点特性并不能影响它应该被淘汰。而C with Concepts是值得推广的,这解决了模板编程可读性差的问题。可惜C with Classes并不能解决可读性的问题,意大利面条代码很大程度上是滥用oop导致的。关于这一结论,可以在讨论编程范式的文章里找到。可以说,是很多人提倡oop,但反对继承的人依然很多。即使你能严格遵循里氏替换规则,也不意味着继承等oop特性就能带来更多的可读性。 |
再提一点,如果libstdc++、msvc stl和libc++好用的话,为何llvm要自己弄一个libllvm来代替标准库(例如llvm::ofstream)?说到底还是标准库的东西太烂了,还搞本地化之类的。 |
This comment was marked as abuse.
This comment was marked as abuse.
这样的比较毫无意义,同步与异步没有可比性。这不在一个水平线上。。。
这不跨平台。不是所有平台都能不阻塞而结果正确。 |
This comment was marked as abuse.
This comment was marked as abuse.
阻塞和非阻塞就有可比性了? |
This comment was marked as abuse.
This comment was marked as abuse.
那测的时候请加上fast_io::open_mode::no_block,这样才有可比性。。。
不要假定系统会怎么实现。 |
This comment was marked as abuse.
This comment was marked as abuse.
用两个阻塞测更准确,因为fast_io还会检查write返回值之类的,拖慢了。 |
然而fast_io的作用就是将原本都是一堆的烂实现的东西整合在一起,达到整体最优。你用print(fbf,to_string(3));就不如直接print(fbf,3)快 |
This comment was marked as abuse.
This comment was marked as abuse.
实际上他这坨能不能性能高都未必。二进制体积就炸妈。代码重复n遍。 |
你封装了你这一堆再测,我只希望看到一行print之类的调用 |
它这个一份代码就重新写一遍,运行时性能都很难保证会高效,原因是二进制大量无意义重复,指令缓存炸妈 |
This comment was marked as abuse.
This comment was marked as abuse.
glibc不能静态编译。你就-static-libstdc++就行了 |
This comment was marked as abuse.
This comment was marked as abuse.
#include <cstring>
#include <cstdio>
#include <fast_io.h>
#include <fast_io_driver/timer.h>
int main() {
fast_io::timer tm(u8"yourmethod");
char buf[10240 * 10 + 1];
const char* w = "Hello World";
size_t ptr = 0;
fast_io::native_file obf("yourmethod.txt",fast_io::open_mode::out);
for(size_t i = 0;i != 10000000; ++i) {
size_t len = strlen(w);
if (ptr + len >= sizeof(buf) / sizeof(char)) {
write(obf,buf,buf+ptr);
ptr = 0;
}
memcpy(buf + ptr, w, len);
ptr += len;
}
if (ptr) {
write(obf,buf,buf+ptr);
}
} 我就用你这种愚蠢的办法“控制变量”呢
|
fast_io的六级文件 wine_file 对应wine层的文件。非缓冲流,进程安全。 从下级到上级移动(例如用nt句柄构造C++标准库文件流),上级到下级强制转换(例如得到fstream里的FILE*,或是fd或是HANDLE或是wine的平台fd)。 native_file在windows为win32_file,其他平台(包括cygwin)都是posix_file。 basic_obuf是给文件类型加缓冲的。 例如obuf_file是basic_obuf<native_file>等于只是在native_file上加了层缓冲而已。不考虑与stdio和fstream共用的情况的时,根本就没有理由用filebuf_file |
先来看看从fast_io中学习经验的MyStd在整数转字符串上的性能
ItoaSpeedTest.txt |
https://github.com/cppfastio/fast_io/blob/master/benchmark/0002.file_io_tsc/time/fstream.cc
你给我解释一下stdio是怎么比fast_io快的?安卓是吧,看样是libc++,之后用的filebuf_file??搞笑呢。libc++ std::filebuf不慢就出鬼了。 LLVM libc++流实现一直都是次品,慢炸。没事干不要用filebuf_file 把我这几个测试数据运行一样,再来扯吧。 |
This comment was marked as abuse.
This comment was marked as abuse.
非常抱歉我完全不能理解你这么多的代码是在胡闹什么。我不能理解你在使用 |
去查看库中以下概念: |
你这种带模板的定长串的输出方式本身就是问题,C++模板一个长度就会生成一个函数。把数组放模板里本来就是问题。你见过哪个库这么干的?字符串长度的可能性是无穷多种的,你每个都生成一份,代码不能合并导致体积炸妈,进而性能炸妈,就不是性能问题了??你这个api设计就有问题,因而基于这样的测的方式都有问题。 其次,终于承认输出整数“明显慢于fast_io”了?当性能慢于fast_io的时候你连数据都不列出了。说是摆烂。fast_io::concat是你这样用的?亲,初中生回去学习吧,不要在这浪费时间。 什么狗屁“内联”,C++里的内联指的是防ODR违反。函数都展开就比不展开快了,多出来的指令二进制体积被你吃了?间接造成上层函数体积增加,开销比你想的大的多的多。 安卓不是libc++就出鬼了。除非你是静态链接。libstdc++根本就不支持bionic |
Add small scatter optimization. Do not know whether it would create new issues for issue #436
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
谁告诉你glibc的缓冲区大小是8192的?它是用的fstat得到的值。操作系统都随便乱设的。之前的wsl2还乱设到512 4096或是8192的缓冲区大小本来就是不合理的。这个值是上世纪70年代80年代的值。现在内存大的多的多,却由于abi问题导致这个值改不了。就是abi bug。C艹abi问题多了去了。 131072是gnu binutils cp测试出来的最优值。然而stdio的问题远远不只是缓冲区大小一类的。 说的好像是什么声音驱动一样。交互式流有tie,需要刷新就手工刷新。完全不用缓冲直接用native_file作非缓冲流,我就没看出任何问题。不要没事干把不相干的东西放到我这来。声卡跟我有毛关系呀。 |
更大的缓冲区在实际使用中会带来更好的性能,并且如果你同时使用fast_io,他会hack iostream的实现以改善使用iostream时的表现,这是readme中清楚提到的。请完整、仔细阅读readme和wiki,再来提出issue |
真的是嘴硬 |
This comment was marked as abuse.
This comment was marked as abuse.
请不要陷入无意义的争论。fast_io所有的benchmark测试代码都在benchmark目录下。请提交你的代码以及你的测试结果。在提交代码前请注意:fast_io目标是建立一个通用的输入输出库,我认为如果fast_io/stdio/iostream可以在10行内解决的代码,人们是不会愿意手写20行来实现相同的功能。 |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as abuse.
aarch64-linux-gnu就不是安卓的三值。aarch64-linux-android才是安卓的三值。只能证明你刷机或是别的怎样的。
C++20 ABI哪里不兼容了?libstdc++ libc++还是msvc stl哪个说了C++20 abi不兼容了? 你脑子有问题,我求你用了。弱智?爱用用不用滚。 对glibc开-O2优化预编译好了,你怎么还用优化过的glibc呢。 直接屏蔽+举报。按github的规定钓鱼你号大概率没了。 重新实现io库的原因很多很多。最大的问题就是stdio和流本身api就有问题,导致根本没办法用。 https://www.bilibili.com/video/av375684439/ |
不要学了几个词就在这乱说,ABI兼不兼容就是个狗屁问题,gcc从2003年到现在就用的一个ABI,clang从2005年出生就用的一个ABI。微软的MSVC自从能编译amd64程序开始就是一个ABI,在网上听风就是雨扯毛呢,符号名的重整方法在这些年里从来没改过,网上那些说C++ABI不兼容的弱智根本就不知道这是C++类型安全的表现,放C里瞎jb链接运行时再报错有意思?你给我解释解释为什么Linux内核和glibc不能随便升级? |
加我qq811452018,我把你加回来吧。 |
问题
fast_io 在和传统流式 I/O 的比较上可能存在不完整或不公正的部分。
在速度上:
在兼容性上:
还请补充缺失的信息。
对于原作者偏见的一些反驳/解释
以 gcc 为例,请在编译参数加入
-s
(或更为激进的-Os -s
),然后再试一次。支持 Release 版的,请用 Release 版。您要是禁用了优化或者只开了-O1
、带了符号表和调试信息,我无话可说。您的行为等同于 Typescript + class 已经过时,建议使用 JavaScript function + Type description / interface。
此外,您几乎抛弃了兼容性,而这正是企业代码需要的。想必,您不会轻易在公司的老旧环境上使用 C++ 20 吧。
当个人和企业都不(愿意)广泛使用 fast_io 时,您是卢瑟。
您要是可以把数组(一定确保是连续内存)的插入时间复杂度变成 O(1),可能学 OI 的人都要跪下来叫您爷爷。
是的,论数值计算模板元被 constexpr 可读性完爆,但是请您用 constexpr 函数,不用 template 关键字来遍历元组。
展开语法不计算在内,对数据的处理往往会更复杂。
请确认 GNU 对此的解释:
您搞错了此选项的意思。请确认自己包含的头文件/用到的特性是否含在这些已提供的头文件中。
我还提到了特性,也就是说您可能需要添加额外的禁用参数来避免这些特性被默认打开,这样才能正常编译。
更多的偏见由于时间问题不再叙述。
总结
您的思想“对于当代程序员来说太过超前”,以至于大家对您的风评并不好。
您的 fast_io 固然比流式 I/O 快,但无可否认地后者文档和实例多得数不胜数,并且提供了很棒的前向兼容性。在这一点上,您的 fast_io 毫无疑问地完败给了您看不起的流式 I/O。
一个更为实用的方向是尝试给以前版本的 C++ 提供高性能的 C++ 20 库的 polyfill,比如更优雅易用的
<coroutine>
,这是大家都期盼的。而现在提出的 I/O 提速虽然性能高但却不能贸然使用。因为换用 fast_io 的成本过高,且不是每个人都使用 C++ 20。
这个库的未来还未知,毕竟也没有实际使用提速的案例。
不过总体来说可以当成一个新奇的尝试就是了。
我年龄较小,本 issue 也未经过高人指点,若有任何事实错误或表意不清的位置,请不吝赐教。
The text was updated successfully, but these errors were encountered: