司马刘的日志

当今信息化时代,计算机需要处理的信息量呈几何级数增加,但是由于 CPU 架构本身的局限,CPU 时钟频率提升已经遇到了瓶颈.而最初只作为图形处理的 GPU 的可编程性日益增加使得很多科学家开始使用 GPU 来运行通用的计算程序.今天我给大家简单介绍一下 GPU 以及 CUDA 架构.
为什么 GPU 适合做大规模并行计算?
GPU 当初设计就是用来做图形处理的,而图形处理本身就是高密度,高并行的计算.请看下图:

GPU 的计算单元非常密集,可以让多个线程在多个不同的计算单元上同时运行,而 CPU 上的进程切换是一个很耗资源的操作,进程内的多个线程共享一份内存和寄存器,CPU 上的多线程并行和 GPU 的多线程并行性能必定有很大的差距.但是 CPU 的复杂的指令流控制是 GPU 的弱项.所以目前大多采用若干个 CPU 和若干个 GPU 来构建大规模并行计算系统,应用程序的顺序部分在 CPU 上运行,计算密集型部分在 GPU 上运行.
CUDA 是什么?
简单来说 CUDA 就是通用的并行计算架构.包括硬件指令集和并行编程模型.请看下图:

目前应用程序可以通过 C 语言来使用 CUDA 架构,从而解决很多复杂的计算问题.其他的诸如 FORTRAN,C++,OpenGL 和 DirectX 等语言或者编程接口会陆续支持.
如何在 CUDA 的编程模型上开发并行运行的程序?
CUDA 编程模型扩展了 C 语言,可以使用扩展语法调用 C 语言定义的特殊函数(这种特殊函数称作 kernel).请看下面的代码:

当用 CUDA 扩展语法调用 kernel [...]

2009 年 11 月 29 日临晨 0 点 10 分左右打开 www.google.cn 出现了 502 错误,持续了几分钟……

这次应该不是实习生搞的吧?

有很多人都问过我如何优化 MySQL,苦于自己一直没有好好总结,总是不能有条理的讲出来,今天就来总结一下.
安装和配置
如果没有充分的理由请不要自己动手编译 MySQL,官网上提供的编译好的包就够用了, MySQL 文档中提出用 ICC 编译的 MySQL 性能要优于用 GCC 编译的.如果你的服务器是 Intel 架构,请下载用 ICC 编译的包.安装好了肯定是要做一些配置的,我通常都是用 MyISAM 表引擎的,所以只总结关于 MyISAM 的配置优化.MyISAM 主要有以下参数需要注意:

query_cache,开启 query_cache,MySQL 会缓存 SELECT 查询语句和查询结果,当遇到相同的查询语句时不用解析查询语句而直接返回查询结果.query_cache 在互联网应用中有不错的表现.
key_buffer_size,这个选项指定索引的缓冲区大小,适当增加这个选项的值会得到更好的索引处理性能.
sort_buffer_size,这个选项指定用于排序的缓冲区大小,适当增加这个选项可以提高 ORDER BY 和 GROUP BY 的效率.
read_buffer_size,这个选项指定扫描表时的缓冲区大小.

最后别忘记开启慢查询日志和没有使用索引的查询日志,这些日志在改善查询性能非常重要.
设计数据库/表
这绝对是个相当重要的环节,在开发过程中发现数据库设计不合理再返工绝对是要命的.MySQL 非常善于处理数字类型字段和固定长度类型字段,单表记录大于千万时性能表现不佳.所以我们设计数据库时最好遵循下面几条原则:

主键/唯一键/ORDER BY 字段/GROUP BY 字段使用数字类型字段
除非有必要,否则数字类型字段请用无符号数字类型
除非有必要,否则字符串类型字段请用 latin1_bin 编码方式
权衡选择固定长度类型和可变长度类型
预估一个表的记录数和字段数目,如有必要请横向/纵向拆分表
不要给字段设置 NULL 值
建立必要的索引

设计 SQL
很多开发人员觉得能写出很复杂,很酷的 SQL 是一件值得骄傲的事情,这里我要说的是”醒悟吧,孩子”.尽量用最简单的 SQL 来完成任务,如果你的 SQL 不能写的简单,那说明你的数据库设计的不合理.设计 SQL 也有一些原则:

SQL 只查询需要的记录的行/列
不要在列上作计算,数据库不是做计算用的,请在程序里想办法
尽量不要用 GROUP BY 和 JOIN
查询尽量能用到索引

在生产环境中观察
项目上线了,真正的烦恼才刚刚开始.MySQL 既然记录了日志,就经常看看,看看哪些 [...]

昨天晚上和老婆还有公司同事,朋友共16人去看传说中的<<2012>>,片子太长了,有2小时40分钟,看的实在很累啊.故事情节和老片子<<后天>>一个套路,没有太多吸引人的地方.
一个团队花了很久制作出壮观炫丽的特效,导演自己看了都觉得哪部分都不好咔掉,结果导致剧情有点拖沓,时间偏长.我觉得如果把情节稍微压缩一下,效果会更好.
引用一个朋友的话”40块钱看这么长一部电影,好实惠啊!”.

这本书是从定位角度讲产品营销的.其实我对这本书的兴趣不大,书后的”给你自己和你的职业定位”这部分内容是我最大的收获.如何从定位的角度成功推销自己呢?有这么几点:

任何值得一座的事情都值得去乱做一气,不要等到你能做得尽善尽美以后才去做
更加努力的工作很少会成为通往成功之路,干得更加聪明才是更好的办法
要选择好公司,上司,朋友,要独立思考,有信心

刚接到手机之家站内搜索 (项目名: batu, 基于 lucene 的站内搜索系统) 的时候真是有几天几夜没睡好,原因是这样的:
1) 有几位前人 hack 过这个项目的代码,代码结构和风格有很大差异;
2) 有部分逻辑是用 bash 脚本实现的,虽然是短短的 200 多行脚本,读起来真是很晦涩;
3) bash 脚本太多,部署非常麻烦;
4) 没有文档,小公司从来都是这样的.
代码大体浏览过一遍,开始定一个目标,大概是这样的:
1) 变量,函数命名标准化;
2) 减少脚本数量使部署更简单;
3) 各个子系统直接采用 socket 通信,而不是目前的写 FLAG 文件的方式;
4) 去掉 lucene 的 QueryParser,用各种子 Query  组装目标 Query;
5) 升级到最新版的 java NIO 框架 — monkey ;
目标定下来就开始写代码,除了一些工具类,其他代码基本都重写了,历时近两月.上周在生产机上部署 batu,没发现大的问题.新的 batu 优点如下:
1) 代码结构更清晰,变量名,方法名,文件名等更加规范,代码也更容易阅读和维护;
2)每台机器只要执行一个脚本就完成了部署工作,大大减轻了运维工作;
3)各个子系统采用 socket 通信,方便把各个子系统部署在不同机器,也降低了子系统直接的耦合;
在这两个月的开发过程中总结出来几点经验和大家分享:
1) 记详细的日志(log4j),便于跟踪代码的执行流程;
2) 做好自动化测试工具(脚本),代码改过后跑一下脚本看看日志就知道大概的情况了;
3) 制定小目标,逐步迭代,避免长时间闷头开发失去目标;
4) 遇到难题时主动向高人请教,别人稍微一指点或许你就茅舍顿开;
接手别人的代码真是”如人喝汤,冷热自知”啊.

我住的楼最高是24楼,我住18楼.今天中午吃饭后准备下楼,看电梯刚好停在18楼,但是上面显示的是10楼,不管它,直接上去关门.结果电梯迅速直上,大概遇到什么东西卡住了终于停下了.
怎么办?捶了几下门,把电梯里的所有按钮都按了一遍,还是没反应,当时很害怕,难道今天就死在这里了?我仿佛看到了摔得血肉模糊的司马刘.
在一个角落里发现紧急电话!”我困在电梯里了,!@#$%^&*”,过了很久(其实没几分钟),几个物业的人把我救出去了.出去看到电梯已经在24层之外了……
人类发明了电梯,可以很方便把人送到很高处,同时也把生命很轻易送到了高处.

今天是11月的第一天,早上起来觉得很冷,到阳台上一看,居然下雪了.