Google developing own CPUs for Chromebook laptops
asia.nikkei.com
asia.nikkei.com
But Apple, Google, and Amazon are now creating their own ARM CPUs for their own products. So most of FAANG, all if you count the ones with consumer products.
The first version of these CPUs will be very ARM compatible, as they are trying to drive adoption to of their silicon. Once there get a leg up they will start adding patented operation to their stuff. And then we'll end up with a fragmented CPU field driven by corporate greed.
And because they are not OEMing this hardware, they really have no incentive to be cooperative with the others. Similar to older gaming console that had custom and experimental architectures.
However it is obvious why this is all happening. And that is Intel and Qualcomm inhibited growth and squeezed too much profit from the market.
As such, it isn’t actually an issue.
As an example, if the kernel doesn’t know of DMA channels, and it requires setup code to prevent user-level code from using them to copy across process boundaries, the kernel will run fine, but have glaring security problems.
Now, I'm typing this on a GNU/Linux machine, but let's face it, all of the nuisances I mentioned are legit and constant source of problems in tech support forums.
https://mobile.twitter.com/ErrataRob/status/1331735383193903...
Rosetta is also a long way from 1:1 performance, even you're own link says ~70% the speed. That's closer to half speed than it is to full speed.
The M1's main trick to being so good at running x86 code is it's just so god damn fast for the power budget it doesn't matter if there is overhead for emulated code it's still going to be fast. This is why running Windows for ARM in parallels is fast too, it knows basically none of the "tricks" available but the emulation speed isn't much slower than the Rosetta 2 emulation ratio even though it's all happening in a VM.
In a fun twist of fate 32 bit x86 apps also work under Windows on the M1 even though the M1 doesn't support 32 bit code.
The result of those is that the expensive atomics aren’t applied to all accesses at all on hardware that doesn’t expose a TSO memory model.
As far as applying it the default assumption for apps is they don't need it and heuristics can try to catch ones that do. For well known apps that do need TSO it's part of the compatibility profile to increase the barriers to the level needed for reliable operation. For unknown apps that do need TSO you'll get a crash and a recommendation to try running in stricter emulation compatibility but this is exceedingly rare given the above 2 things have to fail first.
Details here https://docs.microsoft.com/en-us/windows/uwp/porting/apps-on...
Sure about that? Couldn't it lead to silent data corruption?
I think the main reason why it hasn't been disastrous is that most programs rely on locks, and they're going to be translating that to the equivalent ARM instructions with a full memory barrier.
Not too many consumer apps are going to be doing lockless algorithms, but where they're used all bets are off. You can easily imagine a queue where two threads grab the same item from, for instance.
=> when comparing speed, 70% is about exactly halfway between 50% and 100% (the midpoint being 100%/√2 ≈ 70.7%)
I think you mean either "100% faster" or "faster than a speed of 70" there.
(The parent commenter also works at CodeWeavers, so he would know :P)
M1 is fast and efficient, but Rosetta 2 does not emulate x64 in real time. Rosetta 2 is a static binary translation layer where the x86 code is analysed, translated and stashed away in a disk cache (for future invocations) before the application starts up. Static code analysis allows for multiple heuritstics to be applied at the binary code translation time where the time to do so is plentiful. The translated code then runs natively at the near native ARM speed. There is no need to appeal to varying deities or invoke black magic and tricks – it is that straightforward and relatively simple. There have been mentions of the translated code being further JIT'd at the runtime, but I have not seen the proof of that claim.
Achieving even 70% of native CPU speed whilst emulating a foreign ISA _dynamically (in real time)_ is impossible on von Neumann architectures due to the unpredictability of memory access paths, even if the host ISA provides the hardware assistance. This is further compounded with the complexity of the x86 instruction encoding, which is where most benefits the hardware assisted emulation would be lost (it was already true for 32-bit x86, and is more complex for amd64 and SIMD extensions).
> This is why running Windows for ARM in parallels is fast too, it knows basically none of the "tricks" available but the emulation speed isn't much slower than the Rosetta 2 emulation ratio even though it's all happening in a VM.
Windows for ARM is compiled for the ARM memory model, is executed natively and runs at the near native M1 speed. There is [some] hypevisor overhead, but there is no emulation involved.
x86 apps with JITs can run [1]. For instance I remember initially Chrome didn't have a native version, and the performance was poor because the JITted javascript had to be translated at runtime.
[1]: https://developer.apple.com/documentation/apple-silicon/abou...?
I've seen mentions of a JIT path but only if the AOT path doesn't cover the use case (e.g. an x86 app with dynamic code generation) not as an optimization pass. https://support.apple.com/guide/security/rosetta-2-on-a-mac-...
Windows decided to go the "always JIT and just cache frequent code blocks" method though. In the end whichever you choose it doesn't seem to make a big difference.
> Windows for ARM is compiled for the ARM memory model, is executed natively and runs at the near native M1 speed. There is [some] hypevisor overhead, but there is no emulation involved.
This section was referring to the emulation performance not native code performance:
"it knows basically none of the "tricks" available but the _emulation speed_ isn't much slower than the Rosetta 2 emulation ratio "
Though I'll take native apps any day I can find them :).
AOT (or, static binary translation before the application launch) vs JIT does make a big difference. JIT always carries a pressure of the «time spent JIT'ting vs performance» tradeoff, which AOT does not. The AOT translation layer has to be fast, but it is a one-off step, thus it invariably can afford spending more time analysing the incoming x86 binary and applying more heuristics and optimisaitons yielding a faster performing native binary product as opposed to a JIT engine that has to do the same, on the fly, under tight time constraints and under a constant threat of unnecessarily screwing up CPU cache lines and TLB lookups (the worst case scenario for a freshly JIT'd instruction sequence spilling over into a new memory page).
> "it knows basically none of the "tricks" available but the _emulation speed_ isn't much slower than the Rosetta 2 emulation ratio "
I still fail to comprehend which tricks you are referring to, and I also would be very much keen to see actual figures substantiating the AOT vs JIT emulation speed statement.
The thing about their contributions is that they upstream stuff they want other people to standardize on but aren't doing it out of love, as far as I can tell e.g. Valve have a direct business interest in having Linux kicking ass, Apple actively loses out (psychologically at least) if a non-apple toolchain is as good as theirs.
Nowadays less so, for them C++ support is good enough for what they make out of it (MSL is based on C++14 and IO/Driver Kit use an embedded subset).
The main focus is how well it is churning Objective-C, Swift and their own special flavour of bitcode.
None of them end up upstream as one might wish for.
Compilers aren't great at using the real parameters of the chip (i.e. LLVM knows how wide the reader buffer is but I'm not sure if it actually can use the information), but knowing latencies for ISel and things like that is very helpful. To get those details you do need to rely on people like (the god amongst men) agner fog.
P.S. GCC descs are a goldmine for old arch's.
Yeah i think we fail to see this common pattern of negative (even monopolistic) long term effects because we are distracted by the trade-offs or benefits the company promises us initially (but betrays later).
Microsoft too! https://www.microsoft.com/en-us/surface/business/surface-pro...
And of course RaspberryPi: https://www.arm.com/blogs/blueprint/raspberry-pi-rp2040
Some industries are awfully complex and getting into it requires insane amounts of work. x86 processor making is one of these. It's the same as making new browser engines/js JIT/etc. There is just so much work that catching up with the incumbents is almost impossible.
¹Not sure what happened to that x86 license that Cyrix had.
“x86-64/AMD64 was solely developed by AMD. AMD holds patents on techniques used in AMD64; those patents must be licensed from AMD in order to implement AMD64. Intel entered into a cross-licensing agreement with AMD, licensing to AMD their patents on existing x86 techniques, and licensing from AMD their patents on techniques used in x86-64. In 2009, AMD and Intel settled several lawsuits and cross-licensing disagreements, extending their cross-licensing agreements.”
⇒ I think only Intel and AMD currently can freely implement x64.
There’s also https://newsroom.intel.com/editorials/x86-approaching-40-sti...:
“However, there have been reports that some companies may try to emulate Intel’s proprietary x86 ISA without Intel’s authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation (“code morphing”) techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta’s x86 implementation even though it used emulation.”
That was seen as a message to Microsoft (https://arstechnica.com/information-technology/2017/06/intel...)
Microsoft in the 90s might have been the only company positioned appropriately to try but compared with Amazon, Google, and Apple, they did not have as much of an "in" into people's daily lives the way all three of those companies do today.
Unregulated capitalism leads to the company store, which is I think effectively where GP was suggesting things were headed.
Furthermore this model is fundamental to the ARM architecture. The whole point is for licensees to develop SOCs with their own custom components on the same die. That's literally what a SOC is.
As an aside that is monopolistic behaviour which at least California and EU are in top of. Companies have to be careful exploiting their dominance in an area.
maybe an “in” and dominance are different, if they are it doesn’t matter
The problem is that "better" is being defined by the companies spreading the marketing propaganda about their products, and that has an unfortunate effect on the perception of the users. It's sad that most of the population would simply take it at face value if a company told them something was "better", but if you realise that making users unquestioning and under their control is ultimately a great way to extract more $$$ from them, it all makes sense.
Partially, but I don't think this is nearly as big of a factor as lots of FOSS people on the internet these days seem to think. Remember that RMS wrote a lot of the original GNU tools by himself and wrote the beginnings of GCC. Stallman could have just chosen to reject C and not write GCC altogether the way a lot of modern FOSS advocates seem to act about rejecting closed software. Unix and C could have been cast as proprietary enemies to reject, but he understood at the time that to gain traction, FOSS needed software that was usable for similar purposes as proprietary software. We can cry conspiracy all day but the hard work of building good products is what ultimately wins the day.
(Network effects on modern social/messaging platforms are a much more complicated story however.)
Microsoft, for example, licensed Windows to vendors for decades with the requirement they not have another operating system pre-installed. This killed both "closed and better" and "open and better" systems alike!
It's about who has more capital to aggressively out price competition, even by taking ridiculous losses. Or buy promising startups, or litigate potential competitors into oblivion.
Diapers.com for example. It's not about anything close to sales and marketing.
Browser-based games and real-time 3D applications are the one's I'm most excited about, personally but that may be because I'm developing a WASM startup in this space.
Go work with wasm in the browser, you will pull your hair out at the fact emscripten is still the most used tool. It's all very hackey and if something breaks, you wont fix it.
So x86, basically.
The proprietary cpus will only run software obtained from the corresponding app store.
You can take that to the bank.
Mixed upon that.
Upside - getting software made more portable across architectures and with that, the choice of an ARM or X86 desktop also makes porting to other cpu types less of an effort. Then drivers and lets cut to the crux - support for other hardware via drivers is what holds any other architecture back from the start.
Downside - Moving towards more and more closed/secret source CPU's that more locked in and if they become the norm, then a whole level of developing becomes way harder.
Whilst I'm sure many more upsides and a few other downsides, the real upside in all this will be even better ARM support by the commercial apps. With that, I really do think Apple with the M1 done wonders for ARM and the whole ARM environment.
This allows Apple to deprecate/change those extensions over time without developer involvement, and even use Cortex reference designs where it would make sense for them.
Or, it's just the regular old way capitalism works. Any sufficiently large company will start to vertically integrate to maximize their profits. If not Apple / Google, it could have been Intel / Qualcomm who started vertically integrating by offering their own laptops, phones, OSes and App Stores.
The big fish eats the small ones. That's capitalism 101.
> The first version of these CPUs will be very Arm compatible, as they are trying to drive adoption to of their silicon.
All these CPUs will be Arm compatible, otherwise they will be breaking their license.
> Once there get a leg up they will start adding patented operation to their stuff. And then we'll end up with a fragmented CPU field driven by corporate greed.
Maybe they will add accelerators as Apple has done but Arm compatible code will still run on all these CPUs.
> And because they are not OEMing this hardware, they really have no incentive to be cooperative with the others.
Yes they do because they need Arm code to run on them.
There are thousands and thousands of Arm designs in use and they _all_ run Arm code as specified by Arm Ltd.
(And yes I know that there is fragmentation in other things that go on the SoC but that is a different point).
But it doesn't help anyone to fragment too much.
Reference?
What you are allowed to do is make extensions with the highest tier of arch licenses, you however cannot break the ISA.
fuOS/CustomKC will stay in the long term, and that's what matters for other OSes.
Probably outdated article on this: https://www.electronicsweekly.com/news/business/finance/arm-...
That's not going 'hog wild'!
At base ISA level perhaps. But there will also be extensions for AI, DSP, media encoding, etc which will be incompatible. You nominally wouldn't have to use those, but the CPU will be nothing special without all that. This problem is already quite pervasive in the ARM ecosystem, and it'll get worse over time. There's no way around this. In a power-sensitive environment the only realistic way out currently is specialized co-processing and ISA extensions.
To be clear there is little risk in anyone manufacturing truly proprietary chips. ARM licensing ranges from "you shall produce exactly to spec" for those wishing to vertically integrate commodity parts to "you may freely modify" -- but in either case it's the ARM design being licensed. It does nothing but harm the licensee to build something novel and strange functionality.
This system has been working quite well for Arm for decades at this point. If anything, the fact that well-known brands like Apple and Google are spinning ARM chips speaks volumes to Arm's excellent business model. Nothing we've seen from either tech giants is truly revolutionary -- the smaller fabs have been doing the same things for years.
Why anyone ever sold Arm, I will never understand.
And there are countless counter-examples when IP law causes harm to consumers and inventors.
>"legitimate business models"
And what makes them legitimate? IP law is an artificial construct which currently serves select few. Why should not I be able to "invent" something and sell it without the worries just because somebody else happened to have the same idea? And many of the existing patents, especially ones in a software field can be "invented" by any reasonably intelligent Joe Doe in a few minutes if there is a need.
"It makes me money" is not in and of itself a successful business model.
It's the endless extension of copyright (hello, Mickey Mouse) and granting excessively wide patent rights (e.g. on whole classes of chemical compounds) that does not serve the initially envisioned good purposes. Overdose is bad, whether you use table salt, a medicine, or a law.
ARM in particular is not known for abuse of the system, so indeed they are a positive example.
Oracle and Fujitsu will still sell your business SPARC servers, but I don't know that I'd buy that business unit (never mind that I don't have that kind of money). It's easy to buy the lottery ticket after you've got the winning numbers. ARMs successful now but there was a lot of luck and hard work up get there.
The 68K line was the Itanium of it's time. It overpromised and underdelivered and was crushed by the 286 and 386. Many vendors made machines based on it (Atari ST, Amiga, Mac, Sun Microsystems, Sinclair QL, ...) and all of those vendors either went out of business or transitioned to RISC architectures in a hurry. It was one of the many near death experiences the Mac platform had.
It was more successful than the beautiful losers such as the TMS9900, iAPX 432, i860, NS32000, but it hit the end of track and left everyone in the lurch.
But I think a lot of this usage goes back to the days where embedded CPU families had been a lot more fragmented, and companies usually picked one family of their favorite supplier (based on pricing, fulfilling the use-case, etc) and then just sticked to it due to code not being particularly portable.
Since that time the amount of CPU families that are actually used shrank drastically, and it's a lot more likely that all of those use-cases just pick ARM.
ARM as an architecture may be on solid ground, but their future as a company may be uncertain given that their IP seems to have been appropriated by the CCP.
On the other hand, there's a global supply chain appetite for cheap products including CPU's. Upstream commits aren't required to dump cheap CPU's on the market or to develop compute intensive businesses around them that undercut the competition on price.
High-end CPUs, hardly. That would require significant design efforts to keep up with ARM's development.
Not that it'd be impossible for China to develop their own strong processor-designing forces, driven commercially or by the state. But so far it seems far from a trivial task.
We're talking about instruction sets with ARM, correct? It's not anywhere near the level of investment as next generation litho tech for a chip foundry?
I don't underestimate the ability to innovate. Stolen tech can be improved just as well as in-house R&D'd tech.
Soon, those companies will move beyond China as well.
Even Intel had trouble surviving on 14nm, hence all the contra-revenue spent to directly subsidize Intel tablets (whether they were $100 HP Stream Windows tablets, or $50 Walmart special Android tablets) to try and not get locked out of that space.
Well, maybe the fact that not so long ago it had none of that and it clearly looks like both the company and the political regime aren't having many problems getting their hands on all the missing pieces.
If the smartphone market is an indicator, too bad that this will just mean that the majority of OEMs will just buy their chips from ARM china and thus demand for ARM IP will expectedly drop, and meanwhile this IP appropriation will just be used to develop independent design capabilities.
I'm really not sure what that means. Does ARM china have fabs?
https://en.wikipedia.org/wiki/Arm_Ltd.#Arm_architectural_lic...
Do we know that Apple has a special arrangement not available to other licensees?
Near as I can tell, in terms of licensing rights the only major difference is that they purchase an "architecture license" that gives them the right to create more custom designs, but this is a license available to and purchased by other companies like Qualcom, Intel, and others. And if Apple has lower royalty rates, it may simply be a product of their scale rather than special treatment.
But I don't know this for sure-- only that a little bit of searching didn't find anything obvious about special arrangements.
To make a quick buck, and who cares about timeframes other than short term? ;)
/s
Not just this thread, but on HN. Hardware and their business model is a thing where signal to noise ratio is extremely low on HN.
If it wasn't because of a few working in ASML, ARM, embedded programming adding some immense value of input to balance things out, Hardware on HN is no different to any other forum on the internet.
The F in FAANG - Facebook - has consumer products (notably, the Oculus VR headset).
Also Netflix spun out their consumer product into another company (Roku).
Why would they go out of their way to make it harder for devs to target their ecosystems?
Here's what I see happening: the majority of application development now takes place within architecture-agnostic languages/frameworks/platforms. The platforms solve the problem of multi-architecture once, and then everyone else can get on with their business without thinking about it. Fragmenting the hardware itself mainly serves to open the door for more finely-grained optimizations by these platforms (interpreters, browsers, LLVM, etc).
Look to graphics APIs for comparison: OpenGL was a relatively high-level API because that's what game devs and others were usually writing directly. Now that most game dev happens in engines like Unity and Unreal, or even on platforms like the Web, only the platform/engine developers have to write actual graphics code a lot of the time (excluding shaders). And they want more fine-grained control, so we're switching to lower-level graphics APIs like Metal and Vulcan because the needs for the baseline API have shifted.
So what I see is not a difference in the total fragmentation from the average dev's perspective, just a shifting of where the abstraction happens.
The only issue is with commercial software, but even there JIT enabled emulation is a possible solution.
Oracle too, whose CPU's btw are ~20% faster than aws graviton2. Looks like they use Ampere Altras.
And what should they have done instead? Is it up to companies themselves to forge their own competition? Or did you snooze at the opportunity.
X64 is still decoupled but how long will it survive with ARM designs like the M1 or Graviton blowing it out of the water?
The thing we really have to beware of is an oligopoly of vertically integrated vendors locking up all high end fab capacity, making it impossible to even fab a competing design if you can design one.
Not only do we need a revival of antitrust, but we need competitors to TSMC badly. Samsung and Intel are close on its heels but that’s not enough.
The CPUs in the M1 are competitive because they build on Arm's IP which others can and are doing (Google, Amazon, Qualcomm Samsung already and others can join them) which is a much less oligopolistic position than Intel / AMD having the market to themselves.
That was my point. Diversity doesn’t matter. It’s diversity of what can be sourced on the open market that matters.
So tell me that isn’t a more open market than say 3 years ago when you basically had to buy Intel.
I find these arguments bizarre - we’ve had many, many years of Intel monopoly on the desktop and server and finally we have some competitors and people are worried about the market being closed up? Seriously?
It's not that intel and qualcomm have squeezed too much profit, it's that Apple, Google, Facebook, etc have too much profit. Apple and Google are worth $2 trillion. Facebook is worth more than $1 trillion. Intel and Qualcomm are worth $300 billion put together. These tech companies are big enough and monopolistic enough to own their entire hardware stack. It's like when Rockefeller and Standard Oil got so big that they "bought" the railroads that transported their oil.
Apple and Google each make more profit than Intel and Qualcomm's combined revenue.
Semiconductors are a capital intensive and brutal business, as evidenced by Intel's recent fall - they basically made one architectural mistake and that slip up cost them the lead on multi-threaded performance for probably 5-8 years, assuming they can get it back.
Separately, Rockefeller's coercion of the railroads was not something he did because he was big, it was something he did to become big. He would strong-arm his way into controlling or coercive positions at railroads, then cut off his competitor's ability to transport their product. When they were struggling, he would buy them up at distressed prices and turn the rails back on.
I know. I didn't say they were going to sell commodity chips. Just that they were big enough to own their own stack.
> Separately, Rockefeller's coercion of the railroads was not something he did because he was big, it was something he did to become big.
No. It was something an already large SO did to get bigger. If Standard Oil wasn't big, it could never coerce the railroads to begin with.
> When they were struggling, he would buy them up at distressed prices and turn the rails back on.
I know. But small insignificant standard oil didn't do this. It was big standard oil on its way to even bigger and better things.
It all leads to technical debt. They will make their own devices and keep them in-house. Then they will modify software to leverage these devices. Eventually they will loose touch with the standards. This will go well, for a while. Then something will go wrong. Their chip development will run into a roadblock and they will want to return to the standard. But by that point the cost of reverting will be far to high. They will be stuck with their in-house chips for better or worse. This isn't healthy. Sticking with the community standards on fungible hardware, or better yet contributing to them, is always the better long-term bet.
In marked contrast to the blissful years of the utopian Intel/AMD duopoly? (:
With custom ARM SoCs we are going to see extreme platform lockdowns. (What most people here don't get, or are being deliberately obtuse about, is that ARM's IP are used to build System-on-Chips where the ARM processor is just one of the units. It is other custom parts of the SoC that allow you to lockdown and make the SoC incompatible with other ARM SoCs).
This is how Apple ARM SoCs only fully support ios / macOS, Google's will only support Android / ChromeOS, Microsoft's ARM SoC will only fully support Windows etc, and will enforce platform lockdown.
To understand why this is happening, we have to recognize the shift in the business model of BigTech - They want to turn everything into a service that will earn them recurring revenue. Platform lockdown will ensure they can force users data on to the cloud by pushing cloud services on these device and limiting their hardware. While initially they will lock down personal data too on to their specific cloud services, regulation may force them to allow "data transfer" between the BigTech services to give consumers the illusion of choice.
Remember, PRISM has showed US government how valuable it is to have access to personal data from corporates and how easy it is when it is on the "cloud". BigTech's worldwide reach will allow them to literally spy on anyone in a few decades and the US needs that ability to maintain its influence on world politics.
I predict a very bleak future for personal computing, where the concept of ownership of computers or computing device will no longer exist - your device in the future will be fully controlled by the BigTech, and we will have no computing freedom to even install any open source code on "our" device.
BigTech is already experimenting with "cloud coding" - this means they will even have access to all your codes in the future too - in such a scenario no competitor will emerge in the future to be able to dislodge them for centuries until they lose political backing.
So right now you can buy from Intel / AMD (completely closed source and with ME nonsense etc). License your IP from Arm for a not excessive fee and inspect the code or use open source RISC-V implementation.
And finally writing code for Arm / RISC-V doesn’t require any sort of legal agreement or authorisation.
If you want to go back to 1982 then fine. I'll keep running on my Arm and RISC-V cores thanks.
I do find the enthusiasm for the utterly closed oligopoly of x86 (with all the dubious ME stuff), with literally no modern open source hardware implementation, odd when you could be getting behind RISC-V.
> And because they are not OEMing this hardware, they really have no incentive to be cooperative with the others. Similar to older gaming console that had custom and experimental architectures.
What exactly is this referring to? Are you saying that game consoles should only use chips that are available to other manufacturers, or that every game console should be an IBM-PC compatible, like the first Xbox.
Wouldn't such a divergence merely only increase the demand for compiler-backend/VM engineers making this job segment more attractive ?
I understand Apple's end game. They sold lots of iPhones and wanted to in-house the chips for that. Makes sense. Once they had that working well (and Intel was falling behind on their chips), they decided to put in-house chips in their macOS computers. Makes sense.
AWS rents more CPU time than anyone out there. Makes sense for them to want to develop some custom chips for their stuff.
What's Google's end game? They don't actually sell a lot of chips. I'd understand them wanting to create a server chip, but they seem to be targeting phones and laptops. Is Google looking to become a major player in Android hardware? I like the Pixel phones, but they're a very small part of the market. Chromebooks are usually built by companies like HP and Acer, not Google directly.
The article says that Google's Pixel sold 7M units in 2019 (their highest year) and they're looking for 50% more than that (so 10.5M) for the Pixel 6. In 2019, Apple shipped 215M iPhones (over 30x the Pixel). Is Google looking to make the Pixel a much larger part of the Android ecosystem? Are they looking to compete directly with HP, Acer, and others in the Chromebook market?
I guess I wonder what the end-goal is here. Maybe the premium on Qualcomm's Snapdragon chips is so high that they'd rather make their own. Maybe they want to become the primary hardware vendor in the Android ecosystem - or at least a much larger one. But Google never seems to push its own hardware aggressively so it's a bit curious.
The Android OEMs are trapped in a perpetual race to the bottom, so they can’t afford to invest in premium hardware features. Google has realised the only way for them to compete head on with Apple on hardware enabled features is to design their own hardware because nobody else is going to do it.
I think there are a lot of android phones that have had premium features: e.g. foldables, 90-120 Hz refresh rates (Apple only recently caught up), Vivo x70 Pro Plus w/ an amazing camera that beats the best iPhones (https://www.youtube.com/watch?v=n0r2rENgvwY), etc.. I think there's just a perception that Apple hardware is better, but I feel like they put in above average hardware overall w/ good polish. These are all hardware features. Sure, the performance of Qualcomm chips lag Apple's, but that's because Apple's engineering team is better than Qualcomm's (IMO). I am sure that Samsung, etc. would buy a faster chip for their flagships if it was available. E.g. Samsung, etc. typically fill their flagships with crazy amounts of RAM and Storage.
Disclaimer: My views are my own, and not of my employers.
The problem is that Apple is the hardware vendor getting recurring revenue from usage. Qualcomm needs you to buy a new phone to see anything more, only Google gets a cut of you buying stuff on the Google Play store, etc. That gives Apple both much larger revenues per customer and an incentive to keep your old phone working as long as you’re buying stuff with it. Google trying to get into that model seems healthy from the perspective of getting better competition but worrisome for the level of resources needed to compete.
A lot (but not all for sure) of the A-series chip performance advantage comes from a massive on-die cache for example. That's not fancy engineering, just brute force transistor count. Qualcomm engineers could absolutely do that, but Android handset economics won't support it.
The Intel situation is more obviously, but could you elaborate on this? Was it to improve margins or for CPUs optimized for phones?
Because almost no one uses Chromebooks except Google employees, so far their strategy involves contracting all the developers they can.
There were ~30M Chromebooks sold in 2020[1]. I think many of those were sold to non-googlers.
[1] https://www.statista.com/statistics/749890/worldwide-chromeb...
Some of those landed here in German stores, where they usually get reduced every couple of weeks until finally someone buys them.
Here in Germany they tend to stay on some corner being increasingly reduced until someone finally buys them.
Seriously, try using a Chromebook in anything other than the crippled "guest mode" without giving it your telephone number, a telephone-number-linked gmail account, or jailbreaking it. You can't (unless it's part of a corporate/education site bulk purchase).
Completely moronic policy decision.
Most Chromebooks at the low price point use awful low-end intel CPUs that seem unable to cope with opening more than 2 tabs at once. If Google can create a CPU that is competitive in performance and price to those terrible Intel based ones, but also chuck in some hardware assistance for ML inference on-device, they're likely on to a winner.
Consumers will get more power efficient devices.
Intel may get affected by this.
Would love to see another Pixelbook with great performance and stability for Linux apps.
However, shops like Netbook Billiger and Tuxedo Computers would be my options for a future replacement.
No idea what would work out on your region.
1. I can run any Android app on the device. I find this incredibly useful.
2. On the ChromeOS side of things, everything really "just works" for me - the Pixelbook is a really great combo of hardware and software.
3. There definitely were some Linux hiccups but they continually improved over time. The was container backups work in the UI is especially simple and easy to use.
It's basically a ChromiumOS distro you can install on normal PC hardware. The company that runs it was acquired by Google some time back too.
I'll keep my RK3399 laptop, thank you very much. I can (and have) programmed every processor in the device, including the PMU.
You can't say the same thing about your IME/PSP.
The reduced cost from mastering processes will mean companies are competing on price; which, is typically good for consumers and awful for the businesses involved. If anything, as we really push physics to its limits, the largest companies will likely be forced into cooperation to make any reasonable gains via something like RISC-V because of diminishing returns.
I believe "Machine Learning" will be what leads the way for eventual commoditization of processor fabrication. Pretty much what Relativity has done with 3D printing rockets: using ML to correct, predict, and/or even utilize, what would now-a-days be considered physical flaws to produce extremely perfect parts... but instead of rocket parts, it'll be lithography and CPU fabs one day.
Absolutely not. The proved you can beat intel at lower transistor counts, at more or less similar frequencies.
Now, the fact that vertical integration usually implies closed doors is relevant, yeah; but I don't think anyone is denying credit anywhere, and I think it's important to acknowledge upsides.
Does the recent removal of apps [1] from russian appstore ring some bells?
[1]: https://www.nytimes.com/2021/09/17/world/europe/russia-naval...
Only sometimes. Have you ever tried unlocking a Pixelbook to run a different OS?
It needs a custom cable and significant RE efforts by the community.
For the average consumer — everything.
I'm kind of torn between the two opinions. I wish my iPhone would be able to run anything I want to run. I also recognize that nobody forced me to buy this iPhone.
Mobile phones are mandated to have emergency calling functionality. Maybe in the future we'll have some "general purpose computing as a human right" law.
> I'm kind of torn between the two opinions.
I am not torn. Because of us two, apparently only one lives in an authoritarian country. When your computing device blocks you from accessing anything not praising the current regime, it kinda devalues the user-friendly interface and manufacturing quality. Shiny chains are still chains.
I also welcome tech companies trying to extract every tiny bit of performance from the silicon that powers computing today. It may lead to developing something incompatible with existing solutions, but surely no regime on this planet is to blame here.
From my perspective Apple just made it so non Apple hardware couldn't get fast CPU's for another year.
M1 is a 5nm CPU that is faster than 7nm low power CPU's, and uses less power than 7nm high power CPU's, but to me it isn't obvious that it will perform significantly better than others 5nm low power CPU's when those hits the market. Others 5nm will hit the market once Apples contracts to use all 5nm fabs runs out, but before then we are stuck with only Apple having that tech.
You might think that this situation sounds great, but it doesn't look that great to me. I'd prefer if Apple didn't work to lock in hardware components and tech as they do.
Yes without Apple’s money TSMC would have still built 5nm, but likely a few years later.
ex. https://wccftech.com/apple-secures-3nm-tsmc-chip-production/
Because humanity and every company now has access to 5nm infrastructure? Because Apple created the greatest marketing campaign TSMC ever benefited from? Because Apple proved that custom silicon design is no longer fools gold and can be profitable and competitive? Because Apple showcased that more instruction parallelism, heterogeneous core types, co-processors, etc are all beneficial design choices and every competing company can take advantage of them? Because Intel is now competing with TSMC? Because AMD and Intel might lose the monopoly on x86 and need to compete? Because Rosetta 2 and universal binaries pave the way for Apple to invest and eventually transition to RISC-5 or …?
Do you not see any of these points as great? If not, why not? I’ll use your reasons to try to come up with better examples.
I guess that spareparts are harder to get and third party repairing will be almost non existent. It'll also make new competitors with good concepts harder to come into industry (steam deck, framework laptop).
Imagine if every car vendor (bmw, mercedes, toyota, etc) start making a very specific tire that can only be used by their own model.
No, not in any useful form it can’t.
And any architectural changes could require another lengthy reverse engineering process rendering these devices unbootable with non-Apple OSes until then.
I would not be surprised if Apple completely closes off the Mac ARM64 platform for “security” in the next few years. The option to boot third-party OSes seems like a short-term gimme to keep the pitchforks and torches at bay.
I make this distinction because this is precisely the issue being discussed.
> No, not in any useful form it can’t.
Yes, it can? Ex. https://www.tomshardware.com/news/apple-m1-debian-linux - you're welcome to point out that drivers for the rest of the system are a WIP, but the CPU is fine and the rest is coming along.
Progress is being made by REs such as marcan and others but it’s not useful, yet. And I speculate that by the time it is solid, the M1X/M2 machines will be out and a bunch of additional REing will be done.
This talk is about the PS4, similar in concept https://youtube.com/watch?v=QMiubC6LdTA
And yet you can't run alternate OSes on iPhones and iPads because of Apple's efforts to make sure that you can't.
We're relying on the goodwill of companies that have all the financial incentives in the world to lock users out of the hardware they own, and those are the same companies that already lock users out of their mobile devices.
Can it run native Windows?
Alternate OSes can't access all hardware functions.
We already have that problem with Linux support for battery life and hibernate.
It doesn't work in the vast majority of laptops, while with Windows it does.
It also happens with Smartphones, to the point that alternate OSes for Smartphones have trouble doing the most basic functions, like making calls and using GPS.
Just because it can be installed, it doesn't mean that everything will magically work.
> It doesn't work in the vast majority of laptops, while with Windows it does.
That's kind of my point. The status quo is already not ideal, this doesn't seem necessarily worse than the status quo, as long as Apple and Google aren't overly restrictive in preventing alternate OSes (which of course is a big if).
Server hardware had (still has somewhere): SPARC from Sun, PowerPC from IBM, HPPA from HP, etc... See for example list of supported architectures for Debian4: https://www.debian.org/releases/etch/hppa/ch02s01.html.en
But it feels like amd64 is winning today. Don't you think that eventually one of these architectures you're talking about (Google's, Apple's, Samsung's, CCP's) will win over others, one way or another?
x86_64 didn’t win on technical superiority alone.
it's called "ARMada" for a reason
In a world where all device manufacturers design (or even fab) their own CPUs and make their own software/cloud services (we're already there in some ways, sadly), any newcomer would have to start with transistors and work their way up to a long-term cloud ecosystem. That probably won't happen any time soon, standalone chip designers will continue to be competitive or at least good enough, but you can see how proprietary chips can actually make competition harder in some ways.
All of them will be 100% compatible with SaaS over the internet offerings, no end user will notice.
Once you are deep in a vendor lock-in, you are trapped to use whatever he allows you to.
Isn't it already like this? We already have to make our apps in Obj C / Swift for iOS and Java/Kotlin for Android. You can use C/C++ libraries but you typically need to recompile them anyways. So if iOS or Android switch to different CPU architectures what's the problem? We will have to change our build processes, but the platforms are already fragmented.
Of all the things he said, I found that simple idea to be the most surprising. The internet is already being dominated by a handful of cloud providers, few domain registers and select social media.
It is damn difficult to go against the tide and even though we are falling off a cliff.
Interestingly:
> As of 2017, Google was attempting to eliminate proprietary firmware from its servers and found that the ME was a hurdle to that.
Source: https://en.wikipedia.org/wiki/Intel_Management_Engine
If Google is building their own SoC they could move the EC on-chip. I don't know if it's worth the development effort.
As much as google gets hate, pixel phone and chromebooks are made to be hacked, when contrasted with Apple.
http://www.loper-os.org/?p=2433
It's connected to the auxiliary lines on one of the USB-C connectors. Tickle it the right way and it will happily overwrite the boot firmware -- so long as the image you give it is signed by Google. It will do this without any intrusion into the chassis. Very convenient for, say, airport security inspectors, who would arouse suspicion if they took the time to open the case. Plug in the magic USB dongle, press the power button, the deed is done.
There were a precious few aarch64 chromebook models without it, but they've all been discontinued.
I almost uniformly support diversity: companies are better with many different types of people (and more fun to work at), different CPUs and other components with differing designs and supply chains, every country having their own culture and local economies, avoiding social media and connect directly via email and texts, less power in a few huge corporations, etc.
re: Chromebook's: I always have one for casual web surfing especially when clicking links on places like Reddit that might take me to a infectious part of the web using a mislabelled URI.
Chromebooks with an Intel chip that have a cooling system with a fan can use much more powerful chips and seem to be fine. Typing this from an HP c1030 which I've never seen slow down.
I know you could have gotten a lot of these benefits already by maintaining a bespoke dev server, but having a common set up for a team with prebuilds makes a big difference. Gitpod’s recent open sourcing of their VS Code fork, along with the growth of the open-vsx extension marketplace, seems like it will really open things up further.
But the key thing was outsourcing their core technology bit by bit. And that started in 2007. By 2012, a lot of Nokia factories no longer existed and production had moved to China and they had changed software strategy so often that it all got very confusing.
In the space of about five years they went from being the largest smart phone manufacturer to selling out to MS who then unceremoniously pulled the plug on the whole thing because there was very little left in terms of tech and skills worth salvaging. Windows Phone was a dud. Nokia as an Android phone manufacturer did not make a whole lot of sense (they actually launched one Android phone just before MS took ownership). Around the same time they also launched what could have been a Meego flagship device but was effectively a dead end when they killed off the entire team before putting that in the market.
Already in 2010, Apple felt they needed to do the exact opposite and have more control over their hardware. Fast forward 11 years and now world + dog is doing their own chips. And Apple of course dominates the phone market with a strategy of basically doing everything in house. Just like Nokia used to do.
Typing this from a Nokia phone.
I think the real reasoning is to cut costs once a company achieves domination. If there is no political will in the executive ranks to continue spending on R&D, the executives will choose to cut costs today, coast for a few years and cash out on their “increased” performance.
It is one of the reasons I like dapple, since as far as I can tell, Microsoft is just planning on collecting rent from Office, and Google execs like to toy around with a project for their own prestige and then kill it once a new boss comes around who cannot claim the initiative as their own.
More competition and a more diverse product landscape usually ends up benefitting the customers.
Intel definitely has the talent and they’re in USA.
They just haven’t had the right management for a while. Maybe now they do.
Full disclosure—I own Intel stock.
I expect these ARM chips will be pretty conventional - because the other thing Chromebooks do is run Android apps.
I do worry about the google part though. They clearly think in terms of open technically but not really via gigantic catch. See android being open yet huawei being utterly screwed.
What's more, as far as I know, it's not their expertise area, they outsource this kind of work (architecture and cpu design), so if they had to develop their own architecture or CPU, relying on work from other companies with this expertise would probably lead to better results (for cheaper), for instance for a very specialized kind of work that would be more efficient with a specialized architecture.
And yes, that would probably be very time-consuming and cost a lost of money and that alone is probably a big reason for not doing it, especially if there is no clear need for it.
They probably would if they both had the expertise to do so and they were in a situation where developing a new architecture and CPU from scratch would allow them to save a lot of money.
For general workloads, they are probably just better off using a widespread architecture to leverage existing tools and ecosystems.
And maybe they actually do for internal stuff without us knowing, but that does not seem very likely.
Note that Apple is slowly replacing your chips with M1. MS has similar machines with Snapdragrons. Amazon is using some non-x86 on its cloud. And now Google.
Please, consider that getting rid of IME may gain some goodwill and attractiveness to your platform.
And they don't really have suffixes in x86.
The fact that it has a to have a big streaming cache just for the decoding puts it at a loss. Intel have only just gone 6 wide.
Is it the end of the world? No. Do I want a RISC machine? Yes
It doesn't have to have a L0 cache; a lot of designs don't.
And the decoder is wider than it seems. x86 instructions have more uOPs mainly from RMW instructions that would be three separate instructions in RISC. It'll be fun to compare Zen 4 (even at Ultrabook TDP) and M1 apples to apples once everyone has access to 5nm.
The designs M1 is competing with all have L0s, surely? I guess it could be masked off for a low power design but I would've thought not.
Either way, it's old and ugly, I don't miss it at all even if ARM and friends peripheral story probably isn't as good.
The short decoders don't typically have issues with mod/rm memory destination fields. It's a little confusing because there's typically at least two uOP formats inside the cores. The decoders generally discussed spit out uOPS that still look fairly x86 in the semantics they encode (2 address, can be RMW, etc.) just wide, but fixed width. But by the time they've made their way to the functional units they've been cracked into more uOPs so AGU, LD, ALU, ST can all go to different ports that can handle that work.
> The designs M1 is competing with all have L0s, surely? I guess it could be masked off for a low power design but I would've thought not.
Most designs I've seen they're actually most important as a power saving feature. They shine well in microbenchmarking for perf, but not as much for general code. The real win is the clock gating all the i fetch and decode, most of which gets shared with RISC too (think I-TLBs, and Ifetch before decode).
The observation that ARM also uses a decoder is not a useful one.
And hope that someday you get the gru-kevin u-boot branch working :)
With a new slow custom chip, Google will kill Chromebooks the way they killed Google Pay and Wave and Loon and all the rest.
But...they didn't kill Google Pay.
https://arstechnica.com/gadgets/2021/10/google-pays-disastro...
a case of reverse imperialism if you ask me.
If custom ARM chips make x86 irrelevant and are designed 100% in-house then we could have a situation where the only option is running that locked-down/walled OS or using an old, outdated hardware. Sure you can run our own code in the cloud but that's still under the eyes of the cloud provider.
Luckily this probably won't happen. Computation as a product is a large enough market that there should be sufficient demand for an open platform. Even if the market didn't provide this demand, a large number governments would raise concern & intervene.
And how would the boot unlock get communicated back to these chromebooks?
My warning is, don't expect an Ebay chromebook that is coming off of a big school contract to be able to boot Linux. It may be locked, and will only run Chrome.
It must be done remotely via GSuite, the stock Google firmware uses the serial number to check whether the device is enterprise-managed. And yes, unenrolling a device is very much a possibility.
The PC only happened because Compaq managed to screw IBM with their clean room reverse engineering.
I just hope we don’t see problems with portability like it’s the 70’s again.
Samsung with it's bespoke ARM chips and Apple with its chips make better, more capable, devices than Google can possibly make with off the shelf parts. That combined with having to pay the third party margin on the chips and you don't achieve leadership. But the challenge is that "organically" developing a core competency in semiconductor design is unlikely to succeed. Samsung was a chip company to begin with and Apple bought PA Semi for the expertise.
Not that buying a company would necessarily help, after all their track record there is spotty at best.
There is a long history of tech companies copying competitors and taking over markets by executing better
Somewhat more seriously, I'm wondering if there has been a single adjacent market that Google has tried to enter and executed better than any existing player, much less the leader in the space.
Maybe they think we're at the stage where ML can significantly help with cpu design?