×

x86架构

为什么x86的构架只有因特尔跟AMD可以研发呢?PowerPC CPU为什么后来越来越打不过x86,因为酷睿

admin admin 发表于2023-02-02 22:36:45 浏览91 评论0

抢沙发发表评论

本文目录

为什么x86的构架只有因特尔跟AMD可以研发呢

说来真的是话长。

刚好五十年前,也就是1968年,Intel公司成立,创始人是大外鼎鼎的Robert Noyce和Gordon Moore,Noyce是硅谷之父,集成电路发明人之一(因为去世的早没拿成诺贝尔奖),而Moore大家可能更为熟悉,因为他就是摩尔定律的预测人。

在七十年代,Intel推出了8086和8088处理器,正好碰上当时的巨头IBM(现在IBM也是巨头,但当时Intel和微软还不名一文)要重锤进军个人计算机领域(也就是今天说的PC),开发自己的IBM-PC,IBM-PC采用的CPU就是Intel的8088,采用的操作系统的微软的MS-DOS,正是这个机遇,才成就了今天英特尔和微软的帝国伟业。

扯得有点远,后来Intel又推出了80286,这是一款非常的成功的处理器,差不多当时所有的IBM-PC兼容电脑都用的是Intel的CPU。而x86架构最先是在8088中出现,所以Intel后面的CPU都是以此架构作为基础的,x86也因Intel处理器在IBM-PC中占据绝对领先地位而闻名。

当时IBM为了规避风险,不能让一家供应商卡住脖子,要求至少有两家公司能提供同类产品,这种情况下,Intel就把x86架构授权给了当时的AMD公司,为什么是AMD不是其它公司呢?这多半是因为AMD的创始人和Intel的创始人以前是同事,这样AMD就把Intel的CPU重新设计优化,以第二供应商的身份向IBM提供处理器。

AMD借此机会,也开始发力芯片研发,在2003年推出了首款64位的桌面处理器(Opteron),AMD把这个x86-64的专利也授权给了Intel,当然这几十年来Intel和AMD间打了无数官司,比如Intel禁止AMD生产386处理器,AMD诉讼Intel垄断等,都为了x86架构专利的那点事。

经过几十年的发展,x86架构已成为PC的事实标准,Intel和AMD也将更多的指令和功能集成到这个架构中,使它越来越完善高效。而这两家也控制着x86架构几乎所有的专利,其它公司想研发和生产x86处理器,必须有Intel或AMD的授权方可,比如VIA就是Intel授权的,又如天津海光是AMD授权的(准确说是AMD授权处理器IP)。

PowerPC CPU为什么后来越来越打不过x86,因为酷睿

1994年起,苹果的电脑开始全面使用PowerPC芯片,在性能上是吊打英特尔的X86芯片的。为此,苹果公司还在广告中吹嘘过。

当时,苹果确实有吹的资本,PowerPC不仅是苹果电脑御用芯片,还是微软Xbox游戏机用芯片,一大半的服务器也是PowerPC芯片的粉丝。

在技术上,PowerPC确实有自己的优势,比如第一个飙到4GHz,第一个提出并践行多核心设计理念,第一个推出单核心多线程(类似英特尔的超线程技术)。

但乔布斯回归之后,PowerPC芯片开始走下坡路,由于它面对单一专业市场,出货量没有X86的大众消费市场大,加之坐享一亩三分地,慢慢在性能功耗比上落了下风。对服务器等行业来说,性能落后一点可以忍,但性能落后还耗电就不能忍,因为服务器是24小时开机,耗电量大的话,电费会成为服务器大头。

服务器用着爽,交电费很不爽。


而且芯片耗能增加,用电成本很快会超过服务器价格。

相反,英特尔通过改进微架构,同时在摩尔定律的加持下,性能功耗比很快超过PowerPC芯片。

