这时想起不是Intel Parallel Inspector能找内存错误吗？就开到它的最大内存错误检查模式试着跑一把。结果大有收获！原来是使用的框架中犯了一个经常犯的错误: p = new Foo [100] 必须用 delete [] p 结果用了delete p，但是用的是别人的框架啊，几万行代码哪儿去找这个不起眼的错误？还是工具好用，马上改过来，一切恢复正常！

当然最基本的方法是用CPUID指令，编一个小汇编，再去对手册。但这个十分麻烦，不是一般人可以承受的。

还有就是网上有很多现成的小程序，可以安装了之后运行一下。但这招普遍有两个问题：
1。这些程序的更新不见得十分及时，最新发布的CPU一般认不出
2。为了运行程序，需要安装OS，不能裸机就看出CPU类型来。

最近，发现一个网站，十分有效，可以根据英特尔CPU上的标志，直接查出已经正式发布的英特尔CPU类型来，好用阿！
http://ark.intel.com/sspecqdf.aspx
查时请看CPU背面（没有针脚的一面，是背面吧），上面一般都有如下的一些字：
450/512/100/2.0V S1
19270769 -- 0459 Philippines
98 SLGU5

这里SL开头的SLGU5就是CPU的QDF/S-Spec号，把它输入网站的search栏，就可以直接搜出CPU型号了。

标准的嵌入式系统架构有两大体系： RISC（Reduced Instruction Set Computer，精简指令集计算机）处理器，和CISC（Complex Instruction Set Computer，复杂指令集计算机）处理器体系。

RISC体系的阵营非常广泛，从ARM、MIPS、PowerPC、ARC、Tensilica等等，都属于RISC处理器。不过这些处理器虽然同样是属于RISC体系，但是在指令集设计与处理单元的结构上都各有不同，因此彼此完全不能兼容，应用软件也无法简单的重用。

CISC体系就包括了我们的Intel的X86处理器。CISC体系其实效率并不高，因为其指令集和芯片结构全而复杂。过去被应用在嵌入式系统的X86处理器，多为工业计算机中仍可见到的但是数年前早已退出个人计算机市场的Pentium3处理器。由于其性能稳定，加上已经被市场长久验证，故常应用于效能需求不高，但稳定性要求高的应用中，如工控设备等产品。当然了在这个市场上，Intel 遇到了AMD的强烈挑战，然而AMD在购并ATI之后，其表现只能算差强人意。

回顾以往Intel的产品，从嵌入式IXA（互联网交换架构），到网络处理器，Xscale，到现在的Atom，我们一直没有放弃过embedded system，准确的说是一直在寻找一个恰当的切入点进军这个充满潜力的市场。而且我们一直相信嵌入式市场对Intel来说是决定10年后命运的生死攸关的一场战争，据报道2015年全球将有150亿台连接互联网的设备，相对于已成熟的PC市场，嵌入式市场目前的开发程度可谓冰山一角。Intel嵌入式与通信事业部CTO Pranav Mehta 曾经对《电子系统设计》记者表示“现在是进入‘深嵌入式市场’的最佳时机。” 之前，英特尔在嵌入式市场主要在高端产品领域，比如通信与网络，现在，我们要大力投入的是中低端领域，也是我们称之为‘深嵌入式市场’的领域。在传统的深嵌入式领域，各种电子产品与外界没有联系，是一个个的孤岛。现在，人们对于这些孤岛的互连性要求越来越强烈，比如医疗设备、工厂、零售终端等等，都在向互连性迈进。这也正是英特尔的机会。因为现在的互联网基于IP，而英特尔的IA架构是IP网络最适合的平台。工程师在IA架构上更容易实现各种应用的创新。这也是我们今天有信心进入深嵌入式市场的原因。

我们要用IA架构来统一所有的电子产品，从小屏幕的手持设备到大屏幕的PC、以及没有屏幕的深嵌入设备，比如工业控制、交通、军事以及医疗电子等。当然了为了完成这个宏愿，我们要面对强大的ARM阵营，还有很多路要走。

之前介绍过英特尔® 至强® 5500 处理器。这款已经正式发布的CPU，性能十分强劲，这里就是宝信的一个例子：

