Esper 发布的文章

https://www.cnblogs.com/fqucuo/p/4887083.html

问题出在Debug配置的-Zi选项上。这个选项用于生成目标项目的调试符号。 我产生该警告的过程是，使用CMake配置第三方项目，编译并安装后，删除了编译时的文件夹。 因而猜测，调试符号并不是嵌入到可执行文件（或者库）里的。 MSVC应该是在链接静态库文件的时候，根据写在文件里的信息去寻找（应该也是PATH里的）对应的符号数据库文件吧。（猜测一下，那岂不是把pdb文件复制到lib对应目录下就好了么） 解决方法之一如引用中所说，删除-Zi选项，不生成额外的调试文件，就可以避免MSVC找不到对应的符号文件而报出的警告。 另一个解决方法，个人认为，如果不是在第三方库的初学阶段，可以考虑将该库的源码添加至项目中，作为主项目的依赖随项目一起编译，然后配置一下输出目录和输出文件名和主项目在同一目录即可。这样至少项目树结构会显得清晰一些。（应该不会有人不知道在没有更新目标target的选项或是源文件的情况下，VS是可以自动跳过该目标的重新编译的吧）

https://dblp.org/rec/conf/cluster/ParkS09

该论文属于实验报告类型，主要内容是对于科研程序这种磁盘读写密集型的系统在SSD上的实际性能进行了一个定量的测试。 论文的发表时间为2009年，也就是实验进行的时间理论上不会晚于2009年。在后来查其他几篇论文的时候，发现作者之一的Stan Park是HP实验室的。

在该文章中，作者使用了三种不同技术的存储介质（两种类型，机械硬盘和半导体闪存）,分别是代表机械硬盘的西数鱼子酱WD Caviar SE，SLC的Mtron Pro 7500和MLC的Intel X25-M。MLC里的M指的是Multiple，即相对于（当时的）传统SLC来说，使用一个存储单元存储多位而不是一位二进制数据。（但是就当时（2009年）的科技水平而言，当时最多应该是两位了吧，尤其是这还是企业级的；到了2018/19年TLC才在消费领域普及）要不重新起个名叫BLC算了

然后作者使用了来自Los Alamos和Sandia两个美国国家实验室的I/O数据记录（然而地址都已经打不开了= =），在自己的平台上重放以进行性能对比。当然，除了存储介质不一样（还有存储控制器？），其他变量都是控制了的。结果表明，SSD的性能比机械硬盘提升并不大，西数HDD甚至还在某些场景下性能超过了Mtron的SLC。但是，I/O效率本应低于SLC的Intel MLC却在性能上远远超出了Mtron SLC。根据作者分析，原因如下：

  1. 根据当前NAND闪存芯片的组织方式和操作原理来看，读取和写入的规则是不一致的。虽然读取和写入都是按照文件系统的页来进行的，但是对于NAND闪存芯片的写入必须按照块的方式来进行。页和块分别是从逻辑和物理的角度上定义的：页的大小由文件系统决定，作为从该逻辑分区中一次存取的元数据量大小（即逻辑I/O的最小单位）；块的大小由闪存芯片的固件决定，作为一次物理上数据记录的元数据量大小。仔细思考会发现这两个参数对应的系统效能变化函数（假想）并不会是单调的：过小的页/块会显著地增大地址的数量，过长的地址编码不利于提升数据的有效传输率；过大的页/块则会因为物理传输速率的有限，增大读写时延，该缺陷会在大量的随机读写中明显地表现出来。至少就目前来看，可能是根据计算机行业的大量测试得出的较优结果，页的大小是略小于块的，该比例不会超过二进制的十个数量级。因而可见，最大达到2^10倍的数据量差异，时延差距会有多大。。

  2. SSD连接到计算机的方法是分层的：闪存芯片-Flash Translation Layer(FTL)-计算机外围I/O。因而，FTL在其中扮演了一个很关键的角色，上述提到的块操作就是由它来完成的。顾名思义，闪存翻译（映射）层负责提供计算机能够读取使用的逻辑存储结构，一方面负责操作闪存，一方面与计算机交换存储元信息和数据。作者认为，正是这样的分层结构，成为了闪存I/O优化的一个阻碍：FTL不知道自己被要求读写的数据的语义，只能机械地按照指令存取，同时进行固件中设定的垃圾回收策略；计算机不了解数据的真实存储布局，只能机械地按照程序流程将指令近乎顺序地（系统中可能有I/O调度方案，对I/O请求进行一定程度的重排）发送给FTL。有成语云“因地制宜”，我猜测作者在此同样认为，能够了解实际情况的话，能够使用某些算法对I/O性能有更进一步的提高。（此外私以为，在计算机和FTL尚无法直接沟通的当下，FTL（主控？）的I/O算法同样对性能有很大的影响。）文末提到了不使用文件系统日志来维护当前逻辑分区的文件列表，我就很好奇，不用日志咋办？查一个文件扫一次盘吗？？

  3. 实验中的Intel MLC性能超过Mtron SLC的原因很简单，根据作者的解释，因为Mtron Pro 7500是四通道总线，Intel X25-M是十通道总线。看来这时候还不是很擅长挤牙膏啊

最新版的网易云音乐（1.2.1）使用到了deepin自己编写的qcef，该组建的功能是为第三方软件提供内嵌chrome浏览器的支持。由于是deepin自己写的，dnf里面还没有形成相应的包，所以需要自己编译。

