显卡带Ti并没有缺点，只是在原显卡上做了加强，英伟达的后缀命名规则如下：
GS:普通版或GT的简化版
GE:简化版，略微强于GS显卡GT标准版，比较常见的显卡版本。相对于GS要高个档次，GT没有缩减管线和顶点单元，目前无论是办公还是家用GT版本最为常用。GTS:介于GT和GTX鉴于之间的版本GT的加强版
GTX:(GT eXtreme)代表着最强的版本，极致版。
SE:和LE相似基本是GS的简化版最低端的几个型号LE(Lower Edition 低端版) 和XT基本一样，ATi也用过。
ZT:在XT基础上再次降频以降低价格。
XT:降频版，而在ATi中表示最高端。MX 平价版，大众类。
TI:(Titanium 钛)以前的用法一般就是代表了nVidia的高端版本。今意：高速加强版
TC:(Turbo Cache)可以占用内存的显卡
Ultra:在GF8系列之前代表着最高端，但9系列最高端的命名就改为GTX，超级版 。
GT2:eXtreme 双GPU显卡。
GX2:（GT eXtreme2）指两块显卡以SLI并组的方式整合为一块显卡，不同于SLI的是只有一个接口。
Go:用于移动平台。
Z:双芯加强版
GF：入门级
1. 部署简单Go
编译生成的是一个静态可执行文件，除了glibc外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础的系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。
2. 并发性好
Goroutine和channel使得编写高并发的服务端软件变得相当容易，很多情况下完全不需要考虑锁机制以及由此带来的各种问题。单个Go应用也能有效的利用多个CPU核，并行执行的性能好。
3. 良好的语言设计
从学术的角度讲Go语言其实非常平庸，不支持许多高级的语言特性但从工程的角度讲，Go的设计是非常优秀的：规范足够简单灵活，有其他语言基础的程序员都能迅速上手。更重要的是
Go 自带完善的工具链，大大提高了团队协作的一致性。
4. 执行性能好
虽然不如 C 和 Java，但相比于其他编程语言，其执行性能还是很好的，适合编写一些瓶颈业务，内存占用也非常省。
最近三年，在工作中使用go开发了不少服务。深感go的便捷，以及它的runtime的复杂。我觉得需要定期的进行总结，因此决定写这篇文章，也许更准确的，应该叫笔记。
最近终于解决了一个和cgo有关的问题。这个问题从发现到解决前后经历了接近4个月，当然，和人手不足也有关系。而对于我个人而言，这个问题其实历时2年！这得从头说起。
在上一家公司的一个项目里，有一个服务做音视频数据的提取，这个服务运行在嵌入式设备TX2上。音视频提取这一关键功能主要利用nvidia基于gstreamer开发的插件，这个插件可以发挥nvidia gpu的硬件解码功能。当时这个服务使用go和c混编的方式，问题的症状是服务运行一段时间后，不输出音视频数据。遗憾的是，由于疫情，项目停止，因此没有机会继续研究这个问题。
时间来到去年底。当前这个项目进行压力测试，发现关键的语音处理服务运行一段时间后，会出现不拉流的情况，因此也没有后续的结果输出。症状和上一个项目非常像。虽然使用的第三方SDK不一样，但同样用了go和c混编的方式。一开始，焦点就放在go的运行时上，觉得可能是go和c相互调用的方式不对。经过合理猜测，并用测试进行验证后，发现问题还是在第三方拉流的SDK上，它们的回调函数必须要快，否则有可能会阻塞它们的回调线程。当然，在go调用c的时候，如果耗时比较长，会对go的运行时造成一些副作用；在c回调go的时候，go的运行时也有可能阻塞c的回调线程。但go的运行时已经比较成熟，因此我觉得它对这个问题的贡献不大。以上采用了假设-验证的方法，主要的原因还是第三方的拉流SDK不开源。在定位问题的过程中，使用了gdb的gcore来生成堆栈；也搭建了灰度环境来进行压力测试，以及完善监控，这些都是解决方法的一部分。
正是这一问题，促使我更多的了解go的运行时。而我看得越多，越觉得go的运行时是一个庞大的怪物。因此，抱着能了解一点是一点的心态，不断的完善这篇笔记。