宝信一体化监控指挥平台iCentroView5采用基于英特尔® 至强® 5500处理器的测试平台显著提升软件整体性能

在同企业信息部门的交流中，经常发现对数据中心的抱怨：抱怨不好管理，抱怨维护高昂，抱怨升级痛苦… 也走进了许多数据中心，深为里面的“万国旗”而震动：采购直不同时期，不同品牌不同配置的硬件，不同版本不同参数的软件… 也见过整洁划一的数据中心，但了解下来，多是把老系统彻底推倒重来，我们真的不差钱吗？

如何应对系统处理容量的快速发展，如何解决复杂的管理问题，如何保护现有投资呢？虚拟化和云计算是一个解。

从总体架构上讲，数据中心的硬件资源可以分为两个部分：一部分是由虚拟化平台软件所管理的x86服务器池，也就是传统上说的PC服务器。虚拟化平台软件则是把这些物理的计算资源转换成了逻辑的计算资源。什么是逻辑的计算资源？说白了就是通过创建虚拟机使得计算资源按需分配。现在的x86服务器都从硬件上支持虚拟机操作，而且计算资源也很充沛，4核服务器都很普遍了，所以可以根据实际的需要切出合适大小的虚拟计算机，这个包括处理器的个数和内存的大小。虚拟机是在软件控制下产生的，平台管理软件的控制，所有的设备是虚拟的，和底层物理硬件无关，所以一致性好做到了“异中求同”，从而可以保护大量原有投资。虚拟机可以根据需要动态的产生，撤销，迁移，这些都可以有平台软件的控制下自动完成，更加方便管理。在这种架构的支持下，上层可以支持不同的应用，这些应用不再关心运行在那个具体的物理服务器上，这个过程由虚拟化平台软件负责调配完成：虚拟化平台软件就像一个操作系统管理这些物理服务器，上层的解决方案就像应用程序。当某个解决方案需要更多的计算资源的时候，虚拟化平台软件就为他分配更多的虚拟机，当不需要的时候，虚拟化平台软件就把这些虚拟机在撤销。就这样，控制者物理服务器资源在不同的解决方案中灵活的调度，这个过程是自动实现的。当社保的系统规模增大的时候，就添加更多的物理机到资源池中去，虚拟化平台软件会很好的把他们自动的管理起来。由于虚拟机和物理机的差别是老的软件感觉不到的，所以原有的解决方案不需要做改变即可在虚拟化平台上运行，由此兼容原有的系统。新系统可以为新的运行平台做优化，更好的实现可管理性和资源的动态调度。

从本质上说，这种虚拟化了的数据中心隔离了硬件与应用：应用看到的是计算资源，而不再是一台台的机器。这不就是云计算吗？

而数据中心的虚拟化和云计算建设可以本着循序渐进的原则，从一点开始，逐步建立虚拟化平台，渐进的把更多应用切换的这个平台上。而一些应用，可能由于历史限制或者说非常关键，短期内迁移还有很大的顾虑，就继续沿用，不必改变。从技术路线上说，数据中心虚拟化的过程，是一个循序渐进的过程，是逐步演进，逐步改良的过程而不是一下子推到重来。

其实早在两年前，笔者就耳闻博锐技术基于“软硬兼施”的安全与管理解决方案，碍于无缘体验，一直是扑朔迷离。

2009年4月17日，笔者有幸参与了2009英特尔博锐技术应用宣讲会，期间，英特尔解决方案部中国大区技术部经理梁岩分享了博锐技术的最新应用和成功经验，而来自联想公司的代表更是在现场演示了联想基于博锐平台的创新应用。终于,在了解博锐技术知识的同时，更使笔者享受到一次身心愉悦的博锐应用之旅。

博锐技术应用之旅——商用电脑新高峰

在会上,厂商为我们展示了基于英特尔迅驰2博锐处理器平台和英特尔酷睿2博锐处理器平台关于安全性与可管理性的宣讲和演示。这一基于硬件的技术在重大IT挑战面前，无疑是一个里程碑式的事件。过去，企业诸如系统在关机时难以管理、企业防火墙外的笔记本电脑之间的通信不安全、不断增加的昂贵的现场访问费用支出、未受保护或者难以发现的硬件资产损失、难以实现的配置一致性、耗时耗力的人工盘点等问题给企业造成了很多不便和经营障碍……透过联想基于博锐平台的创新应用的现场演示过程，笔者看到这些难题在博锐技术面前，已不再是难题。