不仅在性能功耗比上落后,PowerPC的迭代速度也慢于英特尔X86芯片,这让乔布斯很不爽,一时没忍住,向PowerPC芯片的设计和制造方摩托罗拉抱怨,要求它生产性能更强的芯片。

本来甲方向乙方发发牢骚,乙方要提现服务精神,听着加安慰就能摆平,但时任CEO克里斯.高尔文脾气也很大,不仅和乔布斯大吵一架,还不理会他的要求。

说白了就是,乙方活不好,服务态度还差!

这就让甲方乔布斯不能忍了,不到18个月就果断换芯,采用性能更强的英特尔X86芯片。

PC端电脑现在为什么不做arm架构,依然坚持X86架构

Pc端电脑现在是有arm架构的,只不过数量非常少,还没有在消费市场上形成潮流。

所谓的ARM架构还有x86架构,指的都是芯片CPU的架构。那么说到芯片,目前的两大阵营,英特尔代表了x86,ARM的代表有很多,只说PC端的话,国产芯片有鲲鹏和飞腾。

华为的鲲鹏,现在正在积极的整合资源。在美国对华为进行技术封堵之后,华为可以说是all in鲲鹏,从服务器到pc电脑全面转向arm架构。

中国电子旗下的飞腾,也是ARM架构芯片的实践者。借助信创项目,也是在pc领域和服务器领域开疆拓土。

说完芯片,接下来就得说说操作系统了。底层的芯片不会被我们直接所操作,我们是通过操作系统来去操作芯片的。操作系统目前比较流行的,分为两大类,一个是windows,另一个就是Linux;Windows统治桌面,Linux统治服务器。

但是现在有一个非常重要的问题,就是windows对ARM的支持不太友好,对ARM支持有好的,只有Linux。如果使用Linux操作系统,服务器侧还好说,在服务器这一领域,Linux操作系统本来就占据了绝大部分的市场份额。但是在pc电脑侧,Windows占据了绝对的主力。Windows环境下的应用和linux环境下的应用是不兼容的,这给Linux在桌面操作系统的生态建设造成了巨大的困难。

在操作系统这个领域,生态就是王,生态就是决定一切的关键要素。试想,如果你是一家软件公司的开发团队,基于Windows开发了一个桌面应用,如果想兼容Linux,还得重新再开发一遍,你会怎样?windows在pc桌面上的应用非常多多,全产业生态的程序员都在基于windows环境进行软件开发,

导致Linux在桌面环境下的应用极度匮乏,这反过来又导致Linux在桌面端的应用推广愈发困难。最终的结果就是windows一家独大,连带着ARM架构在pc端的推广也是举步维艰。

一切的一切,都是生态造成的。

x86架构的安卓系统平板电脑,可以运行pc软件吗

不能,无论什么架构的平台,安卓系统和微软系统核心不同,包括软件安装包或者软件之间并不能直接运行。而且安卓运行的是.apk,而微软系统运行的是exe.但是大部分微软系统运行的软件,商家会有出相应的安卓版或ios版,例如QQ,暴风影音,迅雷之类的。

为什么同样是8G运行内存,Windows能同时开一大堆后台进程和前台应用,而Android不可以

windows属于pc操作系统,主要的目的是尽量发挥硬件的计算性能。它不用考虑能源消耗,可以长时间保持cpu全速运行,可以不考虑内存容量,不行就用硬盘缓存。android是移动操作系统,要保证在能量消耗受限制的情况下,设备提供可接受的计算性能。所以,要明确区分对客户有用的程序,把有限资源分配给客户最希望的程序。尽量把临时信息存储在内存而不是rom中,以节省电量和加快运算速度。这两个策略的不同,造成它们在不同领域都有更好的表现。其实,android的linux内核如果调整后放到pc机上,能比windows同时运行更多的应用。windows裁剪后的wiodows mobile也比android更省电,反应更快。

小米平板2win版和64G安卓版各有什么优缺点

