编译器优化

写程序最主要的目标是使他在所有的可能的情况下都能正确工作。程序应该写出清晰简单的代码，主要为了给后期维护，起作用；但常常我们在程序的简单性，维护性，与程序的运行速度进行权衡； 高效的程序需要几类活动： （1）必须选择一组合适的算法和数据结构； （2）必须编写出编译器能够优化以转换成高效可执行的源代码，因此理解优化编译器的能力和局限性很重要，因此程序即使是很小的变动，会引起编译器优化方式很大的变化；因此程序员经常能够使编译器更容易产生高效代码的方式来编写他们的程序，对于C语言的指针，就编译器已经很难优化了； （3）并发编程，利用多处理器和多核的某种组合并行的计算； 现代编译器使用复杂精细的算法来确定一个程序中计算的是什么值，以及它们是如何使用的，然后利用一些机会来简化表达式，在几个不同的地方使用用一个计算，降低给定计算的执行次数；GCC编译器提供优化级别的控制，级别越高，程序的规模可能会提高，调试困难会提高；低级别的优化高效的C代码，要比高级别的优化初级的C代码性能要高； 要是编译器安全的优化，程序员必须花大力气编写编译器可以转换成有效的代码，举例如下： （1）*x += * y; *x += *y; 与（2）*x += 2 * *y; 这两个代码片段似乎有相同的行为；（2）要快一点，涉及3次存储器引用，而（1）涉及6次存储器引用，但是如果考虑*x = *y，则（1）会增加4倍的值

写程序的主要目标是使它在所有可能的情况下都能正确运行（bug free），一个运行得很快但有 bug 的程序是毫无用处的。在 bug free 的基础上，程序员必须写出清晰简洁的代码，这样做是为了今后检查代码或修改代码时，其他人能够读懂和理解代码。另一方面，让程序运行得更快也是一个很重要的考虑因素。不过，程序获得最大加速比的时候，是它第一次运行起来的时候。 在提到优化程序性能时（Code optimization），我们往往会想到算法与数据结构中的一个概念——复杂度。事实上，除了算法复杂度之外，仍然有许多的代码书写小细节可以改进性能表现。不过，编写高效的程序，第一个考虑的还是选择一组合适的算法与数据结构，因为算法复杂度影响还是相当大的，而且通常比其他常量因素更重要。第二点，我们必须写出编译器能够有效优化以转换成高效可执行代码的源代码。对于第二点，理解程序是如何被编译和执行、理解处理器和存储器系统是如何运作的、理解编译器优化的局限性是很重要的。在程序开发过程中，程序员必须在实现和维护程序的简单性与它的运行速度之间做出权衡，也就是在尽量不破坏程序的模块化和通用性的前提下，做到对代码性能的优化。 即使是最好的编译器也受到 妨碍优化的因素 （optimization blocker）的阻碍，程序员必须编写容易优化的代码，来 帮助 编译器（很让人眼界一新的观点）。研究程序的汇编代码

1、选择合适的算法和数据结构 选择一种合适的数据结构很重要，如果在一堆随机存放的数中使用了大量的插入和删除指令，那使用链表要快得多。数组与指针语句具有十分密切的关系，一般来说，指针比较灵活简洁，而数组则比较直观，容易理解。对于大部分的编译器，使用指针比使用数组生成的代码更短，执行效率更高。 在许多种情况下，可以用指针运算代替数组索引，这样做常常能产生又快又短的代码。与数组索引相比，指针一般能使代码速度更快，占用空间更少。使用多维数组时差异更明显。下面的代码作用是相同的，但是效率不一样。 数组索引 指针运算 For(;;){ p=array A=array[t++]; for(;;){ a=*(p++); 。。。。。。。。。 。。。。。。 } } 指针方法的优点是， array 的地址每次装入地址 p 后，在每次循环中只需对 p 增量操作。在数组索引方法中，每次循环中都必须根据 t 值求数组下标的复杂运算。 2、使用尽量小的数据类型 能够使用字符型 (char) 定义的变量，就不要使用整型 (int) 变量来定义；能够使用整型变量定义的变量就不要用长整型 (long int) ，能不使用浮点型 (float) 变量就不要使用浮点型变量。当然，在定义变量后不要超过变量的作用范围，如果超过变量的范围赋值， C 编译器并不报错，但程序运行结果却错了，而且这样的错误很难发现。 在

