https://baike.baidu.com/item/gcc/17570?fr=aladdin

使用gcc-sdk开发，本地测试通过。决赛阶段一直报 answer exit abnormal Missing output file. 错误。 使用原始版本的gcc-sdk，参考这篇贴子，修改了buff数组内存分配，https://forum.huaweicloud.com/thread-8487-1-1.html 调试后还是存在一些案例跑通，另一些案例报此错误。 可否请专家修复一些sdk中的这个问题？调试的心累。

本帖最后由 MikeoPerfect 于 2018-3-20 13:45 编辑在io.cpp中我单步调试的时候，发现好像官方文档中给出的代码是存在一些问题的，，虽然最终不会影响结果，但会影响运行时间，如果数据量足够大的话确实是一个很大的性能问题！！，这里的fgets好像就是存在问题的，官方的代码中的fgets那行代码本来的意思是去判断是空行则continue，但是最终的行数结果是空行依然被统计了，不知道我说的对不对？？ 12888 12886

GCC会开O2优化么?开和不开运行时间差别很大啊。

新人小白第一次做比赛，有几个问题希望有人能回答一下： 1.SDKgcc中predict函数中char * info[MAX_INFO_NUM], char * data[MAX_DATA_NUM], int data_num, char * filename 分别是什么。filename是输出文件名吗？ 2.输入大概可以分为两部分，一部分是物理服务器大小等，另一部分为训练数据，是先输入第一部分再输入第二部分，还是反着来的？ 3.如第二个问题所示，会有两部分的输入，其输入文件名字是TrainData.txt/input.txt 吗 感谢~

ecs.cpp的主函数中调用的入口函数为：predict_server(info, data, data_line_num, output_file); 为何没有info数组的大小参数，readme中说ecs.cpp不可更改，那就无法获得info数组的大小？