博锐技术应用体验——一个典型的示例

我们知道，诸如Netman、Remote Administrator、PcAnywhere等远程控制软件，已经将远程控制技术发挥得淋漓尽致。随着技术的发展，远程控制从传统的使用NETBEUI、NETBIOS、IPX/SPX、TCP/IP等协议来实现操控，到通过Web页面以Java技术来控制远程电脑；从对等操作系统间到跨越平台的远程控制，技术的发展越见成熟。

但是，基于软件的远程控制技术，其局限性是很明显的。一、在某些情况下，如，当被控端处于关机或系统崩溃状态时，主控端发出的远程控制指令很难得到任何的反馈；二：主控端能够取得控制权的host数量一般都是很有限的，大多数情况下也是不安全的；三：大多数软件，主控端施予被控端的操作是一对一的，很难统一集群操作；四：主控端能够实现的远程操作类别受诸多因素影响，非常有限；五、基于软件的远程控制缺乏主动性。

下面，我们来看一个联想基于博锐平台的应用演示：

如上图，在博锐技术的支持下，演示人员通过图中的IT控制台（VPRO控制台），对一台无法启动系统的客户机进行系统检测和修复，并对其执行开机操作。

如果我们将这个演示过程简单理解成是基于硬件的远程控制，那么，这种远程控制的突破就在于，通过对虚拟技术的支持以及英特尔主动管理技术，它跨越了传统的基于软件的远程控制技术的局限：不受客户机系统因素影响导致操控失败、不受host数量限制、对客户机完整的集群操作、管理台能够完成几乎所有的等同于客户机本机操作的计算机操作、管理台主动操作、基于处理器的内建安全性等等。

这项技术的应用将是企业IT管理的革命。试想，在一个传统的企业办公网络内，一旦某一机子出现系统故障，IT管理人员面对的将是喋喋不休的电话问询，问询无法解决的更是只能亲临现场排查故障。企业规模越大，IT管理人员现场访问的次数也就越多，为此，企业不得不支付高昂的IT管理费用。而当企业部署了计算机群都处于博锐技术的控制之下后，上述问题将迎刃而解。

当然，以上的例子只是博锐技术展示中的一个典型示例。 整个会议过程中 ,笔者都有很深的感慨和体会。 毋庸置疑，博锐技术的应用将会成为企业商务化管理的一个重要体现和趋势性发展的必然结果。 当然这里也很荣幸的被邀请参与到体验的过程中,见证酷睿2博锐时代的发展和辉煌时刻的到来。 今后，我将以使用或体验者的身份，等待真正近距离接触博锐的机会。 拭目以待。

Concurrency and Python

http://www.ddj.com/linux-open-source/206103078

Python Threads and the Global Interpreter Lock

http://jessenoller.com/2009/02/01/python-threads-and-the-global-interpreter-lock/

 
本来是应该从并行、多线程、竞争、锁这些东西谈起，不过我想一般大家都该挺熟的，不熟悉的话也很容易找到资料，这里就偷懒略过了。

Python的多线程模型基本上是Java多线程模型的简化版，提供了线程基类、锁、信号量，事件等待组件，虽然也少了一些功能，比如线程不能被销毁、中止、暂停、恢复等待，基本上可以让程序员比较方便的进行多线程编程。在CPython解释器中，存在一个叫Global Interpreter Lock(GIL)的东西，直译就是全局解释器锁，它的作用在于让同一时刻只能有一个线程对于python对象进行操作。Python已经提供了各种机制让我们进行多线程同步，为什么又要整这个GIL呢？这是因为程序员控制的同步是对各个程序中可见的变量，而GIL同步的是解释器后台的不可见变量，比如为了进行垃圾回收而维护的引用计数。如果没有GIL，有可能出现由于线程切换导致的对同一个对象释放两次的情况。

