公司大佬用cudnn写了一个推理库，用于做背景分割。新到一台用于做测试的服务器，但sre和it都不管我，而我又是集成这个cudnn的人。所以只能自己亲自上，淡然还有大佬的帮助下成功安装了系统和驱动。
准备工作，一个新安装的ubuntu server 18。
下载好驱动、cuda、cudnn、tensorrt：
NVIDIA-Linux-x86_64-418.165.02.run
cuda-repo-ubuntu1804-10-1-local-10.1.243-418.87.00_1.0-1_amd64.deb
cuda-ubuntu1804.pin
libcudnn7_7.6.5.32-1+cuda10.1_amd64.deb
libcudnn7-dev_7.6.5.32-1+cuda10.1_amd64.deb
nv-tensorrt-repo-ubuntu1804-cuda10.1-trt6.0.1.5-ga-20190913_1-1_amd64.deb
其中需要注意的是，除了显卡驱动，其他部分都要下deb包，否则会出现打不上的情况。
然后按照教程的路线，执行dkpg -i和api install就好
首先，我是一个完全的linux开发初学者，我仅仅在windows做开发，由于兴趣与工作的缘故碰到了通过已有的socket模型搭建好的网络库。下面就说说在windows下，我了解到socket模型（准确是标准socket模型，对于微软封装过的一些模型我不是很清楚）
1，普通阻塞是socket：
普通的socket模型，就是msdn中对socket api族介绍中最简单的那个例子。这种最简单，在执行效率上相对较低，在处理send/recv（sendto/recvfrom）时，函数是处于阻塞的。在简单环境，或者写一些简单的测试工具时，这是一种比较理想的用法。
2，同步 select模型
同步select模型，其实可以是理解为普通阻塞式sokcet的一个扩展，就是利用select来对socket句柄进行监听，避免由于调用send/recv（sendto/recvfrom）时出现阻塞。
3，异步select模型
异步select模型，可以看成是同步select的一种变化。即send/recv（sendto/recvfrom）函数不会阻塞，调用立即返回，并需要同时配合select函数一同使用。
4，IOCP
异步IO模型，使用上可以和异步select模型类比；但这并非标准socket模型。
然后接下来再说一下几个模型的差别：
1，普通socket、select模型，在调用send/recv（sendto/recvfrom）函数时，均会出现一次多余的内存拷贝。即，用户态传如一个buffer时，在转为交给协议栈之前，必须通过内存拷贝的方式，将数据复制到内核态的内存中。
2，windows上select集合最大值大约是64/128（有系统版本决定）；换句话说一个调用select函数的线程，最大可监听64/128个socket句柄
*3，据网上各种文档介绍到，select是基于内核态线程轮询完成，具体不详，有待考证！
4，IOCP 和其他几者最大区别在于内存拷贝上，由于IOCP是通过共享内存（即内存映射）。在windows中内存映射属于一个特殊的内存管理器的管辖范围，他即不属于内核态，也不属于用户态内存，当对于内核态或用户态线程来说，只要通过调用内存映射函数，就可以直接访问这块内存（但得到的逻辑地址或许是不同的）。
由于在WSARecv/WSASend之类函数中，提交的均为共享内存，因此无需做任何内存拷贝。所以在IOCP上，性能要更好的多。同时本人的了解范畴也仅限于这一块，对于IOCP的事件投递过程并不是很清楚，但根据《软件调试》一书中对“windows系统调试/windows软件调试”设计的讲述来看，IOCP这种的实现应该是在内核态也同样创建了和用户态以之对应的内核服务线程。
接着再说说linux，刚刚看了一下epoll的介绍。
发现epoll是基于事件回调+内存映射来实现IO上的高效；同时这篇文章也还介绍了几个常用的socket模型在linux中的大概实现。通过这篇文章至少能够看出，linux和windows在对socket的实现上存在很大的相似。
可见linux和windows存在很多相似的地方，如果linux和windows互相对应着学，理解起来可能会快很多。