本帖最后由 霁月 于 2018-2-1 15:55 编辑我们解决什么问题？先设想一个场景：你熬夜写完了论文，终于觉得可以喘一口气，然后舒舒服服地按下了CTRL+S保存文件。就在这时，你家的猫大爷拔掉了你的电源，你的文件还在吗(图片来自网络)？你肯定会想：这软件那么多用户，那么多专业的程序员，肯定没事吧？最多就是我最后没保存的几个错别字没改过来呗。这可不一定哦！这个问题更学术一点的定义叫“崩溃一致性(crash consistency)”。这个概念最早出现在文件系统的研究中——文件系统是一个庞大的数据结构，而一个文件操作通常需要对数据结构的多个部分进行修改，因此在诸如断电、系统故障等情况下保持文件系统的一致性就成为了一个挑战。崩溃一致性的基本概念在Remzi的经典教科书“Operating Systems: Three Easy Pieces”[2]中可以找到。之前的研究工作表明，无论是SSD硬件[3]、数据库系统[4]还是系统软件[5]，在现有的文件系统实现(ext4, btrfs, NTFS, ...)上多少都有一些崩溃一致性的问题。连那么厉害的专业程序员、久经考验的开源和商业项目都没搞定的事情，想必遍地的新手程序员们也会犯类似的错误吧(在读完宗师大佬们的文章以后，我的内心就是这么想的)？你猜对了。事实是，你的文本编辑器真的有可能摧毁你的文件。不仅文本编辑器有这个问题，相当多的其他类型的应用软件也存在这个问题。我们的论文就解决一个问题：让检测应用程序崩溃一致性bug的过程尽量简单，简单到只要按一个键就可以了。从一个Bug例子说起我是一名苦逼的程序员，为了养家糊口在外包公司做一个文本编辑器的项目。今天我完成的功能是存盘，在按下存盘键以后，将打开的文件保存。小case，我在Stackoverflow上搜索了“Java write file”，然后搞到了如下(简化的)代码：voidwriteTextFile(Stringpath,Stringcontent){PrintWriterwriter=newPrintWriter(path);writer.write(content);writer.close();}作为一名优秀的程序员，我想了想这样好像不太对……万一在write的时候出了什么状况，用户的文件不就丢了么？所以最好先做个备份，肯定就万无一失了。于是我把代码改成了下面这样，跑完测试就愉快地回家逗猫玩了。voidsafelyWriteTextFile(Stringpath,Stringcontent){backupPath=path+".tmp";writeTextFile(backupPath,content);deleteItem(path);renameItem(backupPath,path);}然而事情没那么简单。POSIX说，你确实是按照open -> write -> delete -> rename的顺序执行了操作，但我才没有规定从文件系统的角度看，它们是按照你执行的顺序完成的呢！什么？这意味着……如果系统偷偷调换write和delete操作的顺序，并且在删除操写入磁盘后立即断电，那不就等于把用户的文件给删掉了么？也就是说，如果猫大爷真的在保存文件的时候拔掉了电源，这文件整个就没了啊(论文就没有了啊喂)！更可怕的是，现在的文件系统(比如默认设置下的ext4)因为只保留了元数据的日志而没有保存数据操作的日志，这样的“乱序”是真正能被观察到的[5, 6]！这段代码来自文本编辑器Ted，所幸的是这个bug成功地被我们的工具检测到。崩溃一致性的自动检测现在我们有足够的动机去做一个工具检测应用程序的崩溃一致性了。对于程序猿来说，最好的工具就是拿来就能用的工具。所以我们的工具Crash Consistency Checker (C3)只需要被测程序的可执行文件和一个测试用例，方法大致分为3步(对技术细节没有兴趣的可以直接跳过)：[*]运行一遍程序，取得我们认为对于应用来说“正确”的文件系统快照。什么是“正确”的快照呢？我们认为程序猿不会傻傻地把重要的用户文件删掉。所以，我们认为所有元数据操作执行完毕后，内存中的文件系统快照代表了程序猿定义的“正确”状态。实现上，我们用ptrace拦截程序发出的系统调用，并在系统调用结束后从内存中抓取快照。回到之前保存文件的例子，“正确”的快照中至少包含一个文件的内容。 [*]使用一个虚拟的磁盘捕获所有的I/O请求，然后生成可能的崩溃现场。这个技术和已有的技术[4,5,6]十分类似。实现上，我们写了一个ramdisk的驱动，它从外面看表现得和正常的磁盘一模一样，但在后台悄悄记录了所有I/O操作的内容。根据这些I/O操作，就可以生成在Linux设备驱动规约允许条件下的各种崩溃现场。对于之前保存文件的例子，我们将会得到原文件被删除、备份文件尚未写入的一个文件系统快照。[*]对每个崩溃现场计算与“正确”文件系统快照的编辑距离，如果距离很大，那这个崩溃现场就看起来很可疑。两个文件系统快照的编辑距离定义为通过连续内容的删除/移动/重命名操作将一个快照变为另一个的最小次数。不过直接计算这个编辑距离是NP-Complete的，我们用了一些小技巧做了一个近似，求解一个它的下界(我才不会告诉你最后就是给你两个数组A和B，判断能不能把A里删掉一些元素重排以后变成B，现在小学生都会做这个题啦！)。显然，对于一个没有任何数据的文件系统快照，是无法通过编辑操作变成一个有数据的“正确”快照的，自然就被报告为可疑的bug了。实验结果我们从两大类(命令行工具和生产力工具)挑选了总共25个应用，并对每个应用的一个简单测试用例进行了测试，测试软件在ext4默认设置下的崩溃一致性。结果是我们找到了14个崩溃一致性bug，其中11个是开发者先前未知的bug，让我们看一看：列举一些有代表性的bug：[*]对in-place的处理很容易出错。比如sort F -o F、用于兼容古老版本的功能就变成了有危险的操作，提供原地替换的perl也有类似的问题。[*]gzip和bzip2犯了和之前例子类似的错误：在删除旧文件之前没有等待数据同步，从而导致了“压缩等于删除”的可能。各类生产力工具所犯的错误五花八门，保存文件的方式也各不相同，但很多都导致了同样的后果——数据丢失。[*]最后，gmake的问题在于，在你运行的脚本(如gcc)崩溃后，目标文件的时间戳被更新，内容却损坏了，这样如果这个文件最后被直接打包，就可能会导致严重的后果。虽然说这可以算是gcc的问题，但(1) gcc并不必须要提供崩溃一致性，而且(2) 这个问题最终影响gmake的用户，我们觉得让gmake的用户知道这件事可能发生是很重要的。在惊讶于这么多程序都有这类bug的同时，我们也对剩下通过测试的应用提出表扬，比如著名的Vim和Emacs。最后的提醒 [*]小心处理你的文件。看了这么多血淋淋的例子，我想你以后在保存数据的时候也会格外小心了吧。[*]库函数的支持非常重要。在和开源社区交互的过程中，我们很高兴地看到很多库都开始提供安全的文件操作(例如Qt中的QSaveFile和GTK中的g_file_replace)。与此同时，更多的新兴平台则做得不够好。比如Atom的开发者意识到了这类bug (而且真的有人在使用中触发了这个bug)，但Node.js的系统库却缺乏可移植的方案让他们能更好地避免这种问题。[*]留意崩溃一致性问题。gmake的例子警示我们，崩溃一致性问题不仅是那些保存数据的人需要关心的，也许哪天就悄悄地影响了你。所以如果你觉得这篇文章很有趣，请转发它让更多的人能意识到这个问题的存在。参考文献[1] Y Jiang, H Chen, F Qin, C Xu, X Ma, J Lu. Crash consistency validation made easy. InProceedings of the Symposium on the Foundations of Software Engineering(FSE), 133--143, 2016.[2] R H Arpaci-Dusseau, A C Arpaci-Dusseau.Operating Systems: Three Easy Pieces(v0.91), Arpaci-Dusseau Books, 2015.[3] M Zheng, J Tucek, F Qin, M Lillibridge. Understanding the robustness of SSDS under power fault. InProceedings of the USENIX Conference on File and Storage Technologies(FAST), 271--284, 2013.[4] M Zheng, J Tucek, D Huang, F Qin, M Lillibridge, E S Yang, B W Zhao, S Singh. Torturing databases for fun and profit. InProceedings of the Conference on Operating Systems Design and Implementation(OSDI), 449--464, 2014.[5] T S Pillai, V Chidambaram, R Alagappan, S Al-Kiswany, A C Arpaci-Dusseau, R H Arpaci-Dusseau. All file systems are not created equal: On the complexity of crafting crash-consistent applications. InProceedings of the Conference on Operating Systems Design and Implementation(OSDI), 433--448, 2014.[6] J Yang, C Sar, D Engler. EXPLODE: A lightweight, general system for finding serious storage system errors. InProceedings of the Conference on Operating Systems Design and Implementation(OSDI), 131--146, 2006.原文转载自：https://zhuanlan.zhihu.com/p/25188921