本人没用过小米的,但手上有个双系统的平板,英特尔平台,在安卓系统下cpu对系统的支持那只能叫一个差,有些程序用不了没法安装,无法使用。当时买时就是看上了双系统加高分辨率的屏。切换系统到win10,那叫卡,开机后得等上个五六分钟才能正常使用软件支持不多。

为什么同一个应用ios比Android大那么多呢


首先下载时所用的IPA和APK都是ZIP文件,比较压缩前的体积才有意义,iOS上46M的QQ就是因为一点没压缩。其次反对最上面说是因为资源文件的问题,不是每家公司的美工都爱偷懒的。对于常见的应用,个人认为体积大的原因是是iOS上的可执行文件比Android上的字节码文件体积大太多,以常用的QQ为例。iOS上的可执行文件在未压缩前是44M,压缩后是20MAndroid版QQ的执行文件有点多这个是主文件这3个是库文件四个加起来,压缩前是20M,压缩后共11.4M,也就是说可执行文件的iOS版比Android版在压缩前多了24M,压缩后多了8M。再看看IPA文件和APK文件的体积:对比上面的可执行文件体积,可以说在手机QQ中,Android版的资源文件比iOS版多了一倍。


针对占用应用体积大小的大户图片资源,来尝试回答下这个问题

.1. 一个应用的影响大小因素很大一方面是来自于资源,而非代码,一般应用主要的是图片资料,比如图标,背景,图片等.2. iOS 对于图片资源的要求严格一些、

2.1 从屏幕密度上说: 比如 iOS 上屏幕密度不同,得支持 iPhone 6 Plus (3倍),iPhone 6(2倍) iPhone 3GS(1倍)那么你必须提供三种屏幕密度的图片资源,即: 60x60,40x40,20x20, 如果不提供的话,至少在 iOS 7之前则会显示文件缺失.这方面 Android 的机制复杂但宽松一些:说复杂是因为 iOS 的图片资源主要有屏幕密度作为区别(在 iOS 8中也加入了几个屏幕大小的类别),但是 Android 呢,你可以看到: 根据Android 关于资源的官方文档 Providing Resources上面所列举出来的 Table 2. Configuration qualifier names. 有18大项之多.不仅包含屏幕密度,长,宽,大小,比例,方向,语言,还包含其他 N 多情况. 这是复杂的一面.按理来说,Android 的应用应该比 iOS 的大才对.但是事实并不是这样的.因为 Android 的限制宽松一些.就拿屏幕密度来说,iOS 的屏幕密度现在就三种,(如果不考虑老的设备的话,就算两种了)但是 Android 的设备,你知道千奇百怪,很多种--不过基本也在1倍,2倍,3倍,左右.如1.5倍, 2倍, 2.2倍,2.5倍等等. 屏幕密度很多种,怎么办? Android 在一开始设计的时候就提供了这样一个解决方法:即,如果1.5的设备,对应图片不存在,如果有2倍或以上的倍数的图片就用相应的图片,缩放后使用.上面文档关于屏幕密度的与资源的匹配说明如下:

Note: Using a density qualifier does not imply that the resources are only for screens of that density. If you do not provide alternative resources with qualifiers that better match the current device configuration, the system may use whichever resources are the best match.

这样造成的一种情况就是:很多应用其实都是主要使用一份屏幕密度的图片资源,比如我看微信 Android 版本,有一个版本的资源图片主要集中在3倍上. 这样一来,Android 应用就比 iOS 设置少了两份屏幕密度的资源了.

在这里稍微总结一下:Android 的图片资源查找规则是查找最匹配的一个,最终查找到有就不会出错.而 iOS 在 iOS 7之前呢,则就是查找匹配的资源.对于一般的图片,图标来说,从96x96压缩到72x72对外观应该没有什么影响(具体我没有测试过),所以导致 Android 中提供的资源少一些.

