英特尔2018-2020年的处理器路线图
Intel官方表态2019年底10nm工艺都不会量产,这意味着2020年之前英特尔的处理器还都是14nm工艺,从服务器芯片到桌面芯片再到移动芯片、超低功耗芯片,14nm依然是英特尔的主打,10mm还要再等一年。工控主板
没有10nm工艺支撑,但是英特尔的处理器还是要继续更新,推特网友Dayman做了一份英特尔2018-2020年的处理器路线图,我们来看下英特尔的处理器未来一年半内都是如何升级进化的吧。
从高端到低端来看: ·首先是服务器市场的SP系列处理器,目前是Skylake-SP处理器,今年Q3季度之后是Cascade Lake-SP系列,明年Q3季度之后则是Copper Lake-SP,2020年Q3季度则会是10nm工艺的Icelake-SP处理器。
·Core X系列中,现在的是Skylake-X、Kaby Lake-X,Q4季度之后有Cascade Lake-X,明年Q4之后则是Copper Lake-X,2020年Q4季度会有Icelake-X。
·针对桌面的S系列中,现在的是Coffee Lake-S,按照之前的爆料8核还是coffee lake-s架构,但会变成9代酷睿,撑过2019年Q4季度之后会有10nm工艺的Icelake-S,2020年Q4则会有第三代10nm处理器Tiger Lake-S。
·移动处理器中,H高性能系列现在是Coffee Lake-H,明年到2020年Q1季度都会是Coffee Lake Refresh H系列,2020年Q2季度则会是Icelake-H 45W系列。
·低功耗的U系列中,15W系列今年会有Wiskey Lake-U,到2019年Q3季度会升级到10nm工艺的Icelake-U,2020年Q3季度会有Tigger Lake-U。
28W系列中,Coffee Lake-U将在明年Q2季度后会被Commet Lake-U接替,之后在2020年Q2季度再被Tiger Lake-U取代。
·Y系列中,现有的是Kaby lake-Y,Q3季度会Amber Lake-Y接替,明年Q3季度会有Icelake-Y,2020年Q3季度则是Tigger Lake-Y。
·Atom产品线中,现在的Gemini Lake后续产品还不太明朗,下下代是Jasper Lake,要到2020年Q1季度了。
创立50年来,英特尔在PC上的功劳没得说,但是自从智能手机登上历史舞台之后,PC的地位受到了严重冲击,各种移动设备都想取代PC的中心地位。在这个过程中,英特尔公认的失败就是没能成功打入移动市场,现在移动设备所用的芯片几乎都是ARM架构的,高通在移动市场的地位依然不容动摇,英特尔也没能改变这个局面。要说英特尔这几年最大的失误,那就是一直没能打入移动市场,错过了智能手机发展的黄金时期,这也让英特尔付出了巨大代价,7年来浪费了170亿美元,每年亏损25亿美元。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
如何解构单体前端应用——前端应用的微服务式拆分
刷新页面?路由拆分?No,动态加载组件。 本文分为以下四部分: 前端微服务化思想介绍 微前端的设计理念 实战微前端架构设计 基于 Mooa 进行前端微服务化 前端微服化 对于前端微服化来说,有这么一些方案: Web Component 显然可以一个很优秀的基础架构。然而,我们并不可能去大量地复写已有的应用。 iFrame。你是说真的吗? 另外一个微前端框架 Single-SPA,显然是一个更好的方式。然而,它并非 Production Ready。 通过路由来切分应用,而这个跳转会影响用户体验。 等等。 因此,当我们考虑前端微服务化的时候,我们希望: 独立部署 独立开发 技术无关 不影响用户体验 独立开发 在过去的几星期里,我花费了大量的时间在学习 Single-SPA 的代码。但是,我发现它在开发和部署上真的太麻烦了,完全达不到独立部署地标准。按 Single-SPA 的设计,我需要在入口文件中声名我的应用,然后才能去构建: declareChildApplication('inferno',()=>import('src/inferno/inferno.app.js'),pa...
- 下一篇
核心金融场景分布式事务
分布式事务是分布式系统架构设计中的一个技术难点,特别是在这几年越来越火的微服务架构中,服务拆分所带来的跨服务数据一致性问题亟待解决,本文将围绕分布式事务产生背景和蚂蚁金服的分布式事务解决方案(SOFA-DTX)向大家进行介绍。 1、分布式事务产生的背景 1.1、数据库的水平拆分 通常业务系统的数据库起初是单库,但随着业务数据规模的膨胀,单库存储受容量和性能限制,逐渐无法满足业务需求。 如下图所示,将业务数据库水平拆分成多个数据库,是业务发展的必然趋势。 数据库拆分之后,写操作一旦跨多个数据库,单数据库事务就无法保证数据一致性,需要通过分布式事务来保障跨数据库操作的数据一致性。 1.2、业务服务化拆分 在业务发展初期,“大饼一沱”的单业务系统架构,能满足基本的业务需求;但是随着业务的快速发展,系统的访问量和业务复杂程度都在快速增长,单系统架构逐渐成为业务发展瓶颈,解决业务系统的高耦合、可伸缩问题的需求越来越强烈。 如下图所示,按照面向服务(SOA)的架构的设计原则,将单业务系统拆分成多个业务系统,能降低各系统之间的耦合度,使不同的业务系统专注于自身业务,更有利于业务的发展和系统容量的伸缩...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Mario游戏-低调大师作品
- Docker安装Oracle12C,快速搭建Oracle学习环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2更换Tomcat为Jetty,小型站点的福音