Well this strikes close to home. During grad school, I'd drink a red bull (or two) a day. Now, I've quit caffeine completely (save a tiny cup of coffee in the morning occasionally).
I'm not sure I agree with you, long term (about the chips). I think that the value here is in the ecosystem. If Google can compete with CUDA, they'll be doing really well.
Yup, I assume they're gonna keep them in house as a competitive advantage for a time. I doubt they'll do it forever; the most valuable part of NVIDIA's CUDA is the ecosystem, and I think Google knows that.
This is huge. If they really do offer such a perf/watt advantage, they're serious trouble for NVIDIA. Google is one of only a handful of companies with the upfront cash to make a move like this.
I hope we can at least see some white papers soon about the architecture--I wonder how programmable it is.
For 3., I've been interested in the same. How would it work though? Would it include non-free components, or be open source? If it's open source, why would the majority of people pay?
I say this as someone who would definitely pay. I'd love to see something like an XPS developer edition, but with a (relatively) coherent graphics paradigm like OS X.
Almost all of the open source software in the area is permissive-licensed, and relies on non-free components (CUDA).
To be honest, I'm not sure how Gneural plans to compete with those packages without support from CUDA or cuDNN, all of which are distinctly not open source.
Can't speak for OCaml yet; I've wanted to learn for a while but decided to go with Haskell first.
On the Haskell side of things--it's biggest seller (functional purity) is also the biggest downside. To give you an idea, papers have been written about the best way to implement common data structures purely functionally.
From what I've seen, OCaml has less "abstraction overhead" because it can dip into imperative code. While Haskell is really fun, it definitely has moments where you want to beat your head against your desk.
This seems more like MirageOS/Ling than a rumpkernel. From what I remember, rumpkernels are more general, at the cost of being less "unikernel-y" (i.e. lean and fast). I agree that it would be easier and faster to use a rumpkernel if the intention is use in production soon.
I can't tell if this is a research project, or intended to be production quality at some point.
Noticed the same thing, wondered if I was missing some niche side effect here. TBH, I've noticed there's almost never a reason for a general reduce() in Python (to my usual dismay, as an ex-Clojure programmer). It does result in clearer, less clever code for the most part.
Exciting to see this! I haven't taken a look at TensorFlow code yet but it looks very similar (method names and all) to Caffe. I've wanted a CNN library for Rust for a while.
It sounds like performance is important to you. Are there any plans to add GPU paths soon? If it's CUDA, are you going to use cuDNN?
140 characters may not contain the full breadth of his view on the topic. Tweets are easy to compose but myopic. All the same, I understand your point. There's definitely stuff we don't know here.