在性能优化方面永远注意80-20原则，即20%的程序消耗了80%的运行时间，因而我们要改进效率，最主要是考虑改进那20%的代码。不要优化程序中开销不大的那80%，这是劳而无功的。 第一招：以空间换时间 　　计算机程序中最大的矛盾是空间和时间的矛盾，那么，从这个角度出发逆向思维来考虑程序的效率问题，我们就有了解决问题的第1招--以空间换时间。比如说字符串的赋值： 方法A：通常的办法 #define LEN 32 char string1 [LEN]; memset (string1,0,LEN); strcpy (string1,"This is a example!!"）; 方法B： const char string2[LEN] ="This is a example!"; char * cp; cp = string2 使用的时候可以直接用指针来操作。 从上面的例子可以看出，A和B的效率是不能比的。在同样的存储空间下，B直接使用指针就可以操作了，而A需要调用两个字符函数才能完成。B的缺点在于灵活 性没有A好。在需要频繁更改一个字符串内容的时候，A具有更好的灵活性；如果采用方法B，则需要预存许多字符串，虽然占用了大量的内存，但是获得了程序执 行的高效率。 如果系统的实时性要求很高，内存还有一些，那我推荐你使用该招数。 第二招： 使用宏而不是函数。 　　这也是第一招的变招

Linq LINQ（Language Integrated Query，语言集成查询），发音 "link"，是一组技术的名称。LINQ是 Visual Studio 2008 和 .NET Framework 3.5 版中引入的一项创新功能，它在对象领域和数据领域之间架起了一座桥梁。LINQ 将强大的查询功能扩展到 C# 和 Visual Basic 的语言语法中，并采用标准的、易于学习的查询模式。可以对此技术进行扩展以支持几乎任何类型的数据存储。 传统上，针对数据的查询都是以简单的字符串表示，而没有编译时类型检查或 IntelliSense 支持。 此外，您还必须针对以下各种数据源学习一种不同的查询语言：SQL 数据库、XML 文档、各种 Web 服务等等。 LINQ 使查询成为 C# 和 Visual Basic 中的一流语言构造。 您可以使用语言关键字和熟悉的运算符针对强类型化对象集合编写查询。 下图显示了一个用 C# 语言编写的、不完整的 LINQ 查询，该查询针对 SQL Server 数据库，并具有完全类型检查和 IntelliSense 支持。 在 Visual Studio 中，可以用 Visual Basic 或 C# 为以下数据源编写 LINQ 查询：SQL Server 数据库、XML 文档、ADO.NET 数据集，以及支持 IEnumerable 或泛型

