代码移植性与高效性的折衷 ——linux舍高效率而取移植性
2015-03-26 青岛 张俊浩
任何高级语言编写的代码最终都会转化为硬件门电路的空间上的组合逻辑和时间上的时序逻辑，同样所有的硬件门电路的空间上的组合逻辑和时间上的时序逻辑都可以用高级语言来描述 、设计~
我们通过软件设计来去发挥硬件平台的性能，甚至是想去榨干硬件平台的所有优势~其实对于编程经验少，或者项目开发经验少的人，谈到代码的可移植性没什么感觉，更不要说在代码的可移植性和高效性上寻找折衷的方案~我们只能通过前人的经验、思考去体会这种纠结~
软件的开发过程中或者说代码的编写过程中，每个选择意味着妥协。程序员总是要在一大堆方案中做出取舍，尽量满足那那些往往自相矛盾的目标。其中程序员面对的一个艰难的选择就是：高效率和可移植性。因为高效率往往导致代码的不可移植，而选择可移植性却又会让软件的性能不那么尽如人意~对于高效率和可移植性我们思考如下这几点。
一、高效性是指什么？（或者说高效性意味着社么？或者说软件的高效性来自哪里？）
高效性软件会充分利用硬件平台自身独特的优势，将其发挥到淋漓尽致。比如，它会利用一些平台独有的硬件功能，图形加速器、高速缓冲存储器、专用的浮点指令.............
二、移植性是指什么？（或者说为什么会有移植性？或者说我们为什么要考虑代码的移植性？）
“移植性”的同义词，我认为是“通用性”、“一般性”，意味着我们的代码经过处理后，可以运行在不同的硬件平台，同样也意味着我们的代码在再利用不同硬件平台或者项目的共性（很自然，万物皆有共性，包括我们的处理器），这样可能意味着我们要舍弃某些硬件平台独有的优势资源而采用不同硬件的通用资源，这必然会导致我们无法利用某些硬件独有的优势资源，而相对地降低软件在相应硬件平台的效率~
三、我们为什么会倾向于选择移植性相对于高效率？（或者说linux为什么舍高效率而取可移植性？）
我们考量的天平向可移植性这端倾斜的原因，我认为有两个。
【1】对于不同硬件平台：如果我们的软件只能运行在一种体系架构上，其潜在的市场竞争、受众会大打折扣~
【2】对于同种硬件平台：半导体设计世界的动向令人目不暇接，芯片的升级换代周期日益缩短。提高整个系统的性能，除了从软件方面优化系统外，还可以不断提高硬件平台的性能。随着硬件平台的不断升级换代，问题的关键已不在是软件是否充分利用硬件优势，而是软件能否运行在更新的硬件平台上。我们软件的费尽心思的优化，可能还不不足以硬件平台小小的升级，所以具备可移植性的软件才能利用下一款超级计算机的优势。软件无法快速（市场竞争原因）移植到新的平台上，它就无法存活。
四、移植性的两个例子的思考——UNIX和Makefile
(1)UNIX
人们为UNIX的可移植性感到感叹！Thompson最早使用汇编语言编写Unix。1972年，它采用B语言这种具有可移植性的编程语言改写了代码。很明显他可能是想利用不断涌现的新硬件的优势。1973年另一位AT&T公司贝尔实验室的成员Dennis Ritchie对B语言进行了扩展和调和调整，将其发展成今天全世界程序员为之爱恨交加的C语言~
Unix作为第一个可移植系统开创先河~
(2)Makefile
【1】什么是Makefile？
Makefile是Linux下工程管理工具GNU make的配置文件，GNU make通过解析工程项目的编译配置文件Makefile来编译整个项目工程（详见GNU make使用手册~）。
【2】Makefile为什么可以具有可移植性、通用性？
GNU make手册，或者其他讲解make、Makefile的书籍、论坛大都在讲解Makefile的语法、规则、模式，变量和各种通配符的使用，教我们增加Makefile的简洁性和可移植性。自己也在这些书籍、论坛、Makefile源码的磨练之下也经历了从无知到有知的过程（现在仍在各种规则、符合的记忆和遗忘做痛苦斗争~）。但今天想问一个问题，为什么Makefile具有可移植性？
GNU make是在lLinux下用来管理源码项目工程的管理工具，Makefile相对于源码工程编译规则、流程的配置文件。不同的项目工程，目的、功能、内容、源码目录结构、源文件不同，但都是项目工程，其管理、编译流程有其通用性、一般性，这奠定了管理工具GUN make或者Makefile具有一般性~
进一步，为什么C语言或者说高级编程语言相对于机器语言具有可移植性？机器指令是跟具体硬件平台相关的，不同硬件平台的机器指令集不同，但是不同硬件平台也有其共性。计算机组成也逃不出处理器、存储器、输入出入基本组成，机器指令也不外乎数据的传输、数据的算术/逻辑运算，所以硬件平台的共性，或者说计算机的特点决定了高级语言可以跨平台，具备可移植性~