因此，任何一个CPython线程如果要执行，就必须先获取这个GIL。后果？就是在CPython中，本质上几乎是没有线程并行的，不论你开多少个线程，同一时刻只有获取GIL的那个线程能够执行。为什么要说几乎呢，这是因为提供给python的C库中，还是有解决方案的，比如

这段代码是sleep的代码，在执行sleep之前，通过一个宏来释放GIL，然后在睡眠结束执行其他代码前又获取GIL。其他一下操作，比如IO，也会有类似的操作，这样就使得对于IO密集型的程序，或者是使用C库进行计算的程序，还是可以在很大程度上避开GIL来取得线程并行的效果的。但对于纯python代码的程序，GIL恐怕还是躲不过去的。

还有一个问题，就是GIL怎么释放，我们看到在python/C API中提供了宏来进行释放，那么对于普通的python语句呢？解释器会在执行一百条python代码后强制释放GIL，这就使得其它线程得以执行。

最后需要说明的，就是这个GIL的问题是解释器相关的，而不是语言相关的。也就是说它只是对于python语言解释器的一种实现，并不是语言本身的特性。事实上，GIL就是解释器的一个非常粗粒度的锁，我们完全可以采用更细粒度的锁来增加并行性，而且Gindo就写过一个patch来取消GIL，不过好像最后的结果是细粒度锁导致了单线程程序的性能下降了两倍，所以最后还是决定优先保证单线程程序的性能，继续保留GIL。但是python的其他两个分支，Jython和IronPython，却都没有GIL的问题，从而可以实现线程的并行。为什么呢？你知道了麻烦给我说说。。。

今天在测试一个东西时发现，谷歌浏览器与IE浏览器可能在多线程处理方面有根本差别。我是指，如果浏览器在等待一个请求的响应时，如果有一部分已经输出到了浏览器中，那么对于这一部分的展现是否可以并行处理？

例如，我需要等待一个很长时间的页面，为了减少用户的焦虑，我们可能会用一个进度条的方式。这个进度条可能是一个gif图片。我发现在谷歌浏览器中，gif图片可以正常工作（即便浏览器当前还在等待更多的响应），而IE却不行。傲游也不行（因为它也是IE内核）

可以看到那个进度条在动。

而同样的页面，如果用IE打开，则一动不动。

作者：陈希章
出处：http://blog.csdn.net/chen_xizhang

最近在看北电代码的时候，发现，系统中大部分模块都采用的是一个进程/一个线程的设计方式，一个大的功能模块由多个进程构成。因为系统是运行在Linux平台上，一开始，我觉得这种设计是有问题，追溯根源，以为是北电之前使用的操作系统是vxworks,那帮北美的开发人员把vxworks中task的概念生搬硬套到linux中，在linux中提供了比进程性能更高的线程，他们并没有充分的利用起来。之后认真思考了一下，发现，他们这样设计是有道理的。分析如下，我们先来说说进程和线程的区别吧。

区别:

1. 进程是资源拥有的基本单位，线程是调度的基本单位，在CPU上调度的是线程，当任务切换的时候，需要将资源进行保存。

2. 在一个进程内部可以运行多个线程，线程切换不需要资源保存，这些线程共享进程的资源，地址空间。进程切换需要资源保存。

3. 进程之间的同步是可以通过各种IPC，各种进程锁，信号量，信号来实现，比如文件锁，自旋锁，RCU等。而线程之间的同步可以通过进程内部锁来实现，比如互斥锁，读写锁等。

在设计中为什么要使用多进程单线程的这种模式呢？我的理解如下:

1. 增加整个系统的健壮性，比如一个进程做两件事情，任何一件事情做失败都会导致另外一件事情不能做。如果将这个进程里的功能解耦，系统的健壮性自然也随之增强。单点故障的几率减小。

2. 从开发角度讲，这种解耦也便于系统升级，对其中的某一个模块升级变得更加容易而不会影响到其他功能模块。

3. 虽然性能不如多线程，但是多线程编程适用于高级程序员，对编程技巧要求高。使用多进程其实性能差别就在于进程切换资源保存部分，多线程模型会把进程间数据传递的开销转到锁开销上。

4. 减小整个会话阻塞在单个进程中，使得整个系统的吞吐量增大。

以上理解，是我对多进程/单线程模型的一点心得。