注:文章和编译无关。
前两天,听了个小讲座。淘宝的师兄介绍淘宝。记录了一些有趣的数据,和各位分享。
淘宝目前用户收藏大概有40亿条,店铺180万家,活跃用户1.45亿人,总注册用户2.23亿人。但现在淘宝的广告收入只有600-700万元。看来淘宝真是不急着挣钱。 Continue reading »
注:文章和编译无关。
前两天,听了个小讲座。淘宝的师兄介绍淘宝。记录了一些有趣的数据,和各位分享。
淘宝目前用户收藏大概有40亿条,店铺180万家,活跃用户1.45亿人,总注册用户2.23亿人。但现在淘宝的广告收入只有600-700万元。看来淘宝真是不急着挣钱。 Continue reading »
上篇文章《前瞻-主流处理器中的数据并行支持(SIMD)》 介绍了当今主流CPU中的SIMD扩展,本文将介绍前人是物和利用SIMD来做优化的,下篇<前瞻-拿起SIMD的武器II>将探讨如何使用CPU的向量指令为程序做优化
正如之前提到的,SIMD对具有以下特性的程序性能提升明显:天然数据并行,访存模式重复、在局部数据上重复操作、控制流数据无关。很多应用有这方面的特性,并能通过使用SIMD扩展提高性能,但实际仅有小部分从中获益,接下来将介绍在单核处理器上,利用Intel的SIMD扩展针对某些应用提升性能的研究,如多媒体,数据安全,数据库和一些科学计算应用。
多媒体处理需要软件和硬件的很多支持。如MPEG-1,MPEG-2,MPEG-4,MPEG-7,H.263,JPEG2000等需要实时做复杂的媒体处理.3D图像和立体视频处理都需要更强劲的实时处理.因为各种媒体都需要不同的处理方式,技术支持、算法和硬件,因此针对他们的SIMD扩展改进也很不同。 Continue reading »
多媒体处理算法应用在很多媒体处理环境中,如对文本,手写数据,2D/3D图形和音频对象的捕捉、制造、存储和传输等。过去 都是使用昂贵的多媒体处理硬件协同工作来加速。现在,通用处理器通过在体系结构上增加媒体处理支持来减少使用协同处理器分配和返回带来的开销。在通用处理 器上一个基本的操作能同时作用多个元素的支持成为SIMD并行处理。通过SIMD扩展,通用护理器通过捕捉多媒体算法中潜在的并行特性来加速应用。
2010年美国高校计算机系排行榜出炉–《U.S. News》公布了新一期美国大学计算机系实力排名。前四:卡内基-梅隆大学(CMU)、麻省理工学院(MIT)、斯坦福大学(Stanford U)和加州大学伯克利分校(UC Berkely).
Standard Performance Evaluation Corporation:标准性能测试协会,一个致力于发布管理计算机性能标准化测试的组织.建立于1988年,会员包括Apple,Dell,IBM,Intel,Microsoft和Sun。Spec的测试例子被光感应用于计算机系统的性能测试中。
SPEC的测试例子是为了测试实际生活中的场景,如SPEC web2005通过并发HTTP请求测试web服务器的性能.SPEC CPU通过多个例子的运行时间长短衡量CPU的性能。SPEC的测试例子都采用平台无关代码编写,以便能使用各种编译器和平台来测试。现在的工业界更是针对SPEC中的测试例子做优化来证明编译器,CPU,web服务器等等的性能提升。
SPEC发布了以下性能测试集:
(译者注:原文单词为Dwarfs,意思是有魔法的小矮人)
图1左侧的塔是应用。除了传统的桌面、服务器、科研和嵌入式应用外,面向消费生产的重要性正在增加。
我们决定发掘高性能计算领域中并行化的经验,以期能从中学到有关更广泛领域的并行计算的知识。这样做的前提并非传统的科学计算是并行计算的未来;而是在大规模并行计算机上开发高效运行程序的经验本身或许能为以后应用的并行化提供有用的经验。而且许多其他领域的作者,如嵌入式计算,也为他们自己领域内的未来应用与现有并行计算问题如此的相似而感到吃惊。 Continue reading »
1. 致命的异常中止决不允许。
2. 以这个次序编写:用户手册,说明书,帮助,源代码。
3. 除非你使用Risk Factor Analysis(RFA), 否则一个程序将花费双倍你认为开发所需的时间。
4. 编码工作量应该不超过开发工作的百分之二十。
5. 测试应该至少要占工程的百分之三十。
6. 注释应该至少要占源代码的百分之二十。
7. 一条错误的消息应该报告什么发生了,关于这个用户能够做什么,程序下一步要做什么,以及那一行代码造成该问题?可能也要注意时间,用户名和环境。
8. 好的程序将自动地发送最近的错误信息给永久性媒体。
9. 调用一个例程三次?隐藏它调用一次?不要隐藏。
10. 例程精确地只需要一个入口和一个出口例外包括了菜单和错误陷阱。
11. 带有清晰的变量名和例程名的文档代码。
12. 数据库应该是相关的。
13. 总是采用最好的算法。
14. 首先优化最慢的例程,使用Profiler标示它们。
15. 最好的开发语言通常是具有最短开发时间的那个。
16. 要求顾客签名。
17. 首先编写更具风险的模块。
18. 让简单的维护成为你的灯光。
19. 检查你写的每个签名和拼写。
20. 不要写任何你能够用一个3*5卡片封面复制的程序。
21. 知道何时应该完成何事。
22. 没有任何列表是完善的。
23. 困难不是你正在看之处。
24. 存在的规则和规律可以让人免于思考。
(摘于《Java 程序调试实用手册》p342)
在向下一代网络演进的过程中,整个通信产业链将不断地进行细分,产业分工更加细化,新的相关主体不断涌现。这些主体之间的关系也由传统的简单上下游供应关系,逐步演变成较为复杂的多边关系。在这多边关系中,我们有必要了解一个完善的NGN网络所需要的关健基础。
下一代网络呼唤高智能支撑系统
1.网络层面的需求
网络层面的变化对下一代运营支撑系统的要求主要反映在资源管理、网管和计费方面。
网络对资源管理的要求:资源管理是整个运营支撑系统的重要数据基础,它不仅要直接支持业务开通,同时对业务保障(综合网管和故障处理)、资产、工程、数据仓库/集市等都要提供数据支持。
网络对网管的要求:目前的网络是混合结构,既有传统的电信网,也有以TCP/IP为主的分组网。目前业务还没有充分融合,管理上也往往各自独立。下一代网络是电路交换网络和分组网络会在各个层次上融合,融合后的网络必然引发网管方式的变化,网管的统一化、智能化、主动化等方面将有所突破。
网络对计费采集的要求:下一代网络的计费采集对象众多,如交换机、路由器、认证服务器、接入服务器、各种媒体网关及合作伙伴都成为计费采集的对象;下一代服务的多样化使得计费要素更为复杂,因此对于计费采集的完整性和实时性要求更高,从而对计费采集系统的处理能力要求更高。
2.业务层面的变化
业务的需求决定了网络技术的变化,它们同样对于下一代运营支撑系统有着较大的影响。业务类型和模式的变化既会对业务开通和业务保障的流程产生直接的 变化要求,也会对资源分配、网管配置和监控等产生间接的需求。业务层面的变化及对下一代运营支撑系统提出的要求主要有以下几方面。
(1)业务层和控制层的分离会使新业务和新产品推出的速度加快,这种变化要求:
运营支撑系统应实现对产品全生命周期一体化流程管理,这里的全生命周期管理不仅包括产品在销售、开通、运维、退出过程中的状态变化,也包含从战略、决策和基础设施建设角度来看的产品生命周期管理;
运营支撑系统的快速响应(快速的业务开发和部署能力)和多系统协同工作的能力至关重要。
(2)下一代网络的业务价值链更为复杂,导致更多业务的开通或者保障可能会跨运营商、合作伙伴,这种变化会导致:业务开通和业务保障流程系统应具有更好的跨运营商、合作伙伴的处理能力;运营支撑系统应加强对供应商和合作伙伴的管理,并加强对网间或合作伙伴间的结算能力。
(3)业务的多样化和复杂性对计费和帐务系统的要求提高,位置服务、移动支付、流媒体点播等服务的计费使得计费的要素更复杂,时长、流量、位置、内容、QoS、次数等都会成为计费的要素。
(4)个性化自助服务:下一代网络服务的另一个重要特征就是为用户提供个性化的服务体验,用户可以通过运营商面向用户的各种门户,个性化定制自己所 需要的服务,然而,这种个性化的自助服务往往对后台支撑系统的实时性处理要求很高,需要定单处理、资源管理、网管和计费多个系统的协同工作。
3.下一代运营支撑系统的IT技术实现
下一代运营支撑系统所涉及的IT技术相当广泛,主要有面向服务架构(SOA)技术、UML建模技术、中间件技术、企业应用集成(EAI)技术、企业 级工作流程管理技术、数据库技术、数据仓库技术、商业智能技术、海量数据存储技术、容灾备份技术、高端服务器、网络及系统管理技术等。目前,这些技术都有 相当丰富的理论体系和产品实现的支持,无法一一尽述。因此,本文将只对SOA架构技术进行简单的描述。
SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来,接口是采用中立的方式进行定义的, 应该独立于实现服务的硬件平台、操作系统和编程语言,这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA具备了标准化、可操作、可组装的特性,提供了一个通用的、可互操作的和有弹性的行业标准架构,可以在软件基础架构中建立一系列支持商业模型的可重复利用的服务,这些服务由不同应用系统的组件构成,能够帮助企业实现商业流程随需所用。
SOA的核心思想与下一代网络和下一代运营支撑系统的分层服务的架构思路非常一致。因此,SOA技术必将成为下一代运营支撑系统IT实现中的一个重要的架构技术。
下一代网络催生全面网络测试
随着NGN网络技术的日益成熟,全球电信运营商都在某种利益(成本低廉和新业务应用)的驱动下大量部署NGN网络,每年以30%左右的速度递增。由于目前的NGN网络是一个以软交换为核心并由PSTN网络和VoIP网 络融合在一起的复杂网络,多种接口、多种协议、多种媒体并存,存在PSTN与VoIP设备的兼容性、VoIP网络内部不同设备提供商的设备兼容性、网络设 计性能与实际部署性能的差异性、语音(也许还有视频)质量的差异性等挑战都不同程度地摆在了运营商面前。如果处理不好,很可能造成网络部署失败,运营商不 仅要蒙受经济损失,还要承受更大的社会压力。那么,运营商就会不约而同地把目光聚焦到网络测试技术本身,我们认为网络性能测试是NGN很重要的一环。
NGN网络性能测试要兼顾PSTN与VoIP网络的融合,既要考虑满负荷条件下的语音质量测试,也要考虑软交换的纯信令的 压力测试,还要考虑媒体网关对媒体流的处理能力测试。对于电信运营商来说,比较全面的NGN网络测试,不但要考虑本地的端到端测试,还要考虑异地(跨地 域)的性能测试。测试技术一般包括同步呼叫测试、异步呼叫测试、长保持呼叫测试、语音质量测试、语音间断/语音滑动测试、回声测试以及其他性能测试等。
(1)同步呼叫测试(测试NGN系统的峰值压力)
同步呼叫一般分为纯信令和带媒体流的两种,分别测试系统对信令和媒体流的处理能力;同步呼叫一般由几十到几千个用户同时发起呼叫,使用二分法,精确验证出NGN系统同时能够处理多少路呼叫并发,是一种峰值压力的测试。测试时间一般不超过1h;呼损不能超过万分之一。
(2)异步呼叫测试(验证NGN系统的呼叫性能,如BHCA,CPS等)
异步呼叫一般分为纯信令和带媒体流的两种,分别测试软交换对信令的处理能力和媒体网关对媒体流的处理能力;异步呼叫一般由足够多的用户采用异步方式 发起呼叫(例如间隔一秒发呼一个用户),通过更改呼叫保持时间和呼叫间隔时间来调整压力,精确验证出NGN系统的呼叫性能,通常体现在BHCA和CPS数 值上,即系统每小时或每秒处理呼叫的能力。测试时间一般超过1h,甚至达到24h或48h;呼损不能超过万分之一。
(3)长保持呼叫测试(测试NGN系统对于长保持呼叫的处理能力)
长保持呼叫一般分为纯信令和带媒体流的两种,分别测试软交换对信令的处理能力和媒体网关对媒体流的处理能力;长保持呼叫一般由足够多的用户采用同步 或异步方式发起呼叫,呼叫保持时间一般不低于8h,精确验证出NGN系统的对于长呼叫的处理能力,即在规定时间内有无“掉话”,通常体现在呼损数值上,不 能超过万分之一。
(4)语音质量测试(测试在一定压力下,NGN系统内端到端的语音质量)
在电信领域,我们的前辈也曾经在PSTN网络部署的时候遇到过诸如回声和传输衰减等影响通话质量的问题,但他们通过回声抑制和增益补偿等技术很好地 解决了这些问题,使得PSTN网络的话音质量非常稳定。但是这种情况在最近几年有所改变。随着全球电信运营商大量部署NGN网络,PSTN与VoIP网络 不断融合,语音质量问题又被提出来,似乎成了我们难以回避的障碍。
语音质量测试一般指端到端的语音质量测试,主被叫两端所连接的呼叫通常会经过媒体网关等对语音进行编解码处理的网络设备,当然还有其它可能产生损伤 的网络设备。语音质量测试一般由足够多的用户采用同步或异步方式发起呼叫,测试时间一般不超过1h。主要测试参数包括MOS、PSQM、PESQ等ITU标准语音质量参数,还有单向时延、双向时延、抖动、丢包、乱序等网络质量参数,当然还有呼叫完成率,即呼损数值,不能超过万分之一。
(5)回声测试(测试在一定压力下NGN系统处理回声的能力)
回声是PSTN网络中由于2~4线转换造成的,在PSTN与VoIP网络融合的过程中,被媒体网关进一步放大了。回声测试一般只要求有限压力条件, 主要测试系统的一次/两次/三次回声的时延和强度。一般来说,回声最好不要超过150ms,超过150ms,人的耳朵可以分辨出回声,超过400ms,人 的感觉就会很差,造成很严重的语音质量问题。
(6)语音间断/滑动测试(测试在一定压力下NGN系统对语音的处理能力)
语音间断是指语音在传输过程中出现断裂,一般在20ms以上的断裂需要统计,一次连续语音中的断裂总长度与语音长度之比称为“语音间断比”,信息产 业部的测试规范中要求其不能超过2%。语音滑动是指语音在传输过程中两端出现滑码变形,一般在20ms以上的需要统计,一次连续语音中的滑动总长度与语音 长度之比称为“语音滑动比”,信息产业部的测试规范中要求其不能存在,否则视为语音质量不好。根据语音间断和语音滑动的次数和每次的时间长度,可以计算出 语音间断比和语音滑动比。
(7)其他性能测试
其他NGN系统性能测试还包括:视频性能及视频质量测试、传真性能及传真质量测试、Modem性能及Modem质量测试等。
作者:厉红雷 来源:通信世界周刊
漫谈.Net中的自动垃圾收集(Garbage Collection)机制
作者:cornfield
一直以来,垃圾收集(Garbage Collection)在软件界的名声并不好。很多程序员认为垃圾收集做得不如自己来的直接,高效。这种说法有些时候是对的,一个精心为自己的特定程序设 计定制的内存回收方法,肯定比为所有程序提供垃圾回收性能要高。但那对程序员要求甚高,一个项目下来花在内存回收的设计上的时间和精力是很可观的,而稍有 不慎便会酿成灾难性的错误,技术再高超的程序员负担不起,整个现代软件工业也负担不起。把这样普遍而又繁重的任务交给系统处理,将程序员从中解脱出来专注 于事务逻辑和系统功能的实现,已经成为软件业的共识。
微软新推出的.Net平台架构便引入了自动垃圾回收机制,本文将详细解剖其中的原理,回答诸如垃圾回 收怎样工作?怎样控制垃圾回收?什么时候需要控制垃圾回收?什么又是垃圾回收不能解决的?等等重要问题,为.Net平台下的系统开发人员提供设计时的参 考。
要搞清楚.Net 运行时的垃圾回收机制,首先需要搞清楚.Net运行时内存分配的情况。.Net 运行时对受管资源(Managed Resource)采用对象引用的堆式分配(Heap Allocation)方法。这种分配方法大多数时候是非常快的。一个实际系统的内存总是有限的,当系统的剩余的可分配的内存资源不多时,.Net 运行时便会“预见”到下面的内存资源将可能不会满足下面的内存分配请求,于是它便会开始执行垃圾回收释放那些系统不再引用的内存资源。
.Net垃圾回收器 采用的是一种叫做“标志紧缩”(Mark and Compat)的算法。每当垃圾收集开始,.Net垃圾收集器从运行时目前的根对象(包括全局对象,本地对象,静态对象,CPU寄存器对象),开始寻找那 些被根对象引用的所有对象,这些对象便是在垃圾收集时运行时正在应用的对象,除去这些,其他的受管运行时对象(Managed Runtime Object)便是系统不再使用的对象,于是便可以进行垃圾收集。所有引用的对象被向下拷贝到运行时受管堆(Runtime Managed Heap),同时修改它们的引用指针。
需要指出的是,在.Net垃圾收集器移动引用对象和改变引用指针时,系统不能在这些对象上有任何操作,这一点由运行 时的互斥机制来保证,无需程序员干涉。 遍历目前所有被引对象的耗费往往是巨大的,实际上也不必这样做。一个经验的认识是,当一个对象在内存中驻留的时间越长,那么它越有可能继续被引用留在内存 中。相反,一个对象在内存中驻留时间越短,它越有可能被收集。.Net收集器采用一种称作“代分”(Generation Division)的方法来体现这种经验的内存驻留理论。它把受管堆中的对象分成三代(Generations). 第一代是没有经历过垃圾收集驻留在内存中的对象,他们通常是一些局部变量,它们的生命最短。第二代是仅经历过一次垃圾收集仍然驻留在内存中的对象,它们通 常是一些如表单,列表,按钮等生命较短的对象。第三代是经历过两次及两次以上的垃圾收集后仍然驻留在内存中的对象,它们通常是一些应用程序对象,它们往往 要在内存中驻留很长时间。
当运行时收集器开始执行垃圾收集时,它首先对第一代对象进行垃圾收集,这通常会释放较大的内存空间,往往会满足下面的内存请求。 如果这一代的收集结果不理想,那么便会对第二代读像进行收集,同样如果还不理想,便进行第三代的垃圾收集。 .Net垃圾回收机制支持一种称作终止化(Finalizaion)的概念。这有点类似C++中的析构函数。终止化操作在垃圾收集执行后进行一些非受管资 源的清除工作,它在.Net运行时里有很多限制,往往不被推荐实现。当程序员对一个对象实现了终止器(Finalizer)后,运行时便会将这个对象的引 用加入一个称作终止化对象引用集的链表,作为要求终止化的标志。当垃圾收集开始时,若一个对象不再被引用但它被加入了终止化对象引用集的链表,那么运行时 将此对象标志为要求终止化操作对象。待垃圾收集完成后,终止化线程便会被运行时唤醒执行终止化操作。显然这之后要从终止化对象引用集的链表中将之删去。
容 易看出来,终止化操作会给系统带来额外的开销。终止化是通过启用线程机制来实现的,这有一个线程安全的问题。.Net运行时不能保证终止化执行的顺序,也 就是说如果对象A有一个指向对象B的引用,两个对象都有终止化操作,但对象A在终止化操作时并不一定有有效的对象A引用。所以.Net运行时不推荐对对象 进行终止化操作,只是在有非受管资源如数据库的连接,文件的打开等需要严格释放时,才应用终止化操作。 大多数时候,垃圾收集应该交由.Net运行时来控制,但有些时候,可能需要人为地控制一下垃圾回收操作。例如在操作了一次大规模的对象集合后,我们确信不 再在这些对象上进行任何的操作了,那我们可以强制垃圾回收立即执行,这通过调用System.GC.Collect() 方法即可实现,但频繁的收集会显著地降低系统的性能。
还有一种情况,已经将一个对象放到了终止化对象引用集的链上了,但如果我们在程序中某些地方已经做了 终止化的操作,在那之后便可以通过调用System.GC.SupressFinalize()来将对象的引用从终止化对象引用集链上摘掉,以忽略终止化 操作。始终应该清楚的是,终止化操作的系统负担是很重的。 综上所述,.Net垃圾回收机制负责回收系统不再使用的受管内存资源,它通过一定的优化算法来选择收集的对象和时间。程序员只有在释放大量受管资源时可以 进行立即强制垃圾收集,在释放非受管资源时采用终止化操作来处理,其它时间将资源的回收交由.Net垃圾收集起来做。
| 2009-2011© 编译点滴 | Suffusion theme by Sayontan Sinha |
近期评论