I've reached out to a couple Google contacts for an interview, but given the secretive posture the search giant historically has taken around its data center technologies, I don't expect any substantive responses any time soon.
That said, I am ready any time for an interview with anyone who knows more about this topic.
Rick, whether you are Google or Baidu, I can't see any benefit in just doing Vanilla processors that you can get from any ARM or x86 vendor. I'd imagine that you want to integrate CPU, GPU and fabric into a single low latency, highly integrated SoC. I'd imagine that something highly optimized for compute along the lines of what you'd get if you integrate Xeon + nVidea + fabric would be where you want to go to cram in a lot of compute at data center scale with low latency without the overhead of a lot of NICs etc and keep system level power down. Trying squeeze down power and latency around what Intel gives you is probably not going to cut it.
Google should be careful in getting into chip design as its not their forte. They good with software and think twice before getting so selective in hardware business. In hardware business losses are huge.
There's no point in Google making consumer chips. Allwinner and MediaTek can make such chips cheaper than Google. It would be like Google making its own phones -- they're much better off setting the software standard and letting their partners compete against each other to drive the price down.
Besides, why does Google have Android? So that people can get access to mobile advertising, because that's how Google makes money -- selling advertising. And they target their advertising based on what you've searched for. Search is the crown jewels, and it takes a phenomenal amount on computing power and electricity.
So here you have a well-defined highly-parallel problem. Sounds like a perfect application for custom silicon. Instead of interpreting search software on a general-purpose CPU, do it directly in hardware so that data isn't being copied redundantly, which is what really consumes the energy. If custom silicon cuts the Google electric bill in half and doubles the performance of each data center, the silicon pays for itself pretty quickly. And I'm just being conservative with that factor of 2.
If I were with Google, I wouldn't be satisfied with shaking up SDN, or tweaking out some minor mod of a conventional CPU node. I think that's what's so tedious about all the coverage of FB's boring form-factor changes.
Google is in a position where they can look at fundamental changes in programming mode, in ways that conventional suppliers can't. For instance, GPUs have demonstrated that there's a LOT of parallelism out there, in spite of the horrible programming model. Google could be putting dram in-package. They could find a nice uniform way to address large numbers of these nodes (sort of a merged network/dram fabric). If you really go SDN, it doesn't make a lot of sense to stick with the artifacts of traditional ethernet designs (subnets, vlans, ISO layers).
People usually think of this "custom or not to go custom" question as hinging on how much of the conventional architecture can be jettisoned. (ie, if your nodes have nothing but cpu, dram, flash and fabric, you sure don't need 8 ports of SATA or a 6-port USB3 controller. but you probably do want some kind of management coprocessor) But Google should be thinking about more fundamental change, not just subtractions...
Google currently have big power barriers in google glass and robotics which prevents them from building products they want. So some sort of low power custom fit image processor is one possibility. Another possibility is some sort of deep learning(a new hot AI algorithm) algorithm , power optimized , that they can use in glass,robots and even in the data center.
The other possibility is of course accelerators, but do they have enough volume to justify doing stuff in 28nm , considering the fact that they can request custimzation from big suppliers(probably pending on big orders) ? My guess that for accelerators theyre more likely to use easic(via programmable asic) or something similar.
Google has demonstrated its interest in AI by acquiring DeepMind recently. I think any of those options for Google make s sense, as far as what they'd like to do with silicon. But it's still strange that they think this is an area where they need to expand--into silicon--when ARM is coming out right now and offering all of these new options in the datacenter.
There has been speculation about all the internet powerhouses with large data centers developing their own chips. While it is a possibility, it is unlikely. Unlike the mobile market where Apple forged ahead with its own chip design because it was not satisfied with the solutions in the market, there are many options for custom server chips. In fact, this is a key part of AMD's new strategy. I would expect companies like Google and Facebook to partner with those companies that have the necessary IP and expertise to develop silicon solutions that meet their specific requirements. However, it is still in thier best interest to have some expertise in-house to drive the effort.
As far as i can tell , arm(and it's ecosystem) is coming up with generic chips. I see nothing about AI , nothing specific to google glass, and no very customized chips(for example chips customized for memcached processors with a world wide market of less than million units with google maybe needing 100K).
isn't a project. Google will just buy up a company when they are ready to do something real. I agree the most likely possibilities are the areas where they have very specific needs- specialized search engines (where they don't want to give out their algorithms to another company) seems like the best bet...
@rick I don't think you can accelerate mapreduce much, only the operations it does which change by application.
Google uses a variety of algorithms for search. Some of those are machine learning and esp. deep learning algorithms which are quite new and are kinf of breakthrought articial intelligence. For those ASIC's could become cheaper and lower power than GPU's , see . Those same algorithms are also usefull/critical in glass, robots,phones and other places that require AI.
Another option cache server(memcached) acceleration. recently FPGA's shown great promise , and asic could do better.
There are also other search algorithms that could benefit, but accelerating those throught hardware is quite an old idea(and one could use FPGA/GPU) ,so we should ask why now ?
It's those deep learning algrotihms that could take Google into the future with AI and all that comes with it. They already use a broad range of algorithms for their searches. Now with DeepMind and with parallel processing cores, possibly running on silicon that they themselves make, the sky is the limit.
While all the speculation in the posts here are good and thoughtful, I'd bet they are only scratching the surface of what Google is thinking about using their own chips for. Addressing power consumption in their data centers seems like the sort of low-hanging fruit that justifies hiring hardware designers to begin with. And Google has vast troves of their own data on just what processes and applications consume the most power and time today, I'm sure.
But after the largest of those are addressed, what's next? They just noted they need solutions in network latency to handle the surge in connections to IoT, wearables, etc. One way they might attack that is pushing specialized processors closer to their network fringes so the appropriate levels of traffic can be moved where it matters most. Then there's the new robotics initiatives with the likes of Foxconn and aided by acquisitions like Boston Dynamics. This area alone could be quite high-profile and high-margin.
The sky's the limit, it's only the tip of the iceberg, pick whichever cliche you like, they all fit here.
Right, it could serve many masters there. And like others have suggested, Google's group might best be used to set up the architectures (HW,FW,SW) and then partner with providers to implement their visions. Some of those could be proofs of concept, others released as open source, others kept as proprietary though I think the last segment would be small. The more Google can get their ideas used by the world (thus building scale and driving down costs), the more ads they can sell into the world.
If you consider all the things Google is investing in besides their bread & butter search & data centers, there are lots of reasons for them to have an in-house IC design organization. I agree, this small team is just the tip of the iceberg.
I also believe best for cloud providers to work with and compliment, microprocessor and other silicon design producers, especially ARM 64 design producers, aiding too add some necessary production economic volume to that business equation. Even if held captive by customers so long as the design development makes complimentary financial sense. In a concentrating industrial setting drawing that line somewhere just makes sense, on the cost expertise question for sustainable industry, trade, employment, supporting gross domestic product, even at you know who.
I have also speculated x86 decode engine hard in ARM, instruction look up tables, that are certainly available from the other guess who, yet others are known working on breaking that aspect of Intel monopoly once again. That would certainly require the deep pockets of public cloud provider's too keep Intel legal, and financial guilds at bay.
Noteworthy data analytics, and on batch processing, this analyst has determined from constant audit, multiple acceleration approaches and techniques, that are nascent realities of heterogeneous compute platforms capable of entering high end Xeon space.
If you look at high end blades in some big database systems, they're combining off-the-shelf multi-core x86 chips with FPGA-based hardware to accelerate distributed database processing. Google is bound to have problems that can be solved in a similar fashion.
But they're also really big, and the cost, in parts, power, and speed limits, of FPGAs may be suggesting that custom silicon is the answer. And that kind of thing gets even more interesting if you build it into your CPUs, saving power, eliminating any bus or communications bottlenecks between the two processor areas, etc.
Or maybe it's just plain old ARM chips they can buy from multiple sources.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...