English | 中文 | Русский | Français
共 408 篇文章
共 2,611 篇文章及评论
请与我们分享您关于线程的方法和意见,不论是游戏还是财务服务应用,欢迎您畅所欲言。请记住:多核总比单核好哦!
这里是强劲的英特尔® 至强® 5500 处理器的又一个成功案例,欢迎免费下载 :-) 盛京医院数字化医疗体系
最近在做项目开发中,使用了一个开源的代码框架,Debug编译的时候一切正常,但是在Release时候就挂了。找了老半天也没找出哪里错,因为一下就跳到系统DLL,然后就崩溃了,连call stack都看不到了,应该是堆栈被破坏了。根据经验判定可能是内存分配释放问题,因为Release版本可能暴露出一些Debug版本的内存使用问题。 这时想起不是Intel Parallel Inspector能找内存错误吗?就开到它的最大内存错误检查模式试着跑一把。结果大有收获!原来是使用的框架中犯了一个经常犯的错误: p = new Foo [100] 必须用 ...
因工作需要,我自己经常需要确认手头某个英特尔CPU的型号,也经常有客户/朋友这样问。 当然最基本的方法是用CPUID指令,编一个小汇编,再去对手册。但这个十分麻烦,不是一般人可以承受的。 还有就是网上有很多现成的小程序,可以安装了之后运行一下。但这招普遍有两个问题: 1。这些程序的更新不见得十分及时,最新发布的CPU一般认不出 2。为了运行程序,需要安装OS,不能裸机就看出CPU类型来。 最近,发现一个网站,十分有效,可以根据英特尔CPU上的标志,直接查出已经正式发布的英特尔CPU类型来,好用阿! http://ark.intel.com/sspecqdf.aspx 查时请看CPU背面(没有针脚的一面,是背面吧),上面一般都有如下的一些字: 450/512/100/2.0V S1 ...
当下的embedded system已经非同以往,多核与网络化功能的发展加速了整个行业的多元化进程。让我们先回顾一下embedded system的大概框架,再来分析Intel的发展。 标准的嵌入式系统架构有两大体系: 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 ...
经常有人问:你介绍的很多东西有没有什么具体的例子呢?我收集了一些可以公开的成功案例,特此陆续献上,希望可以帮助大家更好的理解英特尔的产品,英特尔的技术。 之前介绍过英特尔® 至强® 5500 处理器。这款已经正式发布的CPU,性能十分强劲,这里就是宝信的一个例子: 宝信一体化监控指挥平台iCentroView5采用基于英特尔® 至强® 5500处理器的测试平台显著提升软件整体性能
(*本文由作者于2009年10月首发于中国移动专家博客) 数据中心是企业的核心竞争力之一,可靠高效的数据中心是确保企业正常运转的核心基础设施之一。但由于企业的快速发展,数据中心的规模也是不断扩张,带来了很多的问题。 在同企业信息部门的交流中,经常发现对数据中心的抱怨:抱怨不好管理,抱怨维护高昂,抱怨升级痛苦… 也走进了许多数据中心,深为里面的“万国旗”而震动:采购直不同时期,不同品牌不同配置的硬件,不同版本不同参数的软件… 也见过整洁划一的数据中心,但了解下来,多是把老系统彻底推倒重来,我们真的不差钱吗? 如何应对系统处理容量的快速发展,如何解决复杂的管理问题,如何保护现有投资呢?虚拟化和云计算是一个解。 从总体架构上讲,数据中心的硬件资源可以分为两个部分:一部分是由虚拟化平台软件所管理的x86服务器池,也就是传统上说的PC服务器。虚拟化平台软件则是把这些物理的计算资源转换成了逻辑的计算资源。什么是逻辑的计算资源?说白了就是通过创建虚拟机使得计算资源按需分配。现在的x86服务器都从硬件上支持虚拟机操作,而且计算资源也很充沛,4核服务器都很普遍了,所以可以根据实际的需要切出合适大小的虚拟计算机,这个包括处理器的个数和内存的大小。虚拟机是在软件控制下产生的,平台管理软件的控制,所有的设备是虚拟的,和底层物理硬件无关,所以一致性好做到了“异中求同”,从而可以保护大量原有投资。虚拟机可以根据需要动态的产生,撤销,迁移,这些都可以有平台软件的控制下自动完成,更加方便管理。在这种架构的支持下,上层可以支持不同的应用,这些应用不再关心运行在那个具体的物理服务器上,这个过程由虚拟化平台软件负责调配完成:虚拟化平台软件就像一个操作系统管理这些物理服务器,上层的解决方案就像应用程序。当某个解决方案需要更多的计算资源的时候,虚拟化平台软件就为他分配更多的虚拟机,当不需要的时候,虚拟化平台软件就把这些虚拟机在撤销。就这样,控制者物理服务器资源在不同的解决方案中灵活的调度,这个过程是自动实现的。当社保的系统规模增大的时候,就添加更多的物理机到资源池中去,虚拟化平台软件会很好的把他们自动的管理起来。由于虚拟机和物理机的差别是老的软件感觉不到的,所以原有的解决方案不需要做改变即可在虚拟化平台上运行,由此兼容原有的系统。新系统可以为新的运行平台做优化,更好的实现可管理性和资源的动态调度。 从本质上说,这种虚拟化了的数据中心隔离了硬件与应用:应用看到的是计算资源,而不再是一台台的机器。这不就是云计算吗? 而数据中心的虚拟化和云计算建设可以本着循序渐进的原则,从一点开始,逐步建立虚拟化平台,渐进的把更多应用切换的这个平台上。而一些应用,可能由于历史限制或者说非常关键,短期内迁移还有很大的顾虑,就继续沿用,不必改变。从技术路线上说,数据中心虚拟化的过程,是一个循序渐进的过程,是逐步演进,逐步改良的过程而不是一下子推到重来。
笔者一直认为英特尔博锐处理器技术是商用电脑领域的一项重大革新,其因有三:1、无论是安全性的突破还是可管理性的超越,博锐技术带来的无疑是更大范围的技术创新(而不仅于个人pc);2、其远程可管理性将大大降低企业的隐性成本;3、笔者坚定的认为这种创新是为众多大中(也许还有小)企业量身定做的。 当然,笔者并非企业IT管理人员,缺少切身体验的机会,一直以来,对博锐技术的了解仅处于“可远观,而不可亵玩焉”的水平。 其实早在两年前,笔者就耳闻博锐技术基于“软硬兼施”的安全与管理解决方案,碍于无缘体验,一直是扑朔迷离。 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博锐时代的发展和辉煌时刻的到来。 今后,我将以使用或体验者的身份,等待真正近距离接触博锐的机会。 拭目以待。
今天随意逛水木的精华区,看大家在讨论什么GIL,搜了一下发现python的多线程原来与我想象的大不同。看了几篇不错的文章,觉得挺不错的,大致对问题有了个了解,先把文章的地址贴出来,有兴趣去读这些文章的朋友就不必再听我这样的半拉子扯淡了: 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 ...
今天在测试一个东西时发现,谷歌浏览器与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. 减小整个会话阻塞在单个进程中,使得整个系统的吞吐量增大。 以上理解,是我对多进程/单线程模型的一点心得。