Data 语义学 一个class的data members，一般而言，可以表现这个class在程序执行时的某种状态。Nonstatic data members放置的是“个别的class object”感兴趣的数据，static data members则放置的是“整个class”感兴趣的数据。 C++对象模型尽量以空间优化和存取速度优化的考虑来表现nonstatic data members，并且保持和C语言struct数据配置的兼容性。它们把数据直接存放在每一个class object之中。对于继承而来的nonstatic data members(不管是virtual还是nonvirtual base class)也是如此。不过没有强制定义其间的排列顺序。 至于static data members，则被放置在程序的一个global data segment中，不会影响个别class object的大小。在程序之中，不管该class被产生出多少个objects(经由直接产生或间接派生)，static data members永远只存在一份实例(甚至即使该class没有任何object实例，其static data members也已存在)。但是一个template class的static data members的行为稍有不同。 Data Member的绑定(The

　　 类的this指针有以下特点： 　　 （1）this只能在成员函数中使用。 　　全局函数、静态函数都不能使用this。 　　实际上，成员函数默认第一个参数为T* const this。 　　如： class A{public: int func(int p) {}}; 其中，func的原型在编译器看来应该是： int func(A* const this, int p); （2）由此可见，this在成员函数的开始前构造，在成员的结束后清除。 　　这个生命周期同任何一个函数的参数是一样的，没有任何区别。 　　当调用一个类的成员函数时，编译器将类的指针作为函数的this参数传递进去。如： A a;a.func(10); 此处，编译器将会编译成： A::func(&a, 10); 看起来和静态函数没差别，对吗？不过，区别还是有的。编译器通常会对this指针做一些优化，因此，this指针的传递效率比较高——如VC通常是通过ecx寄存器传递this参数的。 　　 （3）几个this指针的易混问题。 　　 1）this指针是什么时候创建的？ 　　this在成员函数的开始执行前构造，在成员的执行结束后清除。 　　但是如果class或者struct里面没有方法的话，它们是没有构造函数的，只能当做C的struct使用。采用TYPE xx的方式定义的话，在栈里分配内存

原文链接： https://blog.csdn.net/xuwentao37x/article/details/27804169 多线程的程序是出了名的难编写、难验证、难调试、难维护，这通常是件苦差事。不正确的多线程程序可能可以运行很多年也不出一点错，直到满足某些临界的条件时，才出现意想不到的奇怪错误。 不用说，编写多线程程序的程序员需要使用可能得到的所有帮助。这期专栏将专注于讨论竞争条件（race conditions）——这通常是多线程程序中各种麻烦的根源——深入了解它并提供一些工具来防止竞争。令人惊异的是，我们将让编译器尽其所能来帮助你做这些事。 仅仅一个不起眼的关键字。 尽管C和C++标准对于线程都明显的“保持沉默”，但它们以volatile关键字的形式，确实为多线程保留了一点特权。 就象大家更熟悉的const一样，volatile是一个类型修饰符（type modifier） 。它是被设计用来修饰被不同线程访问和修改的变量。如果没有volatile，基本上会导致这样的结果：要么无法编写多线程程序，要么编译器失去大量优化的机会。下面我们来一个个说明。 考虑下面的代码： 代码: class Gadget { public: void Wait() { while (!flag_) { Sleep(1000); // sleeps for 1000 milliseconds }

过程文件 后缀 含义 描述 .c 源文件 源代码 .o 源文件的目标文件 源代码预处理，编译和汇编后的二进制 .a 目标文件的归档文件 目标文件的打包，没有链接过程 .so 动态链接库文件 由目标文件或归档文件链接而成，没有程序入口，不能独立运行 .out 编译输出可执行文件 由目标文件或归档文件链接而成，有程序入口，可以独立运行 常用工具 工具 描述 gcc 通常用于完成预处理、编译、汇编、链接工作 (.c -> .o .so .out) ar 通常用于归档目标文件 (.o -> .a) 常用方法 1.生成可执行文件 gcc -o app.out main.c 2.生成动态库文件 gcc -fPIC -shared -o libfunc.so func.c 3.生成目标文件 gcc -c fun1.c fun2.c 4.生成静态库文件 ar rcs fun.a fun1.o fun2.o 常用选项 参数 描述 -I 指明头文件的包含路径 -L 指明静态库的包含路径 -l 指明静态库的名字 -Wl,-rpath= 指明运行时可以找到动态链接库的路径 -g 编译时产生调试信息 -Wall 生成所有警告信息 -On n=0~3 优化级别，-O3最高 -static 禁止使用动态库 -share 尽量使用动态库 -fPIC 产生与位置无关的代码 -c 激活预处理，编译和汇编 -o

如何判断栈的增长方向？ 对于一个用惯了i386系列机器的人来说，这似乎是一个无聊的问题，因为栈就是从高地址向低地址增长。不过，显然这不是这个问题的目的，既然把这个问题拿出来，问的就不只是i386系列的机器，跨硬件平台是这个问题的首先要考虑到的因素。 在一个物质极大丰富的年代，除非无路可退，否则我们坚决不会使用汇编去解决问题，而对于这种有系统编程味道的问题，C是一个不错的选择。那接下来的问题就是如何用C去解决这个问题。 C在哪里会用到栈呢？稍微了解一点C的人都会立刻给出答案，没错，函数。我们知道，局部变量都存在于栈之中。似乎这个问题立刻就得到了解答，用一个函数声明两个局部变量，然后比较两个变量的地址，这样就可以得到答案。 等一下，怎么比较两个变量的地址呢？ 先声明的先入栈， 所以，它的第一个变量的地址如果是高的，那就是从上向下增长。“先声明的先入栈”？这个结论从何而来？一般编译器都会这么处理。要是不 一般呢？这种看似正确的方法实际上是依赖于编译器的，所以，可移植性受到了挑战。 那就函数加个参数，比较参数和局部变量的位置，参数肯定先入栈。那为什么不能局部变量先入栈？第一反应是怎么可能，但仔细想来又没有什么不可以。所以，这种方法也依赖于编译器的实现。 那到底什么才不依赖于编译器呢？ 不妨回想一下，函数如何调用。执行一个函数时，这个函数的相关信息都会出现栈之中，比如参数、返回地址和局部变量