スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

无聊地八卦一下

最近被喷到飞起的那个天河一号,这里有这玩艺的具体资料:

http://server.ccw.com.cn/yjzx/htm2009/20091029_829469.shtml

"天河一号的硬件系统包含:计算阵列、加速阵列、服务阵列,以及互连通信子系统、I/O存储子系统和监控诊断子系统等。其计算阵列共有2560个计算结点 ;每个计算结点集成2个Intel CPU,配32GB内存。加速阵列共有2560个结点;每个加速结点含2个AMD GPU、 2GB显存。"

这机器号称的能力是1206TFlops。是怎么来的呢?首先看CPU的部分,它有2560个双路CPU节点。我们拿中科院的深腾7000来比较一下,后者有1140个双路CPU刀片节点。这两者的节点配置应该很相似。深腾的理论能力是100TFlops出头,里面还加上了38个16路CPU的厚节点(大约刀片节点的1/4运算能力)和一组Itanium2胖节点的能力(5T Flops,可以忽略)。所以如果把深腾的集群规模扩大一倍,大约就等于天河的集群部分,运算能力撑死了200TFlops。

那剩下的一千Flops怎么来的呢?这当然就是那5000个AMD(不是ATI,记者同学,ATI已经不存在了)GPU的功劳了。一颗RV770理论上就有1T的FLOPs(单精度),所以5000个的话是5000T Flops(单精度),对RV770,双精度浮点能力大约是单精度的1/4还是1/5,于是正好1000TFlops,完全没作假。

现在的问题是,在GPGPU计算领域,AMD的Brook+远没有NV的CUDA来得普及,而且就算是后者,应用都还是相当有限。所以几乎可以认为,这5000个GPU在很长时间内都会是光耗电不办事的摆设。至于为什么不用NV而用AMD,这里不比较brook+和CUDA的优劣;但请注意一点,NV的半速双精度的GT300还没量产,现有的GPU的双精度能力只有单精度的1/17,而且NV的1T Flops(单精度)的成本和AMD比起来高了一个档次。所以如果用NV的芯片,这机器在纸面上都没办法挤进Top10。这已经是一个足够强的理由了吧。

当然你可以说,也许这机器能促进国内GPGPU计算研究的发展,在Brook+体系上产生一些好的应用出来。问题是……先买硬件然后再研究配套的软件……这种事例……真的有过么?

最后稍微比较一下Roadrunner和这玩艺。Roadrunner的运算能力主要来自于IBM的Cell处理器,就算架构上你可以对power 有这样那样的抱怨,人家至少是个CPU,不是GPU。所以只是因为FLOPs就拿来比较的话,就和把手砍了顶在头顶上然后说“看,我和你一样高”类似的可笑。

主题 : 最新パソコン
分类 : コンピュータ

M$又耍笨了啊……

之前配置2003的DNS的转发器,将google.com转发到opendns,于是查询docs.google.com的时候得到结果:

-> docs.google.com
canonical name = writely.l.google.com
ttl = 86246 (23 hours 57 mins 26 secs)
-> writely.l.google.com
internet address = 74.125.19.113
ttl = 55 (55 secs)
-> writely.l.google.com
internet address = 74.125.19.139
ttl = 55 (55 secs)
...(下略)

可以看到CNNAME的TTL比其它的记录长很多。于是出现了一个非常郁闷的事情:

当其它的记录都已经过期之后,DNS server里面还保留有docs.google.com的CNNAME记录writely.l.google.com,于是下次查询的时候,它就不再去查询opendns而是直接直接查询负责writely.l.google.com的那个DNS服务器(72.14.203.9)了,然后下一次查询的时候结果就全变了:

-> docs.google.com
canonical name = writely.l.google.com
ttl = 84953 (23 hours 35 mins 53 secs)
-> writely.l.google.com
canonical name = writely-china.l.google.com
ttl = 595 (9 mins 55 secs)
-> writely-china.l.google.com
internet address = 64.233.189.113
ttl = 175 (2 mins 55 secs)

(因为CDN的缘故,72.14.203.9会根据查询者的IP范围来响应)

我被这个问题折腾了两天,开始的时候是想设置dns server的缓存策略让那个TTL太长的别名早点挂掉。但M$ DNS根本没有这样的设置选择。绝望到几乎想上bind9的时候我终于发现……

M$ DNS的条件转发器似乎只会匹配一层的域名,也就是说,docs.google.com会匹配到负责google.com域的转发器,但是,writely.l.google.com就不会……

于是把l.google.com加进转发器里,这回,万事OK,耶!

标签 : 网络 DNS服务 EP
主题 : インターネットサービス
分类 : コンピュータ

Privoxy的好处