工具介绍STREAM为业界公认的内存性能测试工具，项目地址为http://www.cs.virginia.edu/stream/。主要用于测试CPU访问内存的带宽，代码有C语言和FORTRAN语言两种版本。测试说明：本指导以C语言下的v5.10版本为例，说明如何在CentOS 7.2操作系统下使用STREAM测试弹性云服务器内存性能。测试步骤：1、 获取源文件访问http://www.cs.virginia.edu/stream/FTP/Code/网站，获取stream.c文件，把文件拷贝至弹性云服务器中。2、 编译程序使用gcc编译源文件。如果弹性云服务器中未安装gcc，请先安装gcc程序。按以下命令编译stream.c文件。（注：编译参数仅供参考）69393、 执行程序执行命令./stream运行程序进行测试，执行结果如下图所示，为避免单次执行误差，建议执行5次以上，取平均值。6913

[color=rgb(51,51,51)]在 Linux Plumbers Conference 会议上，Google 的内核开发者 Greg Kroah-Hartman 和 Nick Desaulniers 介绍了用 Clang 构建内核的进展。[color=rgb(51,51,51)]Desaulniers 称今天的 Android 用户空间都用 Clang 构建，Google 想要减少它需要支持的工具链数量，至少在目前用 Clang 构建内核主要对 Google 有利，但有理由相信这对更广泛的社区同样有利。[color=rgb(51,51,51)]Clang 提供了一组与 GCC 不同的警告，更少的 bug 显然对所有内核用户都有利。Clang 还能提高额外的工具，如控制流分析，link-time optimization， profile-guided optimization。用不同的编译器构建代码也有助于筛选出依赖于未定义行为的代码。[color=rgb(51,51,51)]Greg Kroah-Hartman 称竞争对每个人都有利，过去五年 GCC 引入的新特性都是与 LLVM/Clang 竞争的结果。他希望 Linux 内核也有竞争对手。开源中国（来源）​