2.2 上面说了屏幕密度,那屏幕大小呢? Android 的屏幕大小也是众多的,反正我是说不清倒底有多少,但是 iOS 呢? 我估计你稍微查找下资源,是可以穷举过来的. 例如 iPhone 从3GS到5S 屏幕的宽度都可以表述为320点宽对设计和实现上有这么一些影响:1. 也许你已经知道,很多设计师一般是以 iPhone 为参考大小来设计的.这个时候举一个例子:假充我需要有一个设计上有一个背景,320x240, 这样设计师,切出来之后,就是320x240再出一份,640x480的, iOS 开发者,放上去直接可用 - 搞定,到面透气去了.Android 开发者,这个时候就苦逼一点了,因为 Android 的屏幕宽度比例众多,怎么搞?一开始 Android 开发工具提供了一个叫 Draw-9-Patch 的软件(我就不具体描述这个软件有多难用了,反正用过的都说坑,--- 后来这个软件可以拖动了,1年成集成进 Android Studio,更好用了),这个软件就是用来画点九(.9.png)图片,点九图片的概念具体我就不解释了(基主要是一个图片四条边,左边和上边可定义可扩展区域,右边和下边可以用来定义内容区域)然后花几分钟,或者补学者,慢一点10多分钟,将一张图片处理好,作为背景来说,可自动根据大小拉伸缩放.(最典型的案例其实是,如聊天用的气泡背景图)上面的问题造成这样的可能:一张背景图在 iOS 因为至少有两份,而且是原图大小可能要10多 K.但在 Android 这边制作成点九格式之后一般是1K 不到.

说明: 在设计上,(主要内容区域)纯色的背景下点九处理是再好不过了,但是有些纹理的就会导致最终的效果差强人意了. 说明2: 在 iOS 中,Xcode 5也加入了制作类似点九图的功能叫 Slicing.(之前也可以在代码中,设置图片的edge 来达到点九的效果,但是一般用的情况不多- 这是由于 iOS 设备尺寸种类有限决定的)说明3: iOS 比 Android 更容易在应用中还原设计. Android 中由于尺寸众多,导致开发者对设计还原的妥协. 所以一般的应用大小反而更低,但是美观上略输(针对现在,以前是输很多),其实从某些方面来说,这也是近年影响扁平化设计的一个因素,纯色远比纹理,阴影,高光处理来得方便.

总结: Android 系统资源宽松灵活,使得 Android 应用体积较小,但是设计上不如 iOS 精致

为何arm架构的GPU性能远超X86构架

这纯粹是一个外行提出的子虚乌有的命题。首先,没有x86架构的显卡,那叫x86平台,x86指的是CPU架构!其次,arm架构gpu性能都是以省电为基础设计出来给手机和平板等便携设备用的,就这一点就已经决定了它性能不可能超越插x86平台显卡,更不要说DX等图形API的差别了。

为手游开发的游戏,背景大部分都已经替代成了贴图,而不是3D场景,这大大减少了gpu的运算负担。而电脑游戏,很多细节都是经过gpu优化处理的,运算量和arm相比是几何倍的增长。而且x86平台的gpu相当于新技术的实验场,光追,dlss等等新技术都是x86平台先使用的。新的rtx3090功耗350w,这种耗电量也决定了它的性能级别。

我建议作者好好看看你所说的游戏细节处理,看看平板和电脑的画面区别。另外,还有很多同类型的游戏,比如《我的世界》,平板和电脑的画面绝对有很大不同,特别是最新的光追版。电脑上的画面绝对震撼到你。

MIPS架构和ARM架构有什么异同点,它们的优势和劣势分别是什么

很高兴可以回答这个问题,接下来我简单分享下自己的理解和想法,希望可以帮助到大家。

目前市面上使用的指令集大致可以划分为两种,即复杂指令集,简称CISC;精简指令集,简称RISC。而MIPS和ARM采用的都是精简指令集。

精简指令集(RISC),诞生于20世纪80年代,是一种指令集较短的类型,相比复杂指令集(CISC)运行速度会更快,更高效,它可以在短短的几秒钟时间里面执行上百万条指令。MIPS架构和ARM架构都是使用了精简指令集(RISC)。