1 它在默认配置下就具有一定的adblock能力,而且实际上访问控制能力比FF插件之类的东西的扩展性和定制性更强(比如可以支持页面重定向),并对所有浏览器透明(代理嘛)。

2 可以记录所有http/https访问的踪迹,这在和GFW对抗的时候有时意外的有用。

3 自定义脚本里面将direct指向变成代理指向之后,可以解决IE的一些古怪问题(比如IE8的建议网站功能……我好像太EP了)

4 轻量,配置和迁移方便,在windows下也可以作为服务运行,不影响任何使用体验。

privoxy的主要问题是不支持ipv6,所以需要在自定义脚本里面排除去v6的网站,好在现在v6站也不多。需要注意的是,如果你对 google用了v6,为了让快照的地址(http://[ivp6.google.com的地址]/xxxx)能被排除掉,需要使用如下的语句:

isPlainHostName(host)

这个函数实际上只是简单地判断传入的值里面有没有.号,不过v6地址正好是没有.号的啊哈哈哈……

自动代理脚本里面别的手段大概都没法处理v6地址的问题,毕竟这是一个netscape的年代出来的规范了(那时候有ipv6么)。


现在环顾一下,我的网络环境包括了自己搭建的NAT,VPN,DNS,http代理,ipv6支持,自定义主机名和自动代理脚本,TOR,再加上一大票不太常用的从软件到在线的穿墙工具。我自己则啃下了整个http协议,tcp/ip的基本知识,密码学的初步理论,还有各种各样从windows到 linux软件的使用……这样一整套武装到牙齿其目的几乎只有一个:获取和一个在中国大陆以外的人相类似的internet使用体验。

如果没有GFW,我大概一辈子都不会了解以上内容的十分之一……

标签 : EP HTTP代理 网络
主题 : ソフトウェア
分类 : コンピュータ

なるほど…………

之前各大新闻媒体都已经登载了GFW可以解开流行的phpproxy代理所使用的base64编码,然后进行过滤的消息。

我在这里报告的是GFW对base64编码处理的具体模式。(怎么有股在写论文的味道,orz)


测试基于下列几个URL:

gnu.org/www.blogspot.com

gnu.org/d3d3LmJsb2dzcG90LmNvbQ== ("www.blogspot.com"的base64编码)

gnu.org/aHR0cDovL3d3dy5ibG9nc3BvdC5jb20= ("http://www.blogspot.com"的base64编码)

以及gnu.org/aaaHR0cDovL3d3dy5ibG9nc3BvdC5jb20= (在前者开头补充了两个a,这整个字符串并不是一个正确的base64编码)


测试结果,第2个URL冲破了GFW,而另外3个都惨遭毒手。

第1个URL会被干掉是显然的。但为什么正确地编码的第二个URL没有被拦截,反而根本没有意义的URL4被拦截了呢?

我一开始的猜想是,GFW根本没有对base64进行解码,而仅仅是将需要过滤的关键词的可能的base64编码全部也作为关键词处理(例如,.blogspot.com有三个可能的特征码,因为base64是一种3->4的编码方案)。但很快这个猜想就被否定了,因为 gnu.org/HR0cDovL3d3dy5ibG9nc3BvdC5jb20=(去掉开头的a)也同样冲破了过滤,如果没有进行base64解码而是用特征码来搜寻的话,这种事几乎是不可能的。

于是剩下可能的解释就只有一个:GFW实际上是首先将"http:/"的base64编码"aHR0cDov"作为关键字,当URL里面出现这个关键字的时候,就将以"aHR0cDov"开头的整个字符串进行base64解码,然后做二次过滤。

所以,尽管"aaaHR0cDovL3d3dy5ibG9nc3BvdC5jb20="根本不是一个正确的base64编码字符串,进行解码的也只是从"aHR0cDov"开始的部分。

而phpproxy代理,虽然可以直接接受不带http://协议头的字符串作为请求,比如:

"php?q=d3d3LmJsb2dzcG90LmNvbQ=="

但是,它会返回302,跳转到一个标准的,补充了http://协议头的字符串:

HTTP/1.1 302 Moved Temporarily
Date: Sat, 18 Jul 2009 11:52:44 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Location: http://************/******.php?q=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS

于是就被GFW日了。


不过分析这个有什么用呢?答案是一点用都没有。大概只是好玩吧。要fuck gfw还是要想点别的法子。

主题 : 情報処理技術者試験
分类 : コンピュータ

最近被玩了两次……

这篇是IT文。不管CCP怎么恶心,自己的正事还是要干的。blog上就算愤到翻天也于事无补。

话说google这么一闹,绿坝就淡出人们视线了。我不知道这是不是当局的目的,但我觉得这未尝不是一件好事——可不要以为我安了什么好心,我只是希望绿坝那帮人这么一来也能松懈一下,然后7月份起让这垃圾软件就这么装到全国无数的机器上。按这软件的垃圾程度,致命的漏洞被发现只是早晚的事。众人与其整天声讨来声讨去早早把它剥个精光,还不如闷声发财,等绿霸那帮人以为高枕无忧了,等滤霸的装机量也有几百上千万的时候,像暴风事件那样,再突然来一下大的。我就等着看CCAV和摇尾系统们再怎么卑鄙无耻只手遮天都无能为力的好戏呢。

说到底,能靠技术狠狠地结实地抽CCP一记大耳光的机会,恐怕没有比这次更好的了。


啊扯远了,还是继续说我自己的倒霉经历吧……

首先是刚刚搞定的虚拟鼠标和键盘驱动,其实一天前就已经OK了的,结果放到虚拟机里发现鼠标按键什么的工作都正常,就是指针不能动。左查右改搞了一整天,最后才发现是virtual PC的additional搞的鬼,它加装了filter驱动过滤掉所有原生的输入信号而让客户机中的鼠标指针和本地机器同步,囧……关掉pointer integration选项就一切完美了。

但因为这样进度就被拖了一天。


之前另一个被玩的经历更脑残……hook dx10渲染的画面,搞了半天拷下来的都是屏幕……也是左改右查两三天,几乎绝望之际,发现自己把一个拷贝操作的函数里面源和目的数据搞反了!


呃,好像正文还没有题外话来得长?orz...总之,就拿第一个事故来说,为什么我明明看到虚拟机里面的驱动比正常情况下多了一个,但就一直没往这方面去想呢……像这种“看上去很简单”的错误,要发现关键所在究竟靠的是经验,智慧,或者仅仅是运气?

主题 : ソフトウェア開発
分类 : コンピュータ

我已经不知道起什么标题好了……

因为:

1. 我想在标题里吐嘈自己很EP

2. 我也想吐嘈这些Open Source的吊儿郎当和其它恶习

3. 但2要是吐嘈的话一定会被更多的开源厨骂到臭头的我也怀疑自己是否真的有吐嘈的资格……

(其实我有时觉得这些厨真的会对开源界有贡献么也许真正的那些社区人反而会懒理吧)

总之在这各种纠结之下我想不出恰当的标题干脆就这样了,反正有tag不是吗orz


首先让我们来学习一个名词叫功亏一篑:

事情的起源是某人抱怨他的mp4分离器(Gabest)没法处理大于4G的文件。我想这根本就是小事一桩于是打开MPC-HC的源码看了一眼,结果文件访问部分的函数基本上都很律儀地用了64位整数定义,感觉上不会出问题的样子……

不过一debug之下问题就清楚了,在AP4_Types.h里面:

typedef unsigned long AP4_Size;
typedef unsigned long AP4_Offset;
typedef unsigned long AP4_Range;
typedef unsigned long AP4_Cardinal;
typedef unsigned long AP4_Ordinal;

于是别的辛辛苦苦做的64位支持的考量就全部被台無了……


不过解决了这个问题之后,我还是编译不出来合适的mpc_hc……这次倒不是编不过,而是出来的版本效率低得让人要哭……

问题在于mpchc内建ffmpeg库,我终于明白mpc-hc里面为什么会有两套ffmpeg的库libavccodec和 libavccodec_gcc,并且在编译release版本的时候会使用后者了,因为前者的效率只能用“粪”来评价………………

但要搞定后者的话你至少要装一个mingw32……少来!

至于为啥会搞出这样的结果来?天知道……orz 我可还没有去追根究底的EP度和时间。

所以做一个新版的MPC-HC的想法先放弃吧,而且估计不仅是MP4别的分离器搞不好也是一样的毛病。


总之我最后编译了独立的mp4splitter.ax,用MPC-HC的话,取消掉内建的mp4分离器然后用这个就可以了。在我自己的机器上跑了一下没啥问题的样子。

而这个blogbus还不支持上传文件么?!神经病!

对了记得先注册ax文件,分离器的名字,32位版本是mp4 splitter,64位则是MPC MP4 source啥的……

32位版本

http://cid-b76c8a994436c2e3.skydrive.live.com/self.aspx/.Public/MP4Splitter.zip

64位版本

http://cid-b76c8a994436c2e3.skydrive.live.com/self.aspx/.Public/MP4Splitter%7C_64.zip


本来还打算向gabest报告一个patch的但他们的代码已经3年没更新了我发了大概也是石沉大海所以就算了吧。开源界的人总感觉心比天高,我还是敬而远之好了……

标签 : MPC-HC EP
主题 : ソフトウェア開発
分类 : コンピュータ

关于vista的aero效果

我不要这种充满了IT文的宅用blog啊~~(碎碎念)

总之这是今晚EP的结果。

vista的aero效果是使用所谓的桌面窗口管理器,也就是Desktop Window Manager(DWM)实现的,放狗以这个关键词一搜头条就是MSDN所以不用费神给连接了。

在默认情形下,DWM用aero的半透明效果渲染程序窗口的非客户区(non-client,嘛反正windows下面搞过点界面的都能明白吧),然后它也提供了两个API:DwmExtendFrameIntoClientArea和EnableBlurBehind来允许把半透明效果应用到客户区域。就这么简单。

真的么…………抱歉,这是孔明的陷阱。

如果你只是简单地把API应用到原有的程序上面的话,结果只有“惨不忍睹”四字……

以下是我个人的理解了:

按照MSDN的说法,DWM实际上是把一个alpha通道叠加到了原有的窗口上面——糟糕的是我对alpha通道完全不了解所以不知道叠加起来是个什么概念!不过简言之,如果窗口某个位置的像素是纯的话,最后的效果就是和非客户区一样的半透明。所以如果你直接应用这个API到原有程序,你会发现色的文字全部变透明了,其它部分则像被打了个高光似的。

然后很显然,这个渲染是在窗口完全绘画好之后才进行的,也就是说是在“窗口原有的样子”上再叠加一层,所以不要考虑窗口背景擦除前景绘画之类的问题。

最后,DWM的API只对顶层窗口有效,而作用范围则是应用这个API时传入的窗口句柄,它并不理会你这个窗口下面的子窗口啥的,也就是说不管三七二十一指定范围内的像素通杀。


根据以上的背景知识,要对一个程序实现aero的毛玻璃效果并不那么简单。

首先,要小心地定义aero效果的范围,把不想应用的地方定义出一个RGN来挖掉,记住DWM是不会躲开的子窗口的……呃如果定义起来实在太困难的话,也许还不如把那部分的子窗口做成另外的顶层窗口……

对需要应用aero效果的地方要自行绘画,填上合适的,经过alpha通道叠加后可以变透明的色彩……或者干脆什么都不画,直接一口气把主框架的背景色透出来更方便;不过边框还是得自己处理orz。

所有在透明区域的元素都要小心不要因为alpha通道的叠加而产生了奇怪的效果。

最后说一下WPF和传统win32在aero效果上的区别:MSDN上有一个把DWM的API应用到WPF上的示例,那里面aero效果并不会叠加在WPF主框架的子元素上面……大概是因为WPF中并没有WIN32那样的子窗口结构的缘故吧……

不过很显然的,在WPF里面要应用aero效果会更方便……


总之这研究带来的唯一成果就是我立刻放弃了给MPC-HC的界面作美化的想法了。很容易就放弃……算是我的优点么orz

标签 : EP MPC-HC WPF
主题 : ソフトウェア開発
分类 : コンピュータ

五月是升级月?

昨天把vista, acrobat9.0, office2007都升级了……

vista sp2:没感觉,没变好也没变坏,据说sidebar的资源消耗减少了,也许吧……

office2007 sp2:可以直接保存pdf,其它没感觉,这保存pdf功能其实也没啥用……

acrobat9.1:没感觉……adobelm.dll替换破解法可能是有危险的,升级前记得把这个文件的ntfs权限里面设置上禁止写禁止删。我升完之后要求重起,重起后在c盘下有个目录里面有个adobelm很可能就是它本来会被替换但因为权限设置而没替换成功。嘛,总之目前为止还一切正常……


结论:纯粹只是看着好看的EP行为

PS:今天给一个来组里访问的国老头做好人鼓捣了一下他的电脑。系统居然是他在上交大的时候灌的雨林沐风xp sp2……泪流满面。

标签 : EP
主题 : ソフトウェア
分类 : コンピュータ

个人情报

とある姉コン

Author:とある姉コン
轻小说,ACG,IT相关。

本人则是姐控的死宅(啥),专业是物理化学和高性能计算,有悠久历史(从2000年开始算的话)的代码民工,没了。

ココロ
RSS
最新日志
最新评论
分类
検索フォーム
Tag

虚假的完美世界 EP 姐控 网络 真实的悲惨世界 破鞋党 后宫 絶望した! 文学少女 化物語 HTTP代理 MPC-HC Little_Busters! Fate 文学批评的性别观 戦場ヶ原さま大好き 无限循环 学生会 游戏 K-ON 笨蛋测验召唤兽 DNS服务 Galgame创作 RivaTuner 人渣 自爆 Room.No.1301 GPU-Z 4850HD IE8 WPF Rita UAC windows_live CLANNAD Windows_Gadgets 空境 

友情连接
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。