最近在思考改进项目中一模块的实现，该模块维护起来让我很是头疼，所有才有了整体换掉它的想法。设计和实现中利用了内存对齐的技术。关于内存对齐，我曾经写过三篇文章，第一篇介绍了计算内存对齐的方法和例子，第二篇说了一个内存对齐的应用；三谈内存对齐时，则从其本质上做了阐述，而这次实际上是继续在其本质上的做文章，结合本质谈谈为什么内存对齐的计算方法就应该是第一篇中所讲的那两条。

如果对内存对齐本质还不清楚的话，就看看我的内存对齐系列的第三篇吧。如果你清楚了本质，那么我们结合第一篇中交待的内存对齐计算方法来进一步探究，为什么计算的方法就是这个样子的。

再理解一下对齐系数/模数，众所周知Alignment module反映了CPU 取数据时对数据起始地址的限制-这个地址值必须能被Alignment module所整除，但继续仔细考虑下去，你会想到CPU在下一次取数据依然要从下一个能被Alignment module所整除的地址的地方去取，这显而易见，又能说明什么呢？如果说CPU第一次取数据的地址是first_read_address，那么连续下一次的地址就应该是first_read_address + Alignment module了，也就是说每次取数据的量就是Alignment module这么多，这样通过Alignment module我们又可以知道一个量，那就是：在Alignement module限制下，CPU一次能取Alignment module个字节；在“Data alignment: Straighten up and fly right”一文中作者也称之为"memory access granularity"。从应用层开发人员的角度理解：被访问变量的长度，就是CPU要去读取的字节数；而对齐系数又是限制CPU读取字节数的一个指标，有了这两个理解，解决下面的疑问就有了基础了。

在'也谈内存对齐'一篇中介绍了内存对齐的计算方法，这里不妨再引用一下：
1、数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员的对齐按照#pragma pack指定的数值和这个数据成员自身长度中，比较小的那个进行。
2、结构(或联合)的整体对齐规则：在数据成员完成各自对齐之后，结构(或联合)本身也要进行对齐，对齐将按照#pragma pack指定的数值和结构(或联合)最大数据成员长度中，比较小的那个进行。

疑问：对于数据成员对齐规则：为什么每个成员的对齐都要按照Min(指定对齐模数，数据成员自身长度)来确定呢？为了不用Max(指定对齐模数，数据成员自身长度)呢，用Max值对齐的不更加完美么？同样对于结构的整体对齐规则也一样有此疑问。这里我们还是举个例子更加直观：
#pragma pack(8)
struct Foo {
    char    a;
    int    b;
    short    c;
};
#pragma pack()
我们先来看数据成员对齐，以b为例子，按照规则的说法，sizeof(b) = 4 < 8，那么Address_of_b = Start_Address_of_Foo + 4; 我们来看看当应用的代码里访问b的时候，CPU做了些什么？Address_of_b一半情况下是不能被8整除的，在不能被8整除的情况下，我们去访问b，这里我要提两个问题：
1) 访问b的时候是否会因内存没有对齐到8上而触发core呢？(在Sun SPARC上因访问未对齐地址上的变量时会出core)
2) 为什么不将b放到Start_Address_of_Foo + 8这个地址上呢？

下面一一说说我的理解：
根据前面所说，程序在访问b的时候，CPU实际不一定是从Address_of_b这个地址上开始读取的。如果b这个地址恰巧既能被4整除，也能被8整除(如地址24)，那就无可厚非了。但是如果这个地址只能被4整除，而不能被8整除(如地址12)，那么此时CPU读取的地址肯定是从Address_of_b – 4开始读取8个字节的，也就是说实际上CPU都是从能被8整除的地址上读取的，而且一次读了8个字节，b所在的位置恰是这个8个字节中的后4个字节，所以不存在触发core的可能。

第二个问题，sizeof(b) = 4 < 8，为什么就要按照4而不是按照8去安排b的地址呢？我们不妨按照8去给b分配地址，Address_of_b' = Start_Address_of_Foo + 8，这样的话CPU也能一次将b读取，而且是从b的起始地址开始读，似乎更完美。但你看出问题了么？这么做浪费的空间显然大了很多。将b安排在Address_of_b'比安排在Address_of_b多浪费了一半空间。

同样整体对齐原则也是同样的道理。内存对齐计算显然有两个目标：一是减少CPU的访存次数；第二个就是还要保持存储空间的效率足够高。

随着工程代码量的增加，往往完整的编译一次Proj消耗的时间可能足够你喝两杯咖啡了，我现在build一次我所在proj的代码需要5分多钟，这是很痛苦的，颇让人懊恼的。为了解决这个工作中的别扭事儿，我在网上搜寻了一番，找到了distcc这个分布式编译工具。

先看看distcc能帮助我节省多少时间吧。我在公司的一台Sun SPARC Solaris9主机下对整个项目源代码按照以前的编译方式进行了一次build，这次build用了5分多钟；同样我使用distcc编译(安装了两个节点，都是Sun SPARC Solaris9主机)，居然只用了1分多钟，试想如何有更多的服务器作为distcc的守候进程主机节点的话，势必编译性能还会有提升。

有了"惊人"结果后，我们来看看distcc的原理，distcc本身是gcc的一个wrapper，也可用作本地编译，但是更多的是其分布式编译的强大功能，简单来说：就是将gcc的编译任务分布到各个其他主机上去，然后再传回来整合。它提高的是gcc -c阶段的速度，链接阶段的速度由于肯定要在本地实施，所以distcc无能为力。另外distcc推荐分布的不同主机上安装的编译器版本最好要一致，否则可能会有意想不到的错误。

distcc的安装和使用方法甚是简单，我安装的是distcc-2.13-sol9-sparc-local，直接在root下pkgadd即可。然后在各个distcc节点启动后台守候进程：distccd –daemon –allow x.x.x.x/16，以普通用户启动即可。

客户端使用方法：
1、在自己的用户下，添加环境变量(如果你用的是C shell)：setenv DISTCC_HOSTS 'localhost x.x.x.x'，代表本机和x.x.x.x上安装并启动了distccd
2、将你的makefile 中的CC=gcc改为CC=distcc gcc
3、make即可 。同样你还可以在make的-j参数选项，如make -j 12，这样在单机上进行多任务并行编译，使速度更快。
4、如果你想观察各节点上distcc的工作状态，可使用distccmon-text 2 命令查看distcc在各台主机上的任务快照。参数2代表：每隔2秒刷新一次。

Distcc理论上是可以部署在不同平台上辅助进行分布式编译的，但是在异构平台上分布需要一段时间设置和调试，我推荐还是尽量部署在同一类型平台上吧。有了distcc，我们的服务器的计算能力得到了充分的发挥，个人工作效率也会有所提高的，不知道长此下去喝咖啡的机会会不会被剥夺了:)