高通放弃自主架构应是谣言

简介:

近日一篇文章指高通骁龙830将放弃自主架构,随着ARM发布低性能的A35和高性能的A72核心,高通继续采用自主架构将导致成本过高而难以与各手机企业开发的手机芯片相竞争,这应该是一种谣言,高通不会放弃自主架构。

采用公版核心的教训

这几年随着联发科积极开发多核心架构,高通的自主架构开发无法跟上联发科的发展进程,在2014年采用了ARM的公版核心A57和A53设计其高性能芯片骁龙810,但是由于A57核心的发热过大,导致骁龙810存在发热现象而成为其高端芯片中最失败的产品。

高通骁龙810的发热问题估计也与台积电有一定关系,台积电在2014年获得苹果A8系处理器订单,台积电当时选择了优先照顾苹果,将最先进的20nm工艺优先提供给苹果,再加上苹果推出的iPhone6热卖导致台积电的20nm产能被用光,导致高通的骁龙810投产时间过迟没有足够的时间进行优化,也成为骁龙810发热的因素之一。据说后期的骁龙810已经没有发热问题,例如华为代工的采用骁龙810的nexus 6P就没有发热问题。

发热问题最终导致其骁龙810因为发热而在去年可以说是大败,高通的骁龙8XX系列芯片下降可能达到60%,去年三季度的业绩暴降44%。
采用自主核心的好处

今年高通再推高端芯片骁龙820的时候采用了自主架构kryo,其不在与联发科拼多核,而是主打单核性能。据geekbench的测试,其单核性能高达2200以上,高频版单核性能更达到2450接近苹果A9的2500,是Android市场性能最高的芯片!

华为海思的麒麟950采用ARM的公版核心A72和A53,并且采用了台积电最先进16nmFF+工艺,其单核性能也只有1712,落后骁龙820超过20%。

三星也已经成功开发出自主架构猫鼬,采用四核猫鼬+四核A53核心的Exynos8890成为Android市场性能仅次于骁龙820的芯片。

采用自主架构,芯片企业可以对处理器的功耗、性能进行深层的优化,达到最优。骁龙820的kryo核心设计主频可以达到3GHz,而ARM的高性能公版核心最高主频只能达到2.5GHz。高通的骁龙820采用自主架构,实现了高效的处理器与专用内核组合,以最低功耗、最高效的通讯模式实现内部CPU、GPU、ISP、DSP等的协同运作,并且未来随着手机芯片整合的功能增多,异构计算将成为市场主流,而ARM公版核心存在着模块间通讯性不强软肋。

正是有鉴于采用公版核心的存在问题,联发科采用了多核来与高通竞争,但是业界发现其实多核对于手机来说远不如单核性能高更重要,在Android市场手机处理器已经发展到十核的情况下苹果的A系处理器一直采用双核架构,凭借着超强的单核性能为用户提供了最好的体验,而且联发科和华为海思也表达了要开发自主架构的意向。
高通放弃自主架构可能性不大

从骁龙810的失败,32位时代的自主架构Krait的成功,以及眼下骁龙820采用自主核心kryo的优异成绩,高通应该得出结论采用自主架构的重要性。

其实高通也并没有完全放弃ARM公版核心,其已经采用ARM的公版核心A72和A53推出了中端芯片骁龙65X系列,目前采用骁龙652的三星A9已经发布上市,从表现来看这枚处理器与华为思麒麟950差不了太多,加上高通自家优秀的GPU adreno基带技术,整体与麒麟950各有特点。

如果高通再用公版核心开发自己的高端芯片骁龙830,那样无疑是与目前对骁龙65X的定位所矛盾。

总结来说,高通只会加强对自主架构的开发,而不是放弃,以保持与ARM公版核心的差异性,再用ARM公版核心架构的芯片应对华为海思、联发科的竞争。

本文转自d1net(转载)

相关文章
|
架构师 安全 区块链
带你读《自主管理身份:分布式数字身份和可验证凭证》——第5章 SSI架构:大局观(1)
带你读《自主管理身份:分布式数字身份和可验证凭证》——第5章 SSI架构:大局观(1)
带你读《自主管理身份:分布式数字身份和可验证凭证》——第5章 SSI架构:大局观(1)
|
数据安全/隐私保护 API 区块链
带你读《自主管理身份:分布式数字身份和可验证凭证》——第5章 SSI架构:大局观(2)
带你读《自主管理身份:分布式数字身份和可验证凭证》——第5章 SSI架构:大局观(2)
带你读《自主管理身份:分布式数字身份和可验证凭证》——第5章 SSI架构:大局观(2)
|
前端开发 Android开发
在抛弃 MVP-Clean 后,我自主设计并开源了 Viabus 架构
版权声明:本文为博主原创文章,转载请注明作者和链接。更多请继续关注 KunMinX 前言 前不久刚结束对 20 模块项目的第 3 轮重构,一路见证了 MVC、MVP、Clean 的优缺点并形成自己的体会。
1780 0
|
17天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
15天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
15天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
33 1
服务架构的演进:从单体到微服务的探索之旅
|
13天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
35 8
|
14天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
42 5
|
17天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
40 7
|
16天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
32 5