今天在桑椹那里看到了一留言, 在一篇说spam的帖子下面。 帖子大概是这样。
根据 dashboard 里面的统计,桑林志总共有 4,101 个留言与引用,而写这个帖子的时候最新一个留言的编号为 28055,所以桑林志总共已经有过约 24000 个垃圾留言或引用。真实留言或引用与垃圾留言或引用的比例为:1:6。
下面有个留言很搞笑。
呵呵, 我不小心也帮这个品牌spam了一把。 听了chedong的建议, 还是不给人免费spam了, 所以给建议人和自己spam一把:)
今天在桑椹那里看到了一留言, 在一篇说spam的帖子下面。 帖子大概是这样。
根据 dashboard 里面的统计,桑林志总共有 4,101 个留言与引用,而写这个帖子的时候最新一个留言的编号为 28055,所以桑林志总共已经有过约 24000 个垃圾留言或引用。真实留言或引用与垃圾留言或引用的比例为:1:6。
下面有个留言很搞笑。
呵呵, 我不小心也帮这个品牌spam了一把。 听了chedong的建议, 还是不给人免费spam了, 所以建议人和自己spam一把:)
今天在桑椹那里看到了一留言, 在一篇说spam的帖子下面。 帖子大概是这样。
根据 dashboard 里面的统计,桑林志总共有 4,101 个留言与引用,而写这个帖子的时候最新一个留言的编号为 28055,所以桑林志总共已经有过约 24000 个垃圾留言或引用。真实留言或引用与垃圾留言或引用的比例为:1:6。
下面有个留言很搞笑。
呵呵, 我不小心也帮这个品牌spam了一把。
今天在桑椹那里看到了一留言, 在一篇说spam的帖子下面。 帖子大概是这样。
根据 dashboard 里面的统计,桑林志总共有 4,101 个留言与引用,而写这个帖子的时候最新一个留言的编号为 28055,所以桑林志总共已经有过约 24000 个垃圾留言或引用。真实留言或引用与垃圾留言或引用的比例为:1:6。
下面有个留言很搞笑。
呵呵, 我不小心也帮这个品牌spam了一把。
今天在桑椹那里看到了一留言, 很牛。 在一篇说spam的帖子下面。 帖子大概是这样。
根据 dashboard 里面的统计,桑林志总共有 4,101 个留言与引用,而写这个帖子的时候最新一个留言的编号为 28055,所以桑林志总共已经有过约 24000 个垃圾留言或引用。真实留言或引用与垃圾留言或引用的比例为:1:6。
下面有个留言很搞笑。
呵呵, 我不小心也帮这个品牌spam了一把。
今天在桑椹那里看到了一留言, 很牛。 在一篇说spam的帖子下面。 帖子大概是这样。
根据 dashboard 里面的统计,桑林志总共有 4,101 个留言与引用,而写这个帖子的时候最新一个留言的编号为 28055,所以桑林志总共已经有过约 24000 个垃圾留言或引用。真实留言或引用与垃圾留言或引用的比例为:1:6。
下面有个留言很搞笑。
呵呵, 我不小心也帮这个品牌spam了一把。
最近要重写一个迭代的算法, 教授告诉我去改进这个code, 让他跑的更快, 但是改起来工程似乎太大。 今天和猛哥相谈的时候, 他说其实工作量不太大, 根据他的经验, 在他的几万行的floorplan程序中, 真正费时间的核心部分大概只有几百行。 大概十个函数左右的时间就能够占到全部运行时间的90%以上。 猛哥推荐了一个GNU 的 Profiler, 说这个很好使, 可以找出每个模块(函数)的运行时间, 以及比例。 说他在NEC用了这个十多年了, 很喜欢, 还是不要钱的…… 命令叫gprof, 基本每个*nix机器上都会有。 查了一下, 这里有个不错的介绍入门文章 。
一般运用
一般的应用其实很简单, 在用GCC编译的时候加上-pg的选项, 然后按照正常的参数运行你的程序。 运行完了以后就会在当前目录底下生成一个叫gmon.out的文件。 然后用gprof yourExcutable gmon.out -p就可以了。 一般会用>log将其写到log中。 p选项是flat profiling, 会显示各个函数具体的执行时间和所占的比例, 明显后者对帮你找出消耗时间的大头比较有用。 由于是在编译的时候加pg选项,许多调用c运行时库的函数都会被忽略。因为这些库编译的时候都是没有加上pg选项的。 (libc.so) 用gprof的q选项,可以打印函数的调用图。 如果想要在输出的分析中看到相应的源码, 需要在编译的时候加上pg和debug的g选项, 在运行gprof的时候用A选项, 就可以看到Annotated source。
库的支持
有的系统会提供用pg编译的库,(ibc_p.a)。 需要在USE flags中加入profile, 然后再re-emerge glibc,这时在/usr/lib/libc_p.a就可以看到libc_p.a。 如果不支持, 你就需要重新用上pg选项重新编译你的glibc了。
kernal时间和用户时间
如果你的程序中有诸如sleep这样的kernal space的函数, 你的那些函数的运行时间比例可能会都是0, 因为与sleep时间相比, 他们差不多可以忽略。 这个时候最好之前先用time命令看看real,sys,user时间的比例, 看看能不能用上gprof。
另外感觉是man, info了半天看了好多, 还是不知道怎么用, 要在那个里面迅速找出有用的信息, 简单的用用, 对我还真是不容易。 看别人写的介绍要容易很多。 其实大部分时候大多数的人就是要用最简单的功能, 复杂的功能一般人也用不上。 这种时候几个例子就足够了,而这好像是man,info所缺少的。 写那么长那么多页确实也不容易, 但是看起来也辛苦啊…… 大家看man有什么心得吗?
但是, 这里feed的毛病刚好, 评论现在好像又不行了, 要评论就写信给我吧, 我来update出来。:) (这真是个烂办法) 我的gmail邮箱是biantaishabi, 当然也是gtalk。
最近要重写一个迭代的算法, 教授告诉我去改进这个code, 让他跑的更快, 但是改起来工程似乎太大。 今天和猛哥相谈的时候, 他说其实工作量不太大, 根据他的经验, 在他的几万行的floorplan程序中, 真正费时间的核心部分大概只有几百行。 大概十个函数左右的时间就能够占到全部运行时间的90%以上。 猛哥推荐了一个GNU 的 Profiler, 说这个很好使, 可以找出每个模块(函数)的运行时间, 以及比例。 说他在NEC用了这个十多年了, 很喜欢, 还是不要钱的…… 命令叫gprof, 基本每个*nix机器上都会有。 查了一下, 这里有个不错的介绍入门文章 。
一般运用
一般的应用其实很简单, 在用GCC编译的时候加上-pg的选项, 然后按照正常的参数运行你的程序。 运行完了以后就会在当前目录底下生成一个叫gmon.out的文件。 然后用gprof yourExcutable gmon.out -p就可以了。 一般会用>log将其写到log中。 p选项是flat profiling, 会显示各个函数具体的执行时间和所占的比例, 明显后者对帮你找出消耗时间的大头比较有用。 由于是在编译的时候加pg选项,许多调用c运行时库的函数都会被忽略。因为这些库编译的时候都是没有加上pg选项的。 (libc.so) 用gprof的q选项,可以打印函数的调用图。 如果想要在输出的分析中看到相应的源码, 需要在编译的时候加上pg和debug的g选项, 在运行gprof的时候用A选项, 就可以看到Annotated source。
库的支持
有的系统会提供用pg编译的库,(ibc_p.a)。 需要在USE flags中加入profile, 然后再re-emerge glibc,这时在/usr/lib/libc_p.a就可以看到libc_p.a。 如果不支持, 你就需要重新用上pg选项重新编译你的glibc了。
kernal时间和用户时间
如果你的程序中有诸如sleep这样的kernal space的函数, 你的那些函数的运行时间比例可能会都是0, 因为与sleep时间相比, 他们差不多可以忽略。 这个时候最好之前先用time命令看看real,sys,user时间的比例, 看看能不能用上gprof。
另外感觉是man, info了半天看了好多, 还是不知道怎么用, 要在那个里面迅速找出有用的信息, 简单的用用, 对我还真是不容易。 看别人写的介绍要容易很多。 其实大部分时候大多数的人就是要用最简单的功能, 复杂的功能一般人也用不上。 这种时候几个例子就足够了,而这好像是man,info所缺少的。 写那么长那么多页确实也不容易, 但是看起来也辛苦啊…… 大家看man有什么心得吗?
但是, 这里feed的毛病刚好, 评论现在好像又不行了, 要评论就写信给我吧, 我来update出来。:) (这真是个烂办法) 我的gmail邮箱是biantaishabi, 当然也是gtalk。
最近要重写一个迭代的算法, 教授告诉我去改进这个code, 让他跑的更快, 但是改起来工程似乎太大。 今天和猛哥相谈的时候, 他说其实工作量不太大, 根据他的经验, 在他的几万行的floorplan程序中, 真正费时间的核心部分大概只有几百行。 大概十个函数左右的时间就能够占到全部运行时间的90%以上。 猛哥推荐了一个GNU 的 Profiler, 说这个很好使, 可以找出每个模块(函数)的运行时间, 以及比例。 说他在NEC用了这个十多年了, 很喜欢, 还是不要钱的…… 命令叫gprof, 基本每个*nix机器上都会有。 查了一下, 这里有个不错的介绍入门文章 。
一般运用
一般的应用其实很简单, 在用GCC编译的时候加上-pg的选项, 然后按照正常的参数运行你的程序。 运行完了以后就会在当前目录底下生成一个叫gmon.out的文件。 然后用gprof yourExcutable gmon.out -p就可以了。 一般会用>log将其写到log中。 p选项是flat profiling, 会显示各个函数具体的执行时间和所占的比例, 明显后者对帮你找出消耗时间的大头比较有用。 由于是在编译的时候加pg选项,许多调用c运行时库的函数都会被忽略。因为这些库编译的时候都是没有加上pg选项的。 (libc.so) 用gprof的q选项,可以打印函数的调用图。 如果想要在输出的分析中看到相应的源码, 需要在编译的时候加上pg和debug的g选项, 在运行gprof的时候用A选项, 就可以看到Annotated source。
库的支持
有的系统会提供用pg编译的库,(ibc_p.a)。 需要在USE flags中加入profile, 然后再re-emerge glibc,这时在/usr/lib/libc_p.a就可以看到libc_p.a。 如果不支持, 你就需要重新用上pg选项重新编译你的glibc了。
kernal时间和用户时间
如果你的程序中有诸如sleep这样的kernal space的函数, 你的那些函数的运行时间比例可能会都是0, 因为与sleep时间相比, 他们差不多可以忽略。 这个时候最好之前先用time命令看看real,sys,user时间的比例, 看看能不能用上gprof。
另外感觉是man, info了半天看了好多, 还是不知道怎么用, 要在那个里面迅速找出有用的信息, 简单的用用, 对我还真是不容易。 看别人写的介绍要容易很多。 其实大部分时候大多数的人就是要用最简单的功能, 复杂的功能一般人也用不上。 这种时候几个例子就足够了,而这好像是man,info所缺少的。 写那么长那么多页确实也不容易, 但是看起来也辛苦啊…… 大家看man有什么心得吗?
今晚遇到学校的一个泰国人。 小伙挺高挺白, 会说英文, 日文也挺好, 而且对学中文比较有兴趣, 还会写好多繁体的中国字。 结果导致好奇的我问他泰文的问候语怎么说, 他告诉我读音是chao, 我问早上好呢? 他说也是chao。 中午呢?也是chao。 那么晚上呢? 还是chao。 而且说法是先是chao, 后面加人名。 比如给我打招呼就是 :chao 王博!
旁边的一个中国女生首先受不了啦, 说你们怎么从早上chao到晚上啊。 这个时候我这个纯洁的男人才反应过来。 晚上回来和reika说起这个泰语的早中晚问候, 她说,从早到晚, 泰国人牛比ね……并且告诉我西班牙语的问候也是差不多的读音。 不知道是不是真的。 后来告诉泰国人这个近音字的中文意思, 泰国人竟然很有学术精神的问,这从语言的发展上来看是概率很小的事情啊, 泰国和中国隔这么近, 不可能有意思查这么远的词吧? 后来又解释了一下中国的地大物博, 各种F words也分南北, 他才满意的点头, 然后坏笑, 对我说 : chao, 王博!