amd

有问有答 在处理器中拥有多个内核有什么好处？ https://www.expreview.com/69110.html 某日Intel和AMD发现了单核处理器是有极限的，然后他们都不做单核了开始了多核处理器的道路，实际上到了现在单核处理器基本在PC和手机领域消失了。单核处理器：明明……明明是我先来的，但……为什么会这样呢？ 16核32线程的处理器都要进入主流市场了 其实说白了就是想做一个超强的单核处理器难度实在是太高了，想提升处理器的单核性能无法就两条道路，一是通过架构的改良提升处理器IPC，二是直接提升处理器的频率。架构的改良需要大量的时间和资源投入，别看现在Intel和AMD一年弄一个新架构出来，实际上他们大部分时间都是在原有架构上小修小改来提升性能，这样不但更容易更快速，而且不容易翻车。架构的大改虽然可能带来较大的性能提升，但是也有时会弄出不适合的产品而大溃退，较好的正面例子就是Intel的Core、Sandy Bridge和AMD的Zen架构，而反例则是Intel的奔腾4和AMD的推土机处理器。 而想提升处理器的频率也不是简单的事情，处理器的频率不单止和架构有关，和所用的制程工艺的关系更大，实质上是摩尔定律已经失效了，这个影响了半导体行业50年的金科玉律随着硅基芯片物理极限的到来已经失效了，从28nm节点之后其实就没有带来很大的性能改进了，而且功耗问题也越来越严重。

