1.win10 + CUDA 9.0 + cuDNN 7.0 + tensorflow源码编译安装
2.使用protobuf实现序列化与反序列化
win10 + CUDA 9.0 + cuDNN 7.0 + tensorflow源码编译安装
在配置个人深度学习主机后，安装必备软件环境成为首要任务。使用Anaconda5.0.0 python3.6版本管理Win python环境，新建基于python3.5的tensorflow-gpu-py conda环境。直接使用conda安装tensorflow，会默认安装tensorflow-gpu 1.1.0并主动安装cudatoolkit8.0 + cudnn6.0。android 客户端源码若需配置CUDA环境，需自行下载并安装cuda9.0 + cudnn7.0，配置环境变量。pip安装tensorflow，会默认安装最新版本tensorflow-gpu 1.3.0。配置不当导致import tensorflow时报错：'ModuleNotFoundError: No module named '_pywrap_tensorflow_internal'。尝试源码编译tensorflow解决此问题。
查阅tensorflow官网文档，了解cmake window build tensorflow方法。文档中提到，tensorflow源代码目录下有详细网页介绍Windows环境编译方法，包含重要信息。发现安装tensorflow-gpu版本、fly论坛源码配置CUDA8.0 + cuDNN6.0/cuDNN5.1或CUDA9.0 + cuDNN7.0时，import tensorflow时报错。查阅错误信息，网上解答提及需要配置正确的CUDA和cuDNN版本。然而，尝试安装和配置后依然报错。安装tensorflow cpu版本无问题，确认CUDA环境配置错误。
决定源码编译tensorflow-gpu以解决问题。查阅文档，执行编译操作。在window环境下编译tensorflow源码，需要准备的软件包括Git、tensorflow源码、anaconda、swig、CMake、CUDA、网站源码混淆cuDNN、Visual Studio 。在百度网盘下载相关软件。
配置过程中，修改CMakeLists.txt以适应CUDA 9.0 + cuDNN 7.0。在cmake目录下新建build文件夹，执行命令配置tensorflow。配置后进行编译，遇到问题如：cudnnSetRNNDescriptor参数不匹配、网络访问问题、编码问题、protobuf库下载问题、zlib.h文件不存在、下载链接失败、无法解决的错误等。
为解决这些问题，采取相应措施，如修改cuda_dnn.cc文件、网站报表源码网络代理设置、文件编码转换、忽略警告信息、多次尝试下载、修改cmake配置文件等。遇到无法解决的问题，如CUDA编译器问题、特定源代码文件问题，提交至github tensorflow进行讨论。
完成源码编译后，安装tensorflow-gpu并进行验证。在下一步中继续讨论验证过程和可能遇到的后续问题。整个编译过程耗时、复杂，需要耐心和细心，希望未来能有官方解决方案以简化编译过程。
使用protobuf实现序列化与反序列化
protobuf是用来干嘛的？
protobuf是一种用于对结构数据进行序列化的工具，从而实现数据存储和交换。costex的源码（主要用于网络通信中收发两端进行消息交互。所谓的“结构数据”是指类似于struct结构体的数据，可用于表示一个网络消息。当结构体中存在函数指针类型时，直接对其存储或传输相当于是“浅拷贝”，而对其序列化后则是“深拷贝”。）
序列化：将结构数据或者对象转换成能够用于存储和传输的格式。 反序列化：在其他的计算环境中，将序列化后的数据还原为数据结构和对象。
从“序列化”字面上的理解，似乎使用C语言中的struct结构体就可以实现序列化的功能：将结构数据填充到定义好的结构体中的对应字段即可，接收方再对结构体进行解析。
在单机的不同进程间通信时，使用struct结构体这种方法实现“序列化”和“反序列化”的功能问题不大，但是，在网络编程中，即面向网络中不同主机间的通信时，则不能使用struct结构体，原因在于：
（1）跨语言平台，例如发送方是用C语言编写的程序，接收方是用Java语言编写的程序，不同语言的struct结构体定义方式不同，不能直接解析；
（2）struct结构体存在内存对齐和CPU不兼容的问题。
因此，在网络编程中，实现“序列化”和“反序列化”功能需要使用通用的组件，如 Json、XML、protobuf 等。
① 性能高效： 与XML相比，protobuf更小（3 ~ 倍）、更快（ ~ 倍）、更为简单。
② 语言无关、平台无关： protobuf支持Java、C++、Python等多种语言，支持多个平台。
③ 扩展性、兼容性强： 只需要使用protobuf对结构数据进行一次描述，即可从各种数据流中读取结构数据，更新数据结构时不会破坏原有的程序。
Protobuf与XML、Json的性能对比：
测试万次序列化：
测试万次反序列化：
protobuf 2 中有三种数据类型限定修饰符：
required表示字段必选，optional表示字段可选，repeated表示一个数组类型。
其中， required 和 optional 已在 proto3 弃用了。
protobuf中常用的数据类型：
下载protobuf压缩包后，解压、配置、编译、安装，即可使用protoc命令查看Linux中是否安装成功：
使用protobuf时，需要先根据应用需求编写 .proto 文件定义消息体格式，例如：
其中，syntax关键字表示使用的protobuf的版本，如不指定则默认使用 "proto2"；package关键字表示“包”，生成目标语言文件后对应C++中的namespace命名空间，用于防止不同的消息类型间的命名冲突。
然后使用 protobuf编译器（protoc命令）将编写好的 .proto 文件生成目标语言文件（例如目标语言是C++，则会生成 .cc 和 .h 文件），例如：
其中：
$SRC_DIR表示 .proto文件所在的源目录； $DST_DIR表示生成目标语言代码的目标目录； xxx.proto表示要对哪个.proto文件进行解析； --cpp_out表示生成C++代码。
编译完成后，将会在目标目录中生成xxx.pb.h和xxx.pb.cc文件，将其引入到我们的C++工程中即可实现使用protobuf进行序列化：
在C++源文件中包含xxx.pb.h头文件，在g++编译时链接xxx.pb.cc源文件即可：
在protobuf源码中的/examples 目录下有官方提供的protobuf使用示例：addressbook.proto
参考官方示例实现C++使用protobuf进行序列化和反序列化：
addressbook.proto :生成的addressbook.pb.h 文件内容摘要：add_person.cpp :
输出结果：
三种序列化的方法没有本质上的区别，只是序列化后输出的格式不同，可以供不同的应用场景使用。 序列化的API函数均为const成员函数，因为序列化不会改变类对象的内容，而是将序列化的结果保存到函数入参指定的地址中。
.proto文件中的option选项用于配置protobuf编译后生成目标语言文件中的代码量，可设置为SPEED， CODE_SIZE， LITE_RUNTIME 三种。 默认option选项为 SPEED，常用的选项为 LITE_RUNTIME。
三者的区别在于：
① SPEED（默认值）： 表示生成的代码运行效率高，但是由此生成的代码编译后会占用更多的空间。
② CODE_SIZE： 与SPEED恰恰相反，代码运行效率较低，但是由此生成的代码编译后会占用更少的空间，通常用于资源有限的平台，如Mobile。
③ LITE_RUNTIME： 生成的代码执行效率高，同时生成代码编译后的所占用的空间也非常少。 这是以牺牲Protobuf提供的反射功能为代价的。 因此我们在C++中链接Protobuf库时仅需链接libprotobuf-lite，而非protobuf。
SPEED 和 LITE_RUNTIME相比，在于调试级别上，例如 msg.SerializeToString(&str;); 在 SPEED 模式下会利用反射机制打印出详细字段和字段值，但是 LITE_RUNTIME 则仅仅打印字段值组成的字符串。
因此：可以在调试阶段使用 SPEED 模式，而上线以后提升性能使用 LITE_RUNTIME 模式优化。
最直观的区别是使用三种不同的 option 选项时，编译后产生的 .pb.h 中自定义的类所继承的 protobuf类不同：
① protobuf 将消息里的每个字段进行编码后，再利用TLV或者TV的方式进行数据存储； ② protobuf 对于不同类型的数据会使用不同的编码和存储方式； ③ protobuf 的编码和存储方式是其性能优越、数据体积小的原因。