[code][root@hwclouds-ecs-100 ~]# gcc --versiongcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)Copyright © 2015 Free Software Foundation, Inc.[/code]本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保； 包括没有适销性和某一专用目的下的适用性担保。 [code][root@hwclouds-ecs-100 ~]# yum install -y libmpc-devel mpfr-devel gmp-devel zlib-devel cmake [root@hwclouds-ecs-100 ~]# mkdir -p /tmp/gcc && cd /tmp/gcc [root@hwclouds-ecs-100 /tmp/gcc]# curl -Lk ftp://ftp.gnu.org/pub/gnu/gcc/gcc-5.4.0/gcc-5.4.0.tar.gz|tar xz -C /tmp/gcc --strip-components=1 [root@hwclouds-ecs-100 /tmp/gcc]# ./configure --with-system-zlib --disable-multilib --enable-languages=c,c++ [root@hwclouds-ecs-100 /tmp/gcc]# make -j$(getconf _NPROCESSORS_ONLN) && make install [root@hwclouds-ecs-100 /tmp/gcc]# reboot [root@hwclouds-ecs-100 ~]# gcc --version gcc (GCC) 5.4.0 Copyright © 2015 Free Software Foundation, Inc.[/code] 本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保； 包括没有适销性和某一专用目的下的适用性担保。 [code][root@hwclouds-ecs-100 ~]# g++ --version g++ (GCC) 5.4.0 Copyright © 2015 Free Software Foundation, Inc.[/code] 本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保； 包括没有适销性和某一专用目的下的适用性担保。 [code][root@hwclouds-ecs-100 ~]# \rm -rf /tmp/gcc [root@hwclouds-ecs-100 ~]# mkdir -p /tmp/cmake && cd /tmp/cmake [root@hwclouds-ecs-100 /tmp/cmake]# curl -Lk http://www.cmake.org/files/v3.8/cmake-3.8.1.tar.gz|tar xz -C /tmp/cmake --strip-components=1 [root@hwclouds-ecs-100 ~]# rm -rf /tmp/ 2017-05-17.hwclouds-ecs-100.dwhd.org.root.history-timestamp tcp-status.txt bison/ .Test-unix/ .font-unix/ .X11-unix/ httpNUB.txt .XIM-unix/ .ICE-unix/ [root@hwclouds-ecs-100 ~]# \rm -rf /tmp/bison/ [root@hwclouds-ecs-100 ~]# df -hP 文件系统 容量 已用 可用 已用% 挂载点 devtmpfs 482M 0 482M 0% /dev tmpfs 496M 0 496M 0% /dev/shm tmpfs 496M 6.6M 489M 2% /run tmpfs 496M 0 496M 0% /sys/fs/cgroup /dev/mapper/DTVG-root 10G 3.0G 7.1G 30% / /dev/xvda1 1014M 140M 875M 14% /boot tmpfs 100M 0 100M 0% /run/user/0 [root@hwclouds-ecs-100 ~]# [root@hwclouds-ecs-100 ~]# mkdir -p /tmp/cmake && cd /tmp/cmake [root@hwclouds-ecs-100 /tmp/cmake]# curl -Lk http://www.cmake.org/files/v3.8/cmake-3.8.1.tar.gz|tar xz -C /tmp/cmake --strip-components=1 [root@hwclouds-ecs-100 /tmp/cmake]# ./bootstrap && make -j$(getconf _NPROCESSORS_ONLN) && make install [root@hwclouds-ecs-100 /tmp/cmake]# cd && rm -rf /tmp/cmake [root@hwclouds-ecs-100 /usr/lib64]# cd [root@hwclouds-ecs-100 ~]# cmake --version cmake version 3.8.1 CMake suite maintained and supported by Kitware (kitware.com/cmake).[/code]