首先是定义： explicit关键字只能修饰只有一个参数的 构造函数 ，或者有多个参数，但是除第一个参数外其他的参数都有默认值的构造函数。它的作用是表明构造函数是显式方式显示的。（类构造函数默认为隐式） 如果类构造函数参数大于或等于两个时, 是不会产生隐式转换的, 所以explicit关键字也就无效了 举个例子： class AMD{ public: AMD(int level){ //这里的构造函数默认就是隐式声明 ..... } ..... } 在这种情况下，如果运行以下语句： AMD a(3); AMD b=10; 这两种都是没有问题的，第二句 AMD b=10; 没有问题的原因是： C++中, 如果的构造函数只有一个参数时, 那么在编译的时候就会有一个缺省的转换操作:将该构造函数对应数据类型的数据转换为该类对象. 也就是说 AMD b=10 在实际执行时操作等同于以下语句： AMD b(10); //或者 AMD c(10); AMD b = c; 虽然解释的通了，但是这种写法仍然是不友好的，毕竟 AMD b=10 这种写法看上去就像是将整数赋值给对象，显得不伦不类，而且在复杂代码中容易让人感到迷惑 -->所以现在就要使用到explicit关键字了 经过explicit修饰后： class AMD{ public: explicit AMD(int level){ /

当主板的sata设置为AHCI或RAID模式时，原版Windows操作系统安装光盘在安装时可能找不到硬盘。 Windows XP原版安装光盘中不包含SATA AHCI和RAID驱动程序，使用nlite把下面的驱动集成进xp安装盘即可。能够解决CQ40等笔记本主板中无法关闭AHCI，导致无法安装原版xp的问题。 Windows 7原版安装光盘中包含了部分南桥芯片的SATA AHCI驱动，比如Win7自带SB700驱动，但是Windows 7上市之后出现的SB850等等芯片需要加载驱动。把驱动下载下来放在U盘、光盘、硬盘里，在“您想将Windows安装在何处？”的界面，点下面的“加载驱动程序”，即可。 AMD sata驱动 名称：RAID Driver 版本：3.2.1548.37 更新地址： http://drivers.mydrivers.com/drivers-3601-87-AMD/ 更新地址： http://game.amd.com/us-en/drivers_chipset.aspx 更新地址：http://drivers.mydrivers.com/drivers-502-87-AMD%EF%BC%88ATI%EF%BC%89/ Intel sata驱动 名称：Matrix Storage Manager 或 Rapid Storage Technology 版本：8.9

一、javascript模块化编程规范： 二、关于commenjs规范和AMD规范： 根本不同：前者用于服务器端同步加载模块；后者是客户端异步加载模块。 同点：两者都有一个全局函数require（）,用于加载模块；只是AMD规范中的require函数需要有2个参数。 三、 CommonJS 出现时间更早，代表有： Node.js 的 模块系统 ，就是参照 CommonJS 规范实现的。在CommonJS中，有一个全局性方法require()，用于加载模块。假定有一个数学模块math.js，就可以像下面这样加载。 var math = require( 'math'); 然后，就可以调用模块提供的方法： var math = require( 'math'); math.add(2,3); // 5 服务器端模块以后，很自然地，大家就想要客户端模块。而且最好两者能够兼容，一个模块不用修改，在服务器和浏览器都可以运行。 但是，由于一个重大的局限，使得CommonJS规范不适用于浏览器环境。 　　var math = require('math'); 　　math.add(2, 3); 第二行math.add(2, 3)，在第一行require('math')之后运行，必须等math.js加载完成。也就是说，如果加载时间很长，整个应用就会停在那里等。

JavaScript模块化规范主要遵循CommonJS和AMD规范。 CommonJS规范 -服务器端JavaScript规范 Node.js是一个服务器端JavaScript项目，采用了CommonJS标准实现其模块系统。 CommonJS中采用一个全局require方法来加载模块，主要由原生模块module来实现和完成，该模块在启动时已经被加载。 模块主要分为两类：原生模块，文件模块。 1.原生模块 原生模块也是Node.js中最核心的模块。原生模块在Node.js源代码编译的时候编译进了二进制执行文件，加载的速度最快。 Node.js中存在许多原生模块，例如：http,net,os,path,fs, module等等，其引用方式为var fs = require('fs'); 2.文件模块 文件模块是动态加载的，加载速度比原生模块慢。但是Node.js对原生模块和文件模块都进行了缓存，在第二次require该模块时，是不会有重复开销。 文件模块可细分为3类。这三类文件模块以文件后缀来区分，Node.js会根据后缀名来决定加载方法。 .js。通过fs模块同步读取js文件并编译执行。 .node。通常为npm安装的第三方模块。 .json。读取文件，调用JSON.parse解析加载。 虽然Node.js使用require方法引入模块的方式看似简单，但内部的加载却并不简单

JavaSript模块化 在了解AMD，CMD规范前，还是需要先来简单地了解下什么是模块化，模块化开发？ 模块化是指在解决某一个复杂问题或者一系列的杂糅问题时，依照一种分类的思维把问题进行系统性的分解以之处理。模块化是一种处理复杂系统分解为代码结构更合理，可维护性更高的可管理的模块的方式。可以想象一个巨大的系统代码，被整合优化分割成逻辑性很强的模块时，对于软件是一种何等意义的存在。对于软件行业来说：解耦软件系统的复杂性，使得不管多么大的系统，也可以将管理，开发，维护变得“有理可循”。 还有一些对于模块化一些专业的定义为：模块化是软件系统的属性，这个系统被分解为一组高内聚，低耦合的模块。那么在理想状态下我们只需要完成自己部分的核心业务逻辑代码，其他方面的依赖可以通过直接加载被人已经写好模块进行使用即可。 首先，既然是模块化设计，那么作为一个模块化系统所必须的能力： 1. 定义封装的模块。 2. 定义新模块对其他模块的依赖。 3. 可对其他模块的引入支持。 好了，思想有了，那么总要有点什么来建立一个模块化的规范制度吧，不然各式各样的模块加载方式只会将局搅得更为混乱。那么在JavaScript中出现了一些非传统模块开发方式的规范 CommonJS的模块规范，AMD（Asynchronous Module Definition），CMD（Common Module Definition）等

/** * CommonJS 模块化规范 * CommonJS规范加载模块是同步的，也就是说，只有加载完成，才能执行后面的操作 */ /*-------Node.js遵循Commonjs规范---------*/ //写法1. var exports=module.exports; exports.name="leyi"; exports.fn=function(){ return 'hello world!' }; //写法2. module.exports={ "name":'leyi', "fn":function(){ return 'hello world!' } }; //写法3. module.exports=function(){ this.name='leyi'; this.fn=function(){ return 'hello world!' } }; /** * AMD 模块化规范 -推崇依赖前置 * AMD规范则是非同步加载模块，允许指定回调函数。由于Node.js主要用于服务器编程，模块文件一般都已经存在于本地硬盘， * 所以加载起来比较快，不用考虑非同步加载的方式，所以CommonJS规范比较适用。 * 但是，如果是浏览器环境，要从服务器端加载模块，这时就必须采用非同步模式，因此浏览器端一般采用AMD规范。 */ /*-------require

1 简介 AMI 异步方法调用(AMI) 这个术语描述的是客户端的异步编程模型支持。 如果你使用AMI 发出远地调用，在Ice run time 等待答复的同时，发出调用的线程不会阻塞。相反，发出调用的线程可以继续进行各种活动，当答复最终到达时， Ice run time 会通知应用。通知是通过回调发给应用提供的编程语言对象的 AMD 一个服务器在同一时刻所能支持的同步请求数受到Ice run time 的服务器线程池的尺寸限制（参见15.3 节）。如果所有线程都在忙于分派长时间运行的操作，那么就没有线程可用于处理新的请求，客户就会经验到不可接受的无响应状态。异步方法分派(AMD) 是AMI 的服务器端等价物 ，能够解决这个可伸缩性问题 。 在使用AMD 时，服务器可以接收一个请求，然后挂起其处理，以尽快释放分派线程。当处理恢复、结果已得出时，服务器要使用Ice runtime 提供的回调对象，显式地发送响应。 使用AMD时，客户端如果需要等待返回值，那就一直等待，否则就继续往下执行。 为什么使用AMD? 用实际的术语说， AMD 操作通常会把请求数据（也就是，回调对象和操作参数）放入队列 ，供应用的某个线程（或线程池）随后处理用。这样，服务器就使分派线程的使用率降到了最低限度，能够高效地支持数千并发客户。 另外， AMD 还可用于需要在完成了客户的请求之后继续进行处理的操作

AMD与Intel 　　AMD处理器即由AMD公司生产的处理器。AMD( 超微半导体 ) 成立于 1969 年，总部位于加利福尼亚州桑尼维尔，目前AMD是唯一能与英特尔抗衡的CPU厂商，旗下的独立显卡部门也和NVIDIA平分天下。 　　同主频的AMD处理器与Intel处理器，前者价格只是后者的一半左右，intel处理器的稳定性比AMD处理器的稳定性更好，AMD处理器的发热量比intel处理器的发热量大，但综合起来，AMD的性价比高。 AMD产品阶段 第一阶段 　　80486至AMD K6阶段。初期的产品策略主要是以较低廉的产品价格为诉求，虽然最高性能不如同期的Intel产品，但却拥有较佳的价格性能比。 第二阶段 　　K7阶段。K7的性能尤其是在浮点运算能力方面，受到不少DIY（自行组装计算机）用户的欢迎。由于相对于Intel，AMD对于CPU的倍频锁定限制较松，因此广受许多超频用户的欢迎。但也由于缺乏过热保护，超频过度的K7系列CPU有较高的烧毁风险，导致部分消费者对其稳定度的信心偏低。 第三阶段 　　K8阶段。由于率先于Intel之前优先投入64位CPU的市场，使得AMD在64位CPU的领域有比较早发展的优势，此阶段的AMD产品仍采取了一贯的低主频高性能策略，解决因为电气性能有限导致CPU不稳定和发热量、耗电功率过大的问题，并导入使用IBM开发的SOI技术

一、UMD：AMD 和CommonJS的糅合 前面花了很长的篇幅介绍了两大类模块规范，CommonJS( Modules / Modules/Wrappings )及 AMD 。 我们知道Modules/Wrappings是出于对Node.js模块格式的偏好而包装下使其在浏览器中得以实现。 而Modules/Wrappings的格式通过某些工具（如 r.js ）也能运行在Node.js中。事实上，这两种格式同时有效且都被广泛使用。 AMD以浏览器为第一（browser-first）的原则发展，选择异步加载模块。它的模块支持对象（objects）、函数（functions）、构造器（constructors）、字符串（strings）、JSON等各种类型的模块。因此在浏览器中它非常灵活。 CommonJS module以服务器端为第一（server-first）的原则发展，选择同步加载模块。它的模块是无需包装的（unwrapped modules）且贴近于ES.next/Harmony的模块格式。但它仅支持对象类型（objects）模块。 这迫使一些人又想出另一个更通用格式 UMD (Universal Module Definition)。希望提供一个前后端跨平台的解决方案。 UMD的实现很简单，先判断是否支持Node.js模块格式（exports是否存在），存在则使用Node