两者之间有什么异同点呢?

ARM架构的特点

  • 体积小、低功耗、低成本;
  • 寻址方式灵活简单,执行效率高;
  • 指令执行使用3级或5级流水线的技术;
  • 指令和数据里面有Cache,使用了大量的寄存器,指令执行速度更快;
  • 指令长度固定,即使用32位的ARM状态,使用16位的Thumb状态。

MIPS架构的特点

  • 较早支持64位指令和操作;
  • 有专门的除法器,可以执行除法指令,;
  • 内核寄存器更多,功耗更低;
  • 指令稍多,部分运算更灵活高效;
  • 允许授权商自行更改设计。

MIPS架构相较于ARM架构的不足

  • 目前市场上的移动设备还是ARM架构的物理多核占据优势,而MIPS架构的并行线程存在感低;
  • MIPS内核受限于高容量内存配置,这主要是受到MIPS在内存和cache的限制;
  • MIPS架构自身的软件应用匮乏,ARM架构的软件应用要比它多很多;
  • MIPS架构仅支持顺序单和双发射,而ARM架构支持乱序双和三发射。

综上所述,ARM架构相较于MIPS架构存在诸多的优势,这也就促成了当今ARM架构的市场占有率。

以上是我个人的理解和看法,如有不足之处,还请大家多多指教,喜欢的可以点赞关注下,谢谢!

为啥arm架构比x86 x64省电

这个问题可以扩展为:为什么arm架构的芯片都那么省电!

引言

最初的ARM架构被设计成即使是一个相对简单的指令译码器,也能以架构允许的最大速度运行。

后来的ARM版本有稍微复杂一点的指令解码逻辑,但是每条指令都是一个或两个单词长。

在x86架构上,指令可以是1字节长,也可以是14字节长。

在设计最初的x86架构时,指令是按顺序执行的,而且每个指令都需要多个周期才能执行。

如果执行一条指令需要三个周期,那么找到下一条指令的起始点也需要三个周期。

另一方面,现在人们很难忍受x86代码运行得那么慢了。

设计能够快速运行x86指令的硬件是有可能的

20年前,你可能会认为复杂的指令解码会限制x86的速度,但事实并非如此。

x86架构要求英特尔和其他芯片制造商,包括一些相当复杂的转换和缓存逻辑,以便一段代码第一次运行时,就转换成易于解码的形式。

如果代码再次运行,则可以跳过转换。可纵然是非常快的芯片,这些逻辑也消耗能量。

相对而言,许多低功耗ARM芯片的前端逻辑要少得多。

x86有这么缓存转换性能,arm比不上;可是,没有了额外技能加身的x86,比arm要逊色的多。

说说功耗

在低功耗的应用中,ARM处理器一直是首选,现在仍然是首选。

比较功耗并不是一件简单的事情。操作系统、RAM大小和类型、闪存和使用的接口等方面需要与处理器的影响分开。

然而,一般的规则是,ARM在关闭处理器和等待唤醒的模式和可能性方面非常强大。这种空闲模式是指操作系统正在运行,但只等待输入(例如来自鼠标、键盘或应用程序的输入)。

X86处理器的预期功耗大约为1瓦特。在i.MX6处理器的功耗将是这个数字的一半。

此外,ARM高端部分得益于少数状态/模式,这些 状态/模式 (states/modes)的功耗低至100mW,而不牺牲合理快速唤醒的可能性。

低功耗有许多优点。

手持式和电池供电的产品,将受益于增加电池寿命。做产品设计则可以使用更小的电池。由于需要更小的冷却装置,材料清单、BOM成本和产品尺寸可能会进一步减少。

写在最后

天下武功,唯快不破!小而快而全的arm架构普及也得益于其自身设计上的权衡。

Happy coding :)

我是@程序员小助手,持续分享编程故事,欢迎关注。