91–100 of 123 posts
Earlier quoted context omitted.
How so? Google developed a server class TPU for Datacenters. Apple is trying to build on-device low powered custom chip.
Google announced it at I/O. They're using DSP's, specialized for neural network processing, on the SoC with TensorFlow Lite on the device. https://youtu.be/Y2VF8tmLFHw?t=1h22m8s
Knowing them this will be pretty good. The A10 is a beast.
Knowing Apple's (software) prowess in AI the end-result will still likely be shit compared to Google. (I think what we are seeing here is the usual thing where Apple's software/product/design people decide the iPhone hardware roadmap, rather than the hardware people.)
Earlier quoted context omitted.
Just as going from scalar to vector instructions provides a speedup so does going from vector to matrix instructions. If you've got big vectors than the amount of parallelism exposed for more hardware execution resources used on isn't too big but the reduction in register file read port usage is pretty significant. Also, inference is usually happy with int8s whereas graphics workloads are mostly float32s. So you can…
Why are graphics workloads float32? 32bit (1million+alpha) which is higher color resolution than most eyes can see - "true color" - is 3 8-bit ints + an 8 bit alpha channel (sometimes)
Why is Bloomberg not mentioning that Google announced it was working on the same thing? They mentioned vaguely that Amazon and Google both were working on AI, but nothing about the seemingly similar TPU and how Google announced they were going to bring it to phones at I/O just a bit ago. Am I wrong to be thinking that's pretty relevant here?
Because Google's TPU is for servers and not for Mobile.
Earlier quoted context omitted.
More work needs to be done on training models with less data, differential privacy, and unsupervised learning, but so long as supervised learning continues to be the main path forward for the current set of "AI" centralizing the data into ginormous data sets will continue to be the norm.
I don't see how unsupervised learning makes this any better? That data you're training on in an unsupervised manner is still collected somewhere, and could contain as much private information as a labeled dataset.
This is probably going to be a hyper parallel fixed point / integer engine like TPU gen1. Doing fast matrix multiply over really small fields is very subpar on CPUs and GPUs. That was the initial reasoning behind TPU gen1 - improving runtime performance. One question is if it will architecturally be closer to a GPU or an FPGA. The field moves so fast that it might make sense to "future-proof" a bit with a live-reconf…
You don't put an FPGA in a device you're going to sell 200M+ of. The cost per unit would be way higher than an asic, and your just going to come out with a better version next year anyway so why bother? I foresee it as similar to their M series co-processors - the first one was pretty basic, and more sensors and jobs have been given to the newer ones each year.
I think a lot of people in this thread are making incorrect assumptions about FPGAs implementations of neural network applications.
(1) forward networks are constant multiplications, i.e. Fixed shift and add. FPGAs are very nearly optimal architecture for programmable constant-shift-and-add
(2) individual neurons in a network can be bitwidth optimized and huffman encoded for bit-serial execution, FPGAs are a very nearly optimal architure for variable bit-width operations in a bit serial architecture with programmable huffman decoders [edited: huffman encoding, not hamming]
(3) running a forward network requires multiple channels of parallel memory with separate but deterministic access patterns. Most fpga architurs are designed with onboard ram specifically to be used this way.
(4) fpga architectures can be designed inherently fault and defect tolerant, like gpus disabling cores, but with finer granularity. Especially if the compilation is done in the cloud, the particular defect / yield profile can be stored for placement optimization.
(5) anything optimized for ASIC design will be necessarily so close to an FPGA that it may as well benefit from the existing programmable logic ecosystem to be flexibly optimized for a particular trained network. You can't just tape out an asic for every trained network, but based my previous points, you most likely can optimize the logic for a specific forward network to run on an FPGA better than any asic designed to run arbitrary networks
Earlier quoted context omitted.
Knowing Apple's (software) prowess in AI the end-result will still likely be shit compared to Google. (I think what we are seeing here is the usual thing where Apple's software/product/design people decide the iPhone hardware roadmap, rather than the hardware people.)
What is your basis for this? Am curious.
It has gone from "it just works" to a source of annoyance. Although nothing can top my work computer (Windows 7) for irritation.
Siri is a bag of hurt. I bet Apple has a very useful library of recordings of people saying "damn it, that's not what I said."
Just thinking about how terrible Siri is makes me hope and pray that they really aren't working on any self-driving car software.
Earlier quoted context omitted.
Knowing Apple's (software) prowess in AI the end-result will still likely be shit compared to Google. (I think what we are seeing here is the usual thing where Apple's software/product/design people decide the iPhone hardware roadmap, rather than the hardware people.)
What is your basis for this? Am curious.
It's nice that the article is trying to deliver an intro that explains that Apple clearly has some catching up to do. Except that now I'm pretty baffled, since I've seen an article a few months earlier, that says Apple is massively investing in AI, and already using it in several places in their products. So what am I supposed to believe now? :/
Apple is investing massively into AI and is using it in their products. However, Google has been working with AI longer and has much more experience. (The article praises Amazon's AI chops as well, I dunno about that one.)
Earlier quoted context omitted.
Just as going from scalar to vector instructions provides a speedup so does going from vector to matrix instructions. If you've got big vectors than the amount of parallelism exposed for more hardware execution resources used on isn't too big but the reduction in register file read port usage is pretty significant. Also, inference is usually happy with int8s whereas graphics workloads are mostly float32s. So you can…
Why are graphics workloads float32? 32bit (1million+alpha) which is higher color resolution than most eyes can see - "true color" - is 3 8-bit ints + an 8 bit alpha channel (sometimes)