[HN Gopher] Google developing own CPUs for Chromebook laptops
___________________________________________________________________
Google developing own CPUs for Chromebook laptops
Author : jonbaer
Score : 203 points
Date : 2021-10-02 18:38 UTC (4 hours ago)
(HTM) web link (asia.nikkei.com)
(TXT) w3m dump (asia.nikkei.com)
| z3t4 wrote:
| I wonder if we will get more hardware optimizations for
| JavaScript
| amelius wrote:
| But will it contain a Google Management Engine?
|
| 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
| monocasa wrote:
| Pretty much any SoC powerful enough to use for this
| necessitates having an ME style core. The only question is if
| end users can change the code out.
| wmf wrote:
| Chromebooks (and virtually all laptops) have an embedded
| controller (EC) but fortunately the source is open:
| https://chromium.googlesource.com/chromiumos/platform/ec/+/H...
|
| 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.
| theshadowknows wrote:
| I know nothing about how processors work so tell me if this even
| makes sense. But other than the time and money is there any
| reason that say a Google can't create their 100% from scratch CPU
| and instruction set? Same for apple and all the others?
| PostThisTooFast wrote:
| Google better hope that it sucks less at this than it does at UI
| and branding.
| [deleted]
| sjg007 wrote:
| I have found the arm chrome books to be way better than the intel
| ones.
| amm wrote:
| CPU market fragmentation in the pro-sumer space is not
| necessarily a bad thing and might pave the way for RISC-V
| adoption in the coming years.
|
| More competition and a more diverse product landscape usually
| ends up benefitting the customers.
| bserge wrote:
| More fragmentation and more control over their own hardware.
| Having general purpose PCs that you fully own was great while it
| lasted.
| bdcravens wrote:
| For many, their primary computing device has fully specialized
| for years.
| 1-6 wrote:
| Fragmentation isn't good. Open standards---not open standards
| from one company---is best. The shiny new computer will hold
| the title 'fastest in its class' initially but its longevity
| will be at the mercy of the company building it. Linux will get
| harder and harder to port over without jailbreaking.
| zozbot234 wrote:
| You can get full control over any Chromebook by opening the
| device up and removing a single firmware-write-protect screw.
| Try that with an iOS device. It's the difference between a
| useless toy and something you can actually customize to fit
| your needs.
| Dylan16807 wrote:
| Do newer chromebooks still _actively ask_ the user to wipe
| them every boot once unlocked? Depending on vendor, maybe?
| zozbot234 wrote:
| They do that when you enable the stock "developer mode".
| Removing the firmware write protect allows you to override
| that behavior.
| KingMachiavelli wrote:
| That's only true as long as Google wants it to be true.
| notriddle wrote:
| Unless you have a fab in your closet, your ability to get
| customizable computers will always be contingent on someone
| else making them for you.
| sitkack wrote:
| That is not true, there are plenty of boot locked Chromebooks
| on ebay. If the org didn't unlock them when they surplussed
| them, they will never run Linux.
| zozbot234 wrote:
| They can be "deprovisioned" afterwards by the enterprise
| that was managing them, and these blocks will be removed.
| Just wait until they get around to doing it, they will
| because keeping devices enrolled costs them money.
| rubyn00bie wrote:
| This is the beginning of the commoditization of computer
| processing. Right now, the only thing that gives you a lead is
| what you can have fabricated... Apple and AMD using TSMCs fabs
| have proven this to be extremely true taking the top CPU spots
| from Intel the past ~3 years. While we will probably see a small
| spike in "custom dogshit CPUs" I don't think it will be long
| lived (maybe ~5 years that suck starting around the end of this
| decade). It certainly won't be worse than the current variety of
| processors in phones or random other small electronics. Not to
| mention there's little incentive to use hardware that has poor
| software support. Eventually (~25 years), the fabs will go from
| billions to millions to maybe a few tens of thousands of dollars.
| Purchasing a CPU will (eventually in like 40-50 years) simply be
| deciding how much power, heat, and physical space you have to
| budget...
|
| 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.
| baybal2 wrote:
| > Apple and AMD using TSMCs fabs have proven this to be
| extremely true taking the top CPU spots from Intel the past ~3
| years.
|
| Absolutely not. The proved you can beat intel at _lower_
| transistor counts, at more or less similar frequencies.
| narrator wrote:
| Please Google make a fab. You guys have smart enough people to
| figure out the chemistry and physics, and the world definitely
| needs more 5nm fabs.
| dinvlad wrote:
| I went through multiple iterations of Chromebooks as a developer.
| I really wanted to love them, but they're just not powerful
| enough for it. Even opening multiple tabs slowed down the
| Pixelbook, for example. I think at this point, unless Google
| indeed drastically revamps the architecture to make it much more
| powerful for the buck, it's a dead product in this category.
| Education seems like the only market where it shines.
| krrrh wrote:
| I've never really considered a chromebook for development, and
| I'm almost certainly going to order a new MacBook pro next
| month, but we've been using Gitpod lately and it (and
| presumably codespaces) seem like they are really freeing
| developers from needing beefy machines.
|
| 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.
| zz865 wrote:
| They're not powerful enough to do all the work all the time but
| if you have a lot of web based work they're definitely perfect
| for a lightweight terminal.
| quickthrower2 wrote:
| Web can be the most demanding of applications in terms of
| memory and cpu (for what you get)
| dinvlad wrote:
| "Lightweight on the go" I would say, especially if editing
| something remotely with good connectivity - sure, and might
| be a sweet spot. Though it's less convenient than having a
| general-purpose machine.. I've worked from coffee shops etc.,
| and found it to be much more versatile to bring an extra
| pound of a Macbook instead, even for SaaS work with a remote
| IDE.
| stickfigure wrote:
| I don't think the Chromebook was ever aimed at developers. It's
| the console you use for your marketing and customer support
| team.
| dinvlad wrote:
| Not exactly - they've marketed it to developers with Crostini
| for a number of years now. But it's just not there,
| unfortunately.
| wffurr wrote:
| Chromebooks with fans are substantially faster than the
| Pixelbook. Pixelbook was a fanless low power CPU design, and
| the Intel low power CPUs just aren't quite up to powering video
| calls and a bunch of heavy browser apps.
|
| 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.
| hn_throwaway_99 wrote:
| I hope so. I had a Google Pixelbook, and with the Linux container
| support (aka Crostini) it was an ideal developer laptop,
| especially as the Linux support improved over time. I was worried
| they were going to drop it as the Pixel Slate is much more of a
| consumer device.
|
| Would love to see another Pixelbook with great performance and
| stability for Linux apps.
| pjmlp wrote:
| I wouldn't be ever paying for space constrained Chromebooks,
| when I can get proper Linux laptop around 300 euros, with GPUs
| not stuck in GL ES 3.0 hardware level and plenty of SSD space.
| Andrex wrote:
| Links would be appreciated, I'm in the market.
| pjmlp wrote:
| I just got a Asus netbook from Amazon Germany without OS
| back in 2009, but with explicit Ubuntu support, the 1215B.
|
| 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.
| youngtaff wrote:
| I'd be quite happy with a ChromeOS just want to be able to
| install it on my own hardware rather than the over priced
| stuff that's available ATM
| hn_throwaway_99 wrote:
| To each their own. If I were solely looking for "a Linux
| laptop", correct, I'd get something else. But I find the
| combination of Crostini and ChromeOS ideal for me:
|
| 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.
| Andrew_nenakhov wrote:
| If such efforts are not curbstomped early, we'll end up with
| fully closed computing devices architecture, belonging to
| different vendors who provide whole vertical from bare metal to
| OS. There will be Google's processors/OS/software, Apple's,
| Samsung's, plus some shit CCP will come up with, like, TikToks,
| and all of them will be mutually incompatible, with own
| programming languages and data formats. The future looks bleak.
| capitalsigma wrote:
| This is literally what competition looks like, the opposite of
| a monopoly. Isn't that what we all want?
| dvdkon wrote:
| Yes, it's certainly better than a Qualcomm monoculture would
| be. But ideally competition on CPUs would happen in the CPU
| market, instead of in the target product market with lots of
| vertical integration.
|
| 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.
| user-the-name wrote:
| This is what computing used to be. It wasn't bleak, and I would
| say it was a lot more interesting. Most of the retro computers
| that people remember with great fondness were like this.
| [deleted]
| wmf wrote:
| Chrombooks are pretty open, although totally non-standard.
| PostThisTooFast wrote:
| A bunch of them don't even have Delete keys, which is fucking
| stupid.
| spankalee wrote:
| What's non-standard about them, and compared to what exactly?
| wmf wrote:
| They don't use UEFI/ACPI like every other PC.
| haberman wrote:
| The people reverse engineering the M1 found that it uses an
| architecture that will likely make it easier (not harder) for
| Linux to support new generations of Apple hardware as it is
| released: https://news.ycombinator.com/item?id=28183176
| heavyset_go wrote:
| If you're developer, it's guaranteed that these companies will
| attempt to capture 15% to 30% of all of your revenue on these
| platforms, too. They already do it with phones and tablets.
| jb1991 wrote:
| How bad is that, though? The success and impressive
| performance, battery life, temperature of the Apple M1 suggests
| that this kind of integration can have outstanding results. So
| there are tradeoffs, at least.
| Andrew_nenakhov wrote:
| What good are performance and battery life if you don't get
| to decide which apps you are permitted to run on this device?
|
| 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...
| jb1991 wrote:
| Assuming we are talking about the desktop, you can run
| whatever you'd like. The App Store is just one avenue for
| software distribution on the Mac. The situation is of
| course different on iOS.
| sneak wrote:
| > _Assuming we are talking about the desktop, you can run
| whatever you'd like._
|
| 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.
| jb1991 wrote:
| Sorry, I thought the question was a critique of macOS,
| not the Pixelbook, and I offered a clarification that
| macOS is actually pretty open and you can run whatever
| app you like, in most cases.
| sneak wrote:
| For the moment. You also can't run any of the iOS apps
| (an advertised feature of macOS on M1) if you disable
| SIP, so this isn't really a true statement logically
| speaking.
| ajconway wrote:
| > What good are performance and battery life
|
| 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.
| Andrew_nenakhov wrote:
| > For the average consumer -- everything.
|
| > 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.
| Jensson wrote:
| > impressive performance, battery life, temperature of the
| Apple M1
|
| 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.
| beckman466 wrote:
| Apple M1 didn't come out of nowhere, they learned from
| everything that came before. Your comment sort of implies
| that the innovations came solely from being developed behind
| closed doors (or in some kind of vacuum), which denies credit
| to workers who made the thousands of incremental
| breakthroughs that landed in the commons and which has helped
| us to arrive in the place we are now.
| ketzo wrote:
| No, GP made a pretty specific point: that vertical
| integration can clearly provide some serious benefits in
| the realm of computer hardware.
|
| 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.
| 5faulker wrote:
| Maybe we should start with universal cable format first. Seems
| easier to implement.
| zucker42 wrote:
| Is it that much of a problem as long as alternate OSes can be
| installed by the user? For example, the M1 chip can run Linux.
| I don't see how Apple and Google producing their own chips is
| much different as a consumer than the Windows/x86 monoculture
| that's existed for a long time.
| retrac wrote:
| The M1 can run Linux after an extensive reverse-engineering
| effort. And Apple didn't take particular active measures to
| prevent running your own OS on it; they just didn't offer any
| help. Many Android device manufacturers actively try to
| prevent that. Apple actively tries to prevent it on iOS
| devices. Some early Chromebooks actively tried to prevent it,
| too. (Though not Google's own flagship developer devices.)
| runjake wrote:
| > For example, the M1 chip can run Linux.
|
| 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.
| yjftsjthsd-h wrote:
| >> For example, the M1 chip can run Linux.
|
| > 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.
| runjake wrote:
| Try it on a physical Mac Mini machine and tell me it's
| useful.
|
| 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.
| ducktective wrote:
| In other news, Nvidia's support for Linux is "coming
| along(tm)" and Lenovo says drivers for fingerprint auth
| for thinkpads is just-around-the-corner(r)
| zucker42 wrote:
| Nvidia actively prevents open source support through
| firmware signing.
| drekipus wrote:
| If I remember correctly that's similar what the PS3 did,
| but that's a different issue and comes with cool
| discussions
|
| This talk is about the PS4, similar in concept
| https://youtube.com/watch?v=QMiubC6LdTA
| easton wrote:
| There was too much engineering work put in to make the M1
| be still secure by default while allowing you to run other
| OSes. If Apple wanted to make it so you could only run
| signed kernels then the best time to make that breaking
| change would've been when the first Apple Silicon macs were
| released, not three or four years down the road when
| suddenly they say "throw away that bespoke firmware and all
| that special security work we did, just load the iPhone
| bits on there".
| oblio wrote:
| > For example, the M1 chip can run Linux.
|
| Can it run native Windows?
| heavyset_go wrote:
| > _Is it that much of a problem as long as alternate OSes can
| be installed by the user? For example, the M1 chip can run
| Linux._
|
| 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.
| kevin_thibedeau wrote:
| DEC, Sun, IBM, and many others did this. The world still
| survived.
| kwertyoowiyop wrote:
| And for the most part, _they_ did not.
| oblio wrote:
| The new corps learned from the old corps. I'm not sure
| <<we>>'re going to survive them.
| Lex-2008 wrote:
| > all of them will be mutually incompatible, with own
| programming languages and data formats. The future looks bleak.
|
| 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?
| mattnewton wrote:
| Only if they have an incentive to sell it as a commodity.
|
| x86_64 didn't win on technical superiority alone.
| VLM wrote:
| > and all of them will be mutually incompatible, with own
| programming languages and data formats
|
| All of them will be 100% compatible with SaaS over the internet
| offerings, no end user will notice.
| oblio wrote:
| Yeah? How are progressive web apps working on iOS?
| Andrew_nenakhov wrote:
| Unless the internet will be fractured into 'google's net',
| 'Apple space', 'TikTok realm', 'Microsoft fief'. If you think
| that this will _never_ _ever_ happen, think again. Not so
| long ago some SaaS internet offerings worked only on one
| operating system and on one infamous browser.
|
| Once you are deep in a vendor lock-in, you are trapped to use
| whatever he allows you to.
| Popegaf wrote:
| Yeah, really great news: more vertical integration for higher
| walls around those gardens. And, as usual, the majority of
| hackernews is celebrating this as a win and will happily shovel
| more money into the pockets of tax evasion and anti-competitions
| champions, privacy invaders, and polluters.
| hyproxia wrote:
| Honestly, some people legit scare me when they're talking about
| ARM/RISC-V. They usually have very little relevant
| knowledge/experience in the field (some don't even know what an
| ISA really is) yet worship these architectures like they're the
| second coming of Jesus. It really is easy to brainwash people
| en-masse.
| ChuckMcM wrote:
| Following what your competitor is doing has not historically been
| a winning strategy in tech, I hope it works out for Google.
|
| 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.
| jsnell wrote:
| This isn't coming out of nowhere, they have been doing custom
| ASICs for a while already. The article mentions TPUs as an
| example. A more recent example are YouTube's in-house
| transcoding chips:
| https://news.ycombinator.com/item?id=27034627
| Rd6n6 wrote:
| > Following what your competitor is doing has not historically
| been a winning strategy in tech
|
| There is a long history of tech companies copying competitors
| and taking over markets by executing better
| ChuckMcM wrote:
| You had me until you said "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.
| jsnell wrote:
| But other than browsers, mobile phone operating systems,
| ads, email, search, collaboration software, machine
| translation systems, mapping, ML hardware, internet video,
| identity providing, web analytics, autonomous driving, and
| virtual assistants, what products have the Romans ever
| executed well on?
| dukeofdoom wrote:
| Schools are giving out Chromebooks to teachers to live stream
| classes. It integrates with google classroom well. However its
| terribly slow if you have more than few tabs open.
| b20000 wrote:
| so is google docs working yet?
| mark_l_watson wrote:
| Cool, the more options the better.
|
| 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.
| swiley wrote:
| I doubt this will be the helpful kind of diversity.
| nly wrote:
| But will they all be fabbed by TSMC?
| mark_l_watson wrote:
| true! I would like to see more independent fabs in the USA
| and Europe, but not sure when that can happen.
| beckman466 wrote:
| what's are the most prominent bottlenecks with lithography?
| georgyo wrote:
| Many people are seeing all these different vendor specific CPUs
| as a win. I'm a bit more skeptical, but perhaps that it
| unwarranted.
|
| 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.
| mhh__ wrote:
| Apple has already done this to an extent. M1 has undocumented
| instructions and a semi-closed toolchain (Assuming they have
| some, M1 tuning models for LLVM and GCC are nowhere to be seen
| afaik)
| mancerayder wrote:
| I'm asking out of naivete here -- how were they (kernel
| maintainers) able to get the Linux kernel to support M1 with
| undocumented instructions?
| [deleted]
| kevingadd wrote:
| The undocumented instructions aren't required in order to
| use the hardware
| R0b0t1 wrote:
| Don't use them. The instructions necessary to run Linux are
| likely inherited from the normal ARM set.
| ducktective wrote:
| My guess: if the situation is similar to Windows laptops,
| they just use a subset of OEM features and provide a sub-
| par experience (like lack of battery usage optimizations,
| flaky suspend/hibernate, second-tier graphics support, etc)
|
| 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.
| frabert wrote:
| A kernel doesn't need to use all the instructions a CPU
| offers -- only the ones it needs.
| ithkuil wrote:
| If the extra instructions also operate in extra state
| (e.g. extra registers) a kernel needs to know about their
| existence so it can correctly save and restore state on
| context switches
| my123 wrote:
| Not necessarily/really, the custom extensions still need
| to be enabled by the kernel before they can be used.
|
| As such, it isn't actually an issue.
| Someone wrote:
| It doesn't need to use them, but it must be aware of
| them, insofar as they may introduce security problems.
|
| 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.
| surajrmal wrote:
| What dma channels doesn't require mapping registers into
| the user space process to work? There aren't usually
| magic instructions you have to opt into disabling as far
| as I know.
| heavyset_go wrote:
| I'm assuming they aren't using them or they've reverse
| engineered the ones they need to use.
| mhh__ wrote:
| The instructions are (all?) for acceleration _I think_.
| ant6n wrote:
| Apple M1 also has that x86 emulation mode where memory
| accesses have the same ordering semantics as on x86. It's
| probably one of the main things giving Rosetta almost 1:1
| performance with x86.
|
| https://mobile.twitter.com/ErrataRob/status/1331735383193903.
| ..
| my123 wrote:
| That's a single ACTLR bit present in the publicly released
| XNU kernel source code.
| zamadatix wrote:
| TSO support at the hardware level is a cool feature but
| it's a bit oversold here. Most emulated x86 code doesn't
| require it and usually not at every memory instruction when
| it does. For instance the default settings in Window's
| translation implementation do not do anything to guarantee
| TSO.
|
| 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.
| ant6n wrote:
| Breaking memory ordering will breaks software - if a
| program requires it (which is already hard to know), how
| would you know which memory is accessed by multiple
| threads?
| my123 wrote:
| Heuristics are used. For example, memory accesses
| relative to the stack pointer will be assumed to be
| thread-local, as the stack isn't shared between threads.
| And that's just one of the tricks in the toolbox. :-)
|
| 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.
| zamadatix wrote:
| It's not just a question of "is this memory accessed by
| multiple threads" and call it a day for full TSO support
| being mandated it's a question of "is the way this memory
| is accessed by multiple threads actually dependent on
| memory barriers for accuracy and if so how tight do those
| memory barriers need to be". For most apps the answer is
| actually "it doesn't matter at all". For the ones it does
| matter heuristics and loose barriers are usually good
| enough. Only in the worst case scenario that strict
| barriers are needed does the performance impact show up
| and even then it's still not the end of the world in
| terms of emulation performance.
|
| 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...
| Someone wrote:
| Nitpick: relative speed differences do not add up; they
| multiply. A speed of 70 is 40% faster than a speed of 50,
| and a speed of 100 is 42.8571...% faster than a speed of
| 70 (corrected from 50. Thanks, mkl!). Conversely, a speed
| of 70 is 30% slower than a speed of 100, and a speed of
| 50 is 28.57142...% slower than one of 70.
|
| => when comparing speed, 70% is about exactly halfway
| between 50% and 100% (the midpoint being 100%/[?]2 [?]
| 70.7%)
| mkl wrote:
| > a speed of 100 is 42.8571...% faster than a speed of 50
|
| I think you mean either "100% faster" or "faster than a
| speed of 70" there.
| ithkuil wrote:
| Are the tuning models in opensource toolchains for Intel CPUs
| been released by Intel or figured out over time by opensource
| developers?
| mhh__ wrote:
| Intel publish a very thick optimization manual, which is a
| good help.
|
| 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.
| kolbusa wrote:
| Intel contributes optimizations to gcc and llvm.
| jagger27 wrote:
| Apple also contributes plenty to LLVM, more than Intel
| actually, naively based on commit counts of @apple.com
| and @intel.com git committer email addresses. This isn't
| very surprising given that Chris Lattner worked at Apple
| for over a decade.
| ithkuil wrote:
| They do now; I think I remember the time when they
| didn't.
| beckman466 wrote:
| > Many people are seeing all these different vendor specific
| CPUs as a win. I'm a bit more skeptical, but perhaps that it
| unwarranted.
|
| 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).
| lrem wrote:
| Do they even have to betray anything? It's not like Apple has
| been using interoperability as a selling point...
| reginold wrote:
| Undocumented features and functionality become the norm
| xyzzy_plugh wrote:
| There's a lot of ignorance in some of the threads here, but the
| reality is proliferation of "custom" (but under license) ARM
| chips _is the end goal of ARM_. That's their whole business
| model. They (Arm, the company) don't manufacture _anything_.
| They just design and license their designs.
|
| 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.
| laurent92 wrote:
| This is an excellent example of positive use of IP law, and
| why removing copyright and patent would harm some legitimate
| business models.
| fragmede wrote:
| Theres survivor bias - the success of ARM ignores the
| relative failure of other alternative instruction sets.
| SPARC, Itanic, MIPS, the road to today is littered with
| instruction sets that didn't make it in the same way ARM has.
|
| 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.
| caslon wrote:
| The comment above is talking about ARM's business model,
| which Intel on Itanic _definitely_ didn 't have, Sun didn't
| have for SPARC (they later freed it, after it was no longer
| commercially relevant), and MIPS as a company didn't
| follow, either.
| fortran77 wrote:
| > 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.
|
| 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
| zanethomas wrote:
| ... and
|
| The proprietary cpus will only run software obtained from the
| corresponding app store.
|
| You can take that to the bank.
| marcellus23 wrote:
| Yeah, this won't be happening.
| oblio wrote:
| Why?
| sneak wrote:
| Yeah. This is more about full stack DRM to provide
| rentseeking opportunities than Intel's fat (but historically
| tolerable) margins.
| staticassertion wrote:
| Is this worse than the current state of things? intel has its
| own special extensions to its chips, right? They all do.
| ohgodplsno wrote:
| All the x86 extensions are freely implementable by any
| constructor. There's some stuff like SSE4a which is not
| available on Intel processors, and others that Intel has
| implemented and AMD chose not to. But they are published as
| extensions and part of the standard.
| amscanne wrote:
| I believe you misunderstood the comment. Intel also has
| _undocumented_ extensions and functionality, that requires
| reverse engineering. It's exactly the same as the vendor
| specific cases here. You were thinking of _documented_ and
| well-specified vendor-specific extensions, but I don't
| think that's the main concern.
| ant6n wrote:
| You mean implementable by AMD, the other x86 constructor.
| ohgodplsno wrote:
| I don't see you complaining about ASML being the only way
| of getting photolithography machines, or TSMC being
| basically the only constructor at scale.
|
| 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.
| ant6n wrote:
| I'm not complaining about anything, just saying there are
| two companies that have licenses to make x861, so it's
| not true that anybody could implement a cpu with sse4
| extensions.
|
| 1Not sure what happened to that x86 license that Cyrix
| had.
| forty wrote:
| Via technology is making x86 CPUs using Cyrix's licence
| (they purchased Cyrix 20 years ago)
| Someone wrote:
| https://en.wikipedia.org/wiki/X86-64#Licensing:
|
| _"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-appr
| oaching-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...)
| mertd wrote:
| OP's point is exclusivity. Intel chips are not exclusive to
| Intel branded end consumer computers.
| oefrha wrote:
| These alarmist comments seem to be comically oblivious of much
| of computing history. If you have something open and better, it
| will prevail over closed products; if you have something open
| and worse, you need to work on making it open and better,
| screaming "but they're closed" doesn't help.
| userbinator wrote:
| _If you have something open and better, it will prevail over
| closed products_
|
| 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.
| Karrot_Kream wrote:
| > The problem is that "better" is being defined by the
| companies spreading the marketing propaganda about their
| products
|
| 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.)
| BeefWellington wrote:
| I'm not sure that in computing history there's ever been the
| situation we have now of a software vendor owning so much of
| the market(s) that they can realistically afford to make this
| kind of move.
|
| 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.
| simonh wrote:
| This is the way most of the computing market has worked
| most of the time. Mainframes and minis were this way, then
| almost all the workstation vendors had their own CPU
| architecture and OS (often a flavour of Unix). The only
| real exception, and I admit it is a huge one, in Wintel but
| outside that in house hardware/software development in
| tandem has been the norm.
|
| 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.
| [deleted]
| foobiekr wrote:
| In some tech sectors, the double margin problem is a very real
| issue. Merchant silicon vendors have a margin they need to hit,
| and the vendors have a gross margin they need to hit, and so
| on. This is especially an issue in HPC and networking.
| qqtt wrote:
| > 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 F in FAANG - Facebook - has consumer products (notably, the
| Oculus VR headset).
|
| Also Netflix spun out their consumer product into another
| company (Roku).
| todd3834 wrote:
| This means more competition right? I mostly think good will
| come from this for consumers. Things felt like they really
| stalled out for a while with Intel
| Zenst wrote:
| > Many people are seeing all these different vendor specific
| CPUs as a win. I'm a bit more skeptical, but perhaps that it
| unwarranted.
|
| 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.
| my123 wrote:
| The extensions present in the M1 are not used at all by
| Apple's public compilers. From the perspective of a 3rd-party
| macOS developer that doesn't reverse engineer, it's just a
| regular arm64 machine.
|
| 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.
| Zenst wrote:
| Very true and easy to blur the lines of thought between SOC
| and CPU these days upon ARM. Thank you for the poignant
| reminder.
| antris wrote:
| >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.
|
| 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.
| Avi-D-coder wrote:
| Your right, but all of this will drive WASM adoption. I'm fine
| with papering over incompatibility as long as the costs
| continue to go down.
| junon wrote:
| WASM adoption is not something everyone agrees is a great
| thing in the context of physical CPUs.
| astlouis44 wrote:
| 100% this. Cross-platform binaries that "just work"
| everywhere in a hardware agnostic manner is going to be huge.
|
| 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.
| kcb wrote:
| They should think of a new slogan, maybe "Write once, run
| anywhere". Yea that sounds good.
| carlhjerpe wrote:
| WASM runs on 3 billion devices!
| astlouis44 wrote:
| This x 1000%.
| carlhjerpe wrote:
| It was a joke on the Java installer saying Java runs on 3
| billion devices for ages, not sure if you got it or not.
| devwastaken wrote:
| It won't, and shouldn't. Wasm meets very few of it's goals,
| and is nowhere near any native speeds under real world
| workloads. Even speedups with SIMD ar hindered, and the
| entire design and implementation of it in the clang/llvm
| compiler is very experimental.
|
| 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.
| astlouis44 wrote:
| Oh this comment is not going to age very well...
| junon wrote:
| > And then we'll end up with a fragmented CPU field driven by
| corporate greed.
|
| So x86, basically.
| klelatti wrote:
| Sorry, this is unwarranted alarmism.
|
| > 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).
| xyzzy_plugh wrote:
| You can definitely get a license that allows you to go hog
| wild and make breaking changes. I _believe_ both Apple and
| Google pay for that.
|
| But it doesn't help anyone to fragment too much.
| klelatti wrote:
| > You can definitely get a license that allows you to go
| hog wild and make breaking changes. I believe both Apple
| and Google pay for that.
|
| Reference?
| my123 wrote:
| There is some minor breakage, like Apple CPUs enforcing
| the VHE feature of ARMv8.1-A to be on, and not supporting
| it being off. But that was like... the sole issue on that
| front.
|
| What you are allowed to do is make extensions with the
| highest tier of arch licenses, you however cannot break
| the ISA.
| klelatti wrote:
| Thanks! Very interesting on VHE.
| [deleted]
| Cyph0n wrote:
| It's called an architectural license. There are a few
| publicly announced license holders, including Apple and
| Qualcomm. Refer to the Arm wiki page for a list.
|
| Probably outdated article on this: https://www.electronic
| sweekly.com/news/business/finance/arm-...
| klelatti wrote:
| > Companies can also obtain an ARM architectural licence
| for designing their own CPU cores using the ARM
| instruction sets. These cores must comply fully with the
| ARM architecture. (Wikipedia)
|
| That's not going 'hog wild'!
| [deleted]
| ape4 wrote:
| Embrace and extend.
| zxcb1 wrote:
| Speaking of which, what is the state of the market for
| switches? Where are the Linux switches and open hardware?
| mastrsushi wrote:
| It's cool to see 25+ yrs of x86 dominance schism off into all
| these Arm variants.
|
| I just hope we don't see problems with portability like it's the
| 70's again.
| uncomputation wrote:
| Another win for ARM! Glad to see the industry finally pivoting to
| RISC. I also wonder if this will integrate with Fuschia?
| 1-more wrote:
| Yah, RISC is good https://www.youtube.com/watch?v=RL9yCWv7NS0
| kevin_thibedeau wrote:
| They pivoted 25 years ago with Pentium Pro.
| mhh__ wrote:
| Still has a phat decoder on the front, consuming power all
| the time + I don't want a disassembler to be a PhD project
| like it is for x86 with all its extensions and prefixes (and
| suffix?)
| monocasa wrote:
| In designs with a L0 uOP cache, they clock gate the decoder
| when just running out of L0. But it's really not that much
| power compared to a giant ROB and bypass network in these
| newer designs.
|
| And they don't really have suffixes in x86.
| mhh__ wrote:
| Hence the question mark, wasn't it 3DNow!
|
| 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
| monocasa wrote:
| 3Dnow used an immediate field for an extended opcode, but
| you still figured out the length of the instruction from
| looking at the first opcode bytes, so it's not really a
| suffix. As far as the decoder was concerned, it was just
| another fixed length, required imm field for the
| execution unit.
|
| 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.
| mhh__ wrote:
| The decoder is wider than it seems but isn't the
| throughput lower for those instructions anyway? i.e.
| different decoders for different instructions
| complexities.
|
| 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.
| [deleted]
| mdasen wrote:
| The question I have around Google's CPU ambitions is what their
| end game is.
|
| 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.
| Jensson wrote:
| Google doesn't need a solid plan to do something, they have
| more money than investment opportunities and since they are so
| "skilled" at shutting down projects it wont be a long term cost
| if it doesn't work out.
| outside1234 wrote:
| "Apple cargo cult"
___________________________________________________________________
(page generated 2021-10-02 23:00 UTC)