安装了qt库之后，使用cmake开始编译，遇到了这么一个问题：

fatal error: QtGui/private/qguiapplication_p.h not found
#include <QtGui/private/qguiapplication_p.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

安装了qt5的devel包也没用。后来发现private headers被放在了这么一个奇怪的包里：qt5-qtbase-private-devel

安装完这个包，编译继续，正常完成，网易云音乐可以使用。

此外，ubuntu包里的libs就可以删除了，因为可以通过在系统里用dnf手动杆状需要的依赖库。 数据文件可以通过ar x命令解压，然后在里面的data.tar.gz里。

在国内逛了老半天，都tm是那几篇博客，讲的方法我从f26试到f28，没有一次是成功的（生气）。 然后到国外逛，在Reddit上看到了有不少人在对这个进行讨论。有人直接用nvidia的.run文件安装驱动，然后上bumblebee管理，也有人用rpmfusion里的驱动，也有人用Negativo17的nvidia驱动源。为啥我只给最后一个方式添加链接呢？因为这就是本篇的主角。 至少在我华硕+HM175的笔记本上，使用原生驱动加bumblebee在配置正确的情况下是会直接让电脑死机的，也不知为啥，看到Negativo17这个名字的时候，总有种熟悉感，而且直觉告诉我用了这个一定会配置好。。。

直接上操作了：

  1. 为了让电脑首先正常地启动，修改/etc/sysconfig/grub中的GRUB_CMDLINE_LINUX变量，如果有与modeset相关的一律删掉，改为rd.driver.blacklist=nouveau用以在开机时不加载会让电脑卡死的nouveau驱动。 在此顺便提一下：nomodeset将不会加载任何驱动，直接使用llvmpipe以兼容方式实现最基本的图形输出；nouveau.modeset=0将会加载但不使用nouveau驱动，若是cpu有核显的话会加载并使用对应的核显驱动。
  2. 添加软件源 
    sudo dnf config-manager --add-repo=https://negativo17.org/repos/fedora-nvidia.repo
  3. 安装驱动 基本驱动对应的是nvidia-driver，需要使用CUDA的话还需要安装nvidia-driver-cuda和cuda-devel；需要看X Server Settings的安装nvidia-settings。 GPU开发者全家桶： 
    sudo dnf install nvidia-driver nvidia-driver-cuda cuda-devel nvidia-settings

    根据作者描述，如果是游戏玩家的话，可能还需要32位的图形库nvidia-driver-libs.i686。

装完就完事了。直接能用。

然后根据作者描述有以下两种情景： 1）使用nvidia的官方闭源驱动：在该场景下能最大程度地发挥GPU的性能，但是所有应用将运行在nvidia GPU上，因而无法关闭； 2）使用nouveau开源驱动：对于GPU的使用可能不是十分充分，但是可以选择是否将应用运行在nvidia GPU上，因而可以从某种程度上节省电能，即在该模式下，允许nvidia GPU休眠。 也就是说，使用Negativo17的驱动源，在目前的Fedora上是无法兼顾性能与能耗的。

（有人在Reddit论坛上提到，nvidia官方的run文件不受linux发行版的包管理器管理，会修改许多文件，可能与其他软件造成冲突；自身的卸载指令也无法完全生效，总之就是卸不干净。。。反正据他们推荐，在好还是用包管理器提供的显卡驱动）

最近看到rpcs3中用到了asmjit，就去其官方项目上看了一下，根据描述是个即时生成目标平台汇编代码的库，但是看了一下样例之后发现有些东西还是没法完全理解。其中之一就是ret指令。在样例代码中是这么写的：

  ...
  x86::Assembler a(&code);
  a.mov(x86::eax, 2);
  a.add(x86::eax, -3);
  a.ret();
  ...

然后就想，既然Assembler模拟的是汇编指令，那么ret指令返回EAX的值会不会是某种约定呢？ 然后打算查阅Intel的汇编指令手册，官方名叫Intel® 64 and IA-32 Architectures Software Developer’s Manual，里面有对指令的详细介绍。看到ret指令对应的伪代码有整整几页，有点慌啊。。 其中有这么几句：

IF top 4 bytes of stack not within stack limits
    THEN #SS(0); FI;
EIP ← Pop();

当时就对这个#SS(0);有点迷惑。然后在谷歌上查到了相似的使用方法，但是仍然没看到正式的定义。但是在一个网站上可能看到了类似的定义(http://www.scs.stanford.edu/05au-cs240c/lab/i386/RET.htm，惊了，是斯坦福)：

Protected Mode Exceptions #GP, #NP, or #SS, as described under "Operation" above; #PF(fault-code) for a page fault

然后便开始猜测#<abbr>(<val>)的用法为带返回码的异常抛出：其中PF对应page fault的话，根据搜索，SS对应的为stack smashing，即栈溢出；GP对应general peotection，该机制旨在确保程序访问有效的地址区域；但是NP这个not present就有点搞不懂了。。似乎是指什么不存在？

虽然还是有对不上的。。但是大部分意义都是可以对上的，因而认为猜测正确。

总而言之，这个格式的意义是明白了：Intel使用的伪代码中的异常抛出语句。

  1. 1
  2. ...
  3. 36
  4. 37
  5. 38
  6. 39
  7. 40
  8. 41
  9. 42
  10. ...
  11. 53