上面简单的例子说明系统将花费非常多的时间去移动数据。hello程序对应的机器指令最初存储在硬盘中，
当程序被加载时它们被复制到内存中，当处理器调用这段程序，指令被从内存中复制到处理器。相同的，
"hello world!"这段字符串数据最初存在硬盘中，然后被复制到内存中，最终从内存中被复制到显示设备。
从程序设计者的角度出发，复制数据与代码的开销会减慢程序运行的速度。所以，系统设计最大的目标
是使复制操作的速度尽可能的快。
由于物理规则限制，空间越大的存储设备将比较小的存储设备更缓慢。
但是快速的存储设备相比缓慢的设备更加昂贵。比如，硬盘通常比内存大1000倍，
但是读取同样的数据会比用内存的时间长100万倍。
同样，一个典型的寄存器文件只能存储几百字节数据，而内存能够存储十亿字节。
然而，处理器从寄存器中读取数据比从内存中读取快近100倍.令人沮丧的是，随着
半导体技术的发展，使处理器运行的更快比让内存运行更快来得更简单更便宜。
为了应对处理器与内存速度之间的差距问题，更小更快的缓存被设计出来作为临时存储
区域，专用于存储那些处理器马上要用到的数据。
上面这道题非常简单，即使是笔算，要表达二进制n次方也不过就是在1后面加n个零，然后转为16进制即可，
比如2的3次方，二进制表示就是1000，十六进制与十进制都是8。
写了两个LISP的小程序，来做这道简单的题，代码如下：
#lang racket
(define (f x count)
(if (= x 1)
count
(f (/ x 2) (+ 1 count))))
(f 16384 0)
(define (f2 x tem count)
(if (= 0 count)
tem
(f2 x (* tem x) (- count 1))))
(f2 2 1 19)
lisp太偏门，估计没几个人愿意看，但写c语言又得开个虚拟机，看个书搞这么麻烦没必要，题也简单，就这么对付一下，而且说回来，c语言写这个程序也差不多一样，参数都不用变。
哦对，这些进制都是给人看的，在内存里表示都一样，所以，真正编程时，只是输入的进制不同，实际上计算机自己会做转换，让它显示什么进制他也都会显示，一丁点编程技巧都用不上，障眼法而已，很多人都会被这种问题困扰，没有必要。
Practice Problem 2.4 (solution page 180)
Without converting the numbers to decimal or binary, try to solve the following
arithmetic problems, giving the answers in hexadecimal. Hint: Just modify the
methods you use for performing decimal addition and subtraction to use base 16.
A. 0x605c+ 0x5 =
B. 0x605c− 0x20 =
C. 0x605c+ 32 =
D. 0x60fa − 0x605c =
又有一道题，小学加法题，后面的题不知道会不会难一些，一直这样的题恐怕要睡着了。
说起字节序，突然想起11月5日在看“Kathiravelu P., Sarker F. - Python Network Programming Cookbook, Second Edition - 2017”这本书的时候，遇到了一个问题，当时自认为很明白字节序，但事实证明还是被搞
晕，这道题是这样的
Listing 1.5 shows integer_conversion as follows:
#!/usr/bin/env python
# Python Network Programming Cookbook, Second Edition -- Chapter - 1
# This program is optimized for Python 2.7.12 and Python 3.5.2.
# It may run on any other version with/without modifications.
import socket
def convert_integer():
data = 1234
# 32-bit
print ("Original: %s => Long host byte order: %s, Network byte order:
%s" %(data, socket.ntohl(data), socket.htonl(data)))
# 16-bit
print ("Original: %s => Short host byte order: %s, Network byte order:
%s" %(data, socket.ntohs(data), socket.htons(data)))
if __name__ == '__main__':
convert_integer()
If you run this recipe, you will see the following output:
$ python 1_5_integer_conversion.py
Original: 1234 => Long host byte order: 3523477504,
Network byte order: 3523477504
Original: 1234 => Short host byte order: 53764,
Network byte order: 53764
能看到1234是在机器上由cpu读取的数据，而将要发送到网络中的数据，在cpu读取时，应该是53764。显然
字节序应该是改变了，这由于一般的机器都是小端机，所以字节的排列与正常读取的方式正好相反，低位在
低位，高位在高位。
比如1234的十六进制是04D2，那么在小端机的内存中应该写成D204,这是小端机的字节序，但是呢，网络中
要求传输的字节序为大端序，所以应该发送的字节顺序应该是04 D2 ,这就要求小端机在内存中把顺序先整理好，于是小端机的确在低位字节上写入了04 高位写上了D2，但这个数据由小端机CPU读取时可就成了D204,
这个D204是多少呢？
怎么样，会不会被绕晕啊，其实D204这玩意正过来反过去都是在说那个十进制的1234，只是一正一反，来回
两次就容易把人搞晕，当然，这里说的字节序还对应着bit序，那个玩意不被感知，所以一般不用管，其原因是在网络传输中，字节序是大端的，而bit序是小端的，所以只用转换字节序即可，当然在大端机上，就需要转换bit序喽。
推荐一个国外的帖子，专门讲cpu处理bit序与byte序的事情，相当的好,国内也有一个，讲的也不错，但是其中有一幅图画的有问题，什么问题就得真的理解后才能指出，
放心，只要是真的懂了，那一定是能看出来的。
为了想起这道题在哪看到几乎用了一个上午，直到查了浏览器的历史纪录，才想起看的是这本python书，
看来以后有必要把每天看了什么书都做一个汇总，万一偶尔碰到重要的问题，缺因为记性差想不起来，
那可实在是不爽。
