I can't wait to see more affordable RISC-V microcontrollers on the market!
The Kendryte K210 looked very cool, especially with its SIMD-ish "machine learning coprocessor", but it felt like they had rushed the hardware to market without investing in scrutable documentation or software support, last time I checked.
The GD32V series looks fantastic, since the current crop of GD32VF103 chips appear to be API-compatible with the venerable STM32F103 workhorse. But I haven't been able to find a source of the raw chips yet, it seems like you can only get them on development boards at the moment.
And there are always softcores running on FPGAs, but those sort of highlight how many permutations of "RISC-V" exist. I hope that we don't end up with too many inscrutable compiler flags to juggle as more of these chips become available.
Not completely API-compatible. They are /extremely/ similar. Giga Devices did make an ARM STM32 clone, so they probably just did a ctrl-c, ctrl-p on the peripherals. Addresses are slightly different, and things aren't quite the same. I just ran into an issue with the system timer and it's lack of documentation... But good news is that they are pin-for-pin compatible, and you can put a raw chip onto a blue-pill board and use it!
You can get raw chips from taobao. I used taobao and a reseller, superbuy to get mine. Not bad at all!
Huh, what do you search for on Taobao to find them? I tried "GD32VF103CB" a week or two ago, but I only got results for the GD32F103 ARM clones.
I guess it makes sense that the addresses aren't quite the same; iirc ST has some licensing restrictions on their SVD/header files saying that you can't use them with other vendors' chips anyways.
Just note that you need a relatively new J-Link (v10 iirc) to program RISC-V cores using J-Link, alternatively for the Sipeed Longan boards, pick up two of them and you can flash one with a provided debugging/uploading firmware.
Yes, the Longan Nano is very nice but I'm also interested in the bare chips. Seeed also sells cheap JTAG dongles that work with their RISC-V boards, which is nice.
I've been using a clone J-Link which works pretty good. I got it probably 5 years ago, so it's impressive that it works. I think I'm using a patched version of openocd with it though.
What's the appeal in using an STM32 clone? Are you building things in quantities where saving a few pennies is really worth the headache of all the subtle incompatibilities?
The appeal is that there is a lot of good example code showing how to use the communication peripherals, but the CPU core is RISC-V instead of ARM Cortex-M3.
Also they are rated for higher clock speeds and claim better power efficiency.
In lieu of the documentation, Kendryte has _a ton_ of code on their github, so you could use that if you're looking to work on something practical. For me, having a dual core risc-v, with _TPU_ and _DSP_ onboard for $8 in single digit quantities is absolutely nuts. I frankly didn't believe it and thought the spec sheet was fake, but I've since bought some real dev boards with this chip, and they work. Even if you don't need the TPU bits, just having dual-core risc-v is more than worth the price of admission.
I don't care about TPU, don't need DSP, but dual-core - yes, please do. Having a dedicated core for hard-real time and using the other for more complicated things is way better than single core. I've seen so many projects attempting to cover timing glitches from their single cores doing everything.
I don't understand why there aren't many multi-core offerings. It's not as if the silicon would cost a lot more, especially when it would be possible to downgrade the speed and/or size.
It certainly would be pretty awesome if there was a modification of this chip without a TPU but with an MMU instead, so it'd be capable of running a proper OS rather than FreeRTOS or bare metal.
Seems like he has been changing companies quite a bit recently. Is this typical for the VP level? Does anyone know how his tenure at Google was viewed by others?
Well, his time at Tesla was basically (publicly, IIRC) determined to be a bad fit between him and the company, so can't really fault him there. So since his long tenure at Apple he had a misstep at Tesla and a shortish, but certainly reasonable, length at Google. Would definitely not call that job hopping.
You seem to have the impression that a machine learning model is all you need to drive the car: this isn't true. There is a lot of real-time system programming and overall architecture.
> Andrej Karpathy basically threw everything out once he replaced Latner.
What are you basing this on? I don't believe there is any truth to this.
First Chris was not replaced by Andrej but by Jim Keller and then Stuart Bowers.
Andrej is amazing in his field and has done impressive things at Tesla, but he is managing the ML part of the org, which was a relatively small portion of the Autopilot Software group overall.
That doesn’t really answer the question. “Not a good fit” is a bit of a euphemism in the industry - it typically is a polite way of saying “I didn’t get along with the CEO/CTO/leadership because X, Y, and Z” - and that’s what GP (and myself) are looking for. I doubt we’ll get an answer anytime soon - he’s a classy guy and probably still under NDA with Tesla.
With the benefit of hindsight, I'm really happy both that I joined Tesla and also that I left it. I have no regrets at all.
I learned a lot while I was there, but Elon and I had different opinions about some things. It was clear that he wasn't going to bend or change, and those points were important to me.
I have some principles that are extremely important to me, and if they aren't aligning, then it is best to acknowledge that and do something about it, than deny it and be frustrated or unhappy.
E is a force of nature -- for better and worse :-). I'm glad we have someone like him in the world, but that doesn't mean I want to be directly involved.
Any lessons on sticking to principles and how to make sure they align going into a project/role? I imagine it's hard to so preemptively rather than when push comes to shove.
It doesn’t really matter - he’s no longer there and I’m sure much happier because of it. There are a lot of irrational things management can come up with. Sometimes the manager in particular is a sociopath or narcissist. Or maybe you unknowingly offended them in some way. At that point there’s no reason to stay, regardless of the reason.
His credentials put him in high demand. Due to this, he has the luxury of changing jobs in order to find his fit. Jumping can dampen the demand at some point, but it hasn't for now.
I don't think it's the absolute length of time, but rather the fact that the projects he was spearheading (Swift for Tensorflow/MLIR) are nowhere near production-ready (or at least they weren't the last time I checked).
2.5 years seems a very short amount of time to develop, launch and push adoption for low-level PL tooling (in an ecosystem that's not mature, but at least is reasonably developed). I would expect 5 years at a minimum.
Ah, I wasn't aware that MLIR was now under LLVM. I'm not heavily involved with the LLVM Foundation but the whole project seems to be stable and well run, so that makes me feel more comfortable about the future of MLIR.
Depends what skills you have and how hot your market is. I know some people in big metro areas like London or Bucharest switching every year without problem as their skills are in high demand.
In German speaking countries that kind of job hoping isn't well seen, at all.
Anyone switching after an year means they barely made it after the six months probation time, so many employers will think twice about hiring them, unless they are in pressure to hire someone.
German speaking countries(apart from Switzerland) also don't pay their developers particularly well either as unlike US/UK/Eastern Europe they artificially cap salaries instead of letting the market dictate so of course they don't like people switching jobs as they have to pay more to stay competitive, even managing to convince their developers that €80k is a top salary while their counterparts in Warsaw and Bucharest make that or even more. German/Austrian devs are severely underpaid.
Also, unlike UK/US, they have this nasty habbit of not mentioning their salary range/hiring budget in job ads to low ball you during negotiations.
I look at it the other way around. They're probably talented enough to make it past probation, so their leaving was them deciding to leave, rather than not making it. That is, any investment you make in them, giving them slack to get up to speed in a codebase, you'll lose because they don't stick around.
I interpreted him going to Google as a place to learn a few new things while figuring out what to do next. He’s done some big stuff in the past. But even people like him need time to figure out what to tackle next.
Anyone who has been following his projects knows that 2.5 years is too little a time for the problems he set out to solve and the projects he was leading (esp. with TensorFlow, MLIR, TF runtime, TPUs). So this is really a very early, abrupt and surprising exit, and several people both inside/outside know that he ran into political issues/struggles with high-level folks. Fortunately, one of the projects (MLIR) is already part of LLVM and will remain unaffected, but looks like S4TF may just die out irrespective of what's being said. Otherwise, we may not hear much on the details given his "seemingly" reasonable length stint at Google.
He seems like the kind of developer that needs a real challenge to work on. When things shift into maintenance mode, he gets bored. That’s my take anyway. He’s a brilliant programmer. I’m glad to hear that he’s working on something really interesting.
I would avoid binning people into builders or maintainers, there are many more issues that could prompt one to leave Tesla and Google, eg: Work environment or ethical issues.
Swift for Tensorflow could never be taken seriously outside Apple community.
On Linux, Foundation barely works and one still needs to selectively do either import Darwin or import Glibc for basic IO stuff.
Then we are already at Swift 5.1, and Windows version has to be built from source will lots of caveats.
How can it even be taken seriously against Julia, Tensorflow for C++, ML.NET all of which work across macOS, Linux and Windows as of today, and offer the same strong typing benefits?
While I agree there is an even chance that Google will allow S4TF to fade away after Lattner's departure, that is more of a reflection on the company having no commitment or consistency to good ideas: ex: https://gcemetery.co
However S4TF should be taken seriously if you understand what they are trying to accomplish and how deeply they designed machine learning support into the language. Take a look at http://fast.ai new course offerings using S4TF. Swift has always been a long bet. If it doesn't work as you want it, is still short sighted to discount it in the future.
With all due reference to Jeremy and Fast.AI (which I love and continue to recommend) I think it's fair to say they don't stick with things for a long time. I think the Fast.AI python library has been re-written 3 times in the past 3 years (Keras -> PyTorch -> PyTorch, differently).
The Swift core team just added two new members, whose contributions are related to Swift on Windows, and Swift on the server respectively, and have specifically called out supporting Swift in non-Apple domains as a part of the roadmap for Swift 6 (including adding the autodiff work from S4TF into mainline Swift). There is attention being paid to these issues.
Thanks for the heads up, I have been looking at that thread, the roadmap still looks quite uncertain, with big questions regarding what Apple is willing to support outside their platforms, tooling (e.g. IDE support), dependencies to WWDC announcements and deliveries.
I love the idea of Swift for Tensorflow : powerful automatic differentiation and a solid type system in a single language.
That's something that is not seen elsewhere and that would make it a perfect fit to write deep learning code targeting production systems.
Now the language needs two things in order to be safe from an hypothetical abandon from Google :
- running smoothly on linux (I though it was already there but your post seem to imply that it is not the case)
- getting the auto-diff out of the alpha stage where people can build framework on top of it (fastai seem to be ready to jump on that ball which is nice)
Having distinct Darwin or Glibc imports seems a little crazy for these examples. When you code in c, libc is just there. It has minor variations from platform to platform, but you always think of it as libc. (Even if Darwin calls it libsystem etc. Or if Microsoft's is mscvrt and it kind of sucks.) It would be more reasonable to call it libc. (If I run on BSD do I still call it "glibc" with no actual GNU present? And if the arc4random APIs present in libc there look a lot like Darwin's because they actually share code? Maybe they have not considered porting to non-linux?)
Basically they set a portability boundary in the wrong place.
But for context, the previous sentence on that page is:
“You can also import any available system modules, such as Darwin on macOS and Glibc on Linux”
The random number examples aren’t saying that’s the right way to generate random numbers in a platform-independent way, it is specifically demonstrating how to import system libraries on your local platform.
File handling can be done using Foundation, which I believe has API parity between Darwin and Linux at least.
I think the point of the example was to demonstrate importing platform-specific modules, not random number generation per se. But you're right, it should probably be updated to do something else.
Not many use an actual c/c++ compiler (clang) to generate language native calling convention wrappers for calling into C/ObjC code (not sure how well c++ interop works these days).
Ah, that might be the reason why NVidia is adopting Ada for their firmware, ebay and Netflix decided to use D for some of their projects, the Turkish government decided to invest into Delphi for their education system,...
By the way, it is a list of languages with compilers that currently outperform Swift.
>Ah, that might be the reason why NVidia is adopting Ada for their firmware, ebay
A, the "some part of some huge player with 2000 divisions uses some otherwise niche language, surely said language is making a comeback" argument.
You can find all kinds of niche/sidestepped languages if you look hard enough on any organization that has 200 products, 1000 inside projects, and tons of engineers. Doesn't mean said languages are making a comeback anytime soon.
For languages that actually thrive nobody needs to enumerate major and minor projects where they're used, because they're too many to mention. But when the main news for "Planet language X" is "big corp decided to use X for something among the 100s things they do", well, they need all the straws they can grasp.
Same way Latin remains a dead language whether some Oxford professor recently published a book of new poems he wrote in it or not...
for what it is worth: a few days ago I installed the latest Swift and TensorFlow in Swift on both my little MacBook and my Linux laptop (1070 GPU, i7, fast laptop).
I had to manually set LD_LOAD_PATH on macOS, but then everything worked on macOS and Linux.
sadly i agree with you. initially i was really excited about S4TF because swift is a fantastic language and it would be a fantastic replacement for python as the defacto ML language. but then i realized tensorflow is much worse than pytorch and the S4TF team was too small to build anything substantive enough to win market share.
S4TF was started over 2 years ago, and hasn't really gained any ground since then. It's a project on life support and Lattner's departure means the project is going to be put down soon.
It's good to try different things; S4TF tried, and failed. No one really cares about it at Google except the team developing it. The researchers are adopting other new technologies, like JAX.
Unfortunately Swift is a dud.... and the Apple ecosystem is stuck with it for the next few decades....
I have said, Swift is to Objective-C, what Scala is to Java. Sure, there are plenty of people that like Scala, but its 'academic stuffiness and complexity' doomed it to a niche language.
Same with Swift. It is doomed to be an apple ecosystem only type of language.
All I wanted is a Python* look alike, with some solid static typing, what we got was a franken/monster/language where people felt to try out their little academic pet-peeves, and sucking out the fun out of programing with it, and making it less accessible to beginners.
GO is becoming popular, not because it is shoved down the throat to people, but because its own merit, and mainly because they kept it simple. It is a closely to a "static Python and some minimal features" we got....
*I think Python is a great language, and very accessible for beginners, just not suitable for large projects due to its dynamic type system
I write iOS apps for a living. Most the people I know have moved away from ObjectiveC. When I see language boards, and jobs for iOS, I see Swift asked for over ObjectiveC. On Reddit, Swift has more subscribers than ObjectiveC, most of the tech articules I see these days are ObjectiveC, when I watch a video on WWDC I often see Swift first.
Swift may not be what you wanted, but it is a long way from being a dud. Swift didn't have to be great, it just had to be better than ObjectiveC.
Because of some technical argument, or just personal aesthetics?
>I have said, Swift is to Objective-C, what Scala is to Java. Sure, there are plenty of people that like Scala, but its 'academic stuffiness and complexity' doomed it to a niche language.
While Objective-C was really cool, it was neither modern enough, and few people liked it (mostly old NeXT/early OS X guys, but not most of the iOS crowds).
And Swift is easy to use and nothing like Scala in academic-ness and complexity.
>All I wanted is a Python look alike, with some solid static typing*
That's not what the ecosystem needed, or what people in general want (there's Go for that, for one). Swift is somewhere between Rust and Kotlin, features wise.
I'm not sure this argument makes sense. I'm not primarily a Swift developer. My goto languages are Python, C++, Java and Javascript (I build DevOps automation pipelines and monitoring tools -- primarily for scientific computing). But my experience with Swift on MacOs and iOS has been pleasant. I definitely would not use it for cross-platform development. But that is not because the language isn't nice. It's because it won't have widespread support outside the MacOS ecosystem. But for UI apps on MacOS and iOS, it is the best choice. Similarly, I use C# for Windows UI apps, but would not use it for anything else. Use the right tool for the job.
Have you checked Nim? It's the closest thing to static Python that I know of (plus some extras like Lisp inspired macros), and there is some early development of a machine learning ecosystem (outside of wrappers):
When I read that SiFive is working on custom silicon, my first thought was to wonder what would happen if custom hardware and custom programming languages co-evolved together, instead of languages adapting to old hardware that's adapted to older programming languages.
.. and here he is talking about compilers. I might have to keep an eye on SiFive in addition to Oxide.
There are some other people talking about him not staying long at places. In this talk he mentions how he intended to stay at UIUC for one year and got 'nerd-sniped' into staying for 5 years building LLVM. After an experience like that, I could see how someone might feel claustrophobic and tend to take any opportunity on offer - if it's interesting enough.
I wonder if this will curtail the effort to implement TensorFlow in Swift, turtles all the way down?
That would be a shame. Python ecosystem with TensorFlow, PyTorch, mxnet, etc. has been good for rapid progress but I think we need something better to break out of just using deep learning. This needs a hackable infrastructure. I personally don't have the skill to hack the C++ TensorFlow core.
I think a new ecosystem based on Swift, TensorFlow, and future tools and platforms makes some good sense.
An alternative would be a similar hackable infrastructure based around the Julia language, which is also very good.
Even in swift it isn't "turtles all the way down".
The AD stuff is hardcored into the C++ guts of the compiler, whereas Julia's source to source autodiff accesses a compiler pass from a fully Julia user package.
Aside from making it easier to hack and improve the AD system as just a Julia user, this capability enables other package program transforms like that in https://github.com/MikeInnes/Poirot.jl for prob programming.
So Julia is already further ahead in that regard and it's more hackable.
re: "So Julia is already further ahead in that regard and it's more hackable."
I agree. Flux is very concise, very nice to work with. I just had some trouble with my small playing-around code snippets when going from one minor release to the next, but that probably means I should revert to the LTS 1.* version.
I have tried Julia with non-mathematical stuff like using it with sqlite, fetching and using RDF data, and general text processing - nice for those use cases also.
He went from Tesla to Google in no time flat, less than 3 months. But he was at Google from August 2017 until now which is significantly more than one ISO no time flat unit.
I was super tempted to buy the new learning development board they just released (which is actually tough to get in the US) but I actually haven't been able to figure out the benefits of the new SiFive processors compared to other traditional arms boards like a M0. Anyone here familiar with their boards that can provide some insight?
Why should a random tinkerer trying to learn or get a basic job done with a microcontroller/CPU care whether the architecture is open source? It's still overwhelmingly difficult to do anything interesting with the fact that the architecture is open source.
There are a couple nice innovations happening in RISC-V. A lot of nice FPGU stuff where you can extend the architecture yourself and tooling that supports that.
There are some cool RISC-V chips out that have different advantages, AI accelerators, lower power and so on. Lots of security stuff as well.
I mean sure, all those things exist in the ARM world to some extend or another, but there is defiantly cool stuff being built.
I didn't say anything about ARM specifically either. If I were a random tinkerer, I would choose based on these factors:
* Ecosystem support (libraries, stack overflow, docs)
* Quality of tools (compilers, debuggers)
* Price/availability
ARM is probably a good choice based on these factors, due to things like Raspberri Pi and Arduino (not all ARM but maybe the more popular ones are?). Open source hardware architecture doesn't really factor in anywhere here.
Then to be honest it's a bit difficult to explain this to you in one post. Assuming you are even willing to consider any other perspective than you own egoistical current short-term position, then if you want you should read up on how this industry operates, on politics in it, on how processors and architectures are contracted and licensed, on what lobbying and political tools do big manufacturers like Intel use in order to get their advantage, about the history of the different architecture in general, on cybersecurity of the aspects of open/closed silicon, etc. etc.
In short, yes RISC-V is a huge deal and if you care anything about software, hardware or computing in general you should be very happy and optimistic because of its existence. The team behind it is doing a tremendous monumental job of creating a free architecture, and they are still in the beginning of it.
Yeah, I've been following SiFive for a while now, especially since their announced tool for custom "ASICs" and I know they're a huge driver for RISC-V. I just haven't seen their MCUs used much and curious what advantage they have over other competitors.
Their value proposition is basically that you can get to market with a costum chip cheaper then with anybody. They argue that their chips are lower energy then use less space. They are more configurable, and the RISC-V tooling is build around this as well.
They do seem to quite a few costumers but their current growth is VC funded.
There is nice stuff coming down the pipe as well, the RISC-V Vector extension and hopefully finally some linux boards. RISC-V SoC with FPGA is going to be a product. But hardware product cycles are just long and a takes a while.
Both were probably designed the same way - company name is "word five" so take the first letter and fit it into a 5 sided polygon and bam you've made each logo.
SiFive's actually fits this design more even though it came out later. They don't need the added shape at the bottom and the embedded character can be seen as either "s" or "5" while the carbon 5 one needed the extra bit at the bottom and is a bit harder to see the "5".
I don't think that's nearly as close to Carbon5's logo as the SiFive logo is to Carbon5's, but fair point, there's always overlap in these... when I posted that I actually couldn't see the difference between their logos and was genuinely a bit confused if they were connected, but I see a small difference at the bottom of the Pentagon now... so it seems unlikely there's an intentional connection, but was genuinely confused at first!
MLIR is getting used internally more and more inside TensorFlow, but also by separate team in different projects, like IREE for example (https://github.com/google/iree ). The TensorFlow lite converter has been replaced by the new MLIR-based one, similarly for the Edge TPU.
The LLVM Fortran frontend (f18/flang) which will merge soon in the LLVM monorepo is using MLIR for their own IR. It'll be exiting to develop a non-ML MLIR-based frontend within LLVM! In particular Flang is opening an HPC perspective that could be leveraged by other DSLs later.
They are adding an OpenMP dialect to MLIR right now: https://llvm.discourse.group/t/rfc-openmp-dialect-in-mlir/39...
Intel has been actively porting their nGraph/PlaidML framework to be based on MLIR (search for "The Stripe dialect" and "nGraph Dialect" here: https://mlir.llvm.org/talks/ ).
Edge TPU will eventually be canceled as well, I'm pretty sure, which is why, as exciting as it is otherwise, I'm not using it for anything practical. There's just no way to make $1B/yr with it, so it's officially below Google's executive interest threshold.
By far the #1 committer and founding engineer of Swift for Tensorflow also recently left the project: http://rxwei.me/about/ . From the committer list, it looks like Dan Zheng is the only individual who is actively working on it, and he's was an intern until he formally started January 2019. I don't know the ins and outs of Google culture, but it looks at least like every senior engineer has moved onto something else.
There are medium sized teams at Google for each of MLIR and s4tf. There's a weekly open design meeting for each of them. Many different folks have presented their work at both meetings.
Not clear with MLIR, since it seems to have some traction beyond S4TF.
But yes, I think S4TF has had zero interest among people actually doing ML and is probably dead. It might take Google a while to actually kill it off, though.
From conversations I’ve had with people doing ML, if they know about S4TF at all they actively dislike certain aspects (for example that it’s based on a statically typed language), or are dismissive of others (like support for differentiation, which is a neat parlor trick but saves a tiny bit of effort).
Not "zero" IMO. I, for one, was excited about its potential, I was just waiting for it to mature (wisely in retrospect). Python is really bursting at the seams for ML/DL at this point and the ecosystem is in need of a proper compiled language for implementing deep learning systems. This language must be easier on the newcomers than C++.
Imagine a future where you could tell if your shit's broken by recompiling it, and your "deployment" would be just putting some RPC in front of your existing code.
Most people I know that understand s4tf well (including me) are excited about it. Chris Lattner and I co-taught two video lessons on it - have a look at those and see what you think: https://course.fast.ai/videos/?lesson=13 .
Hey Jeremy, I'm a really big fan. I got really interested in Swift based on your initial blogpost on it, and managed to get the company I work at to invest a bit in researching how suitable it could be for real time ML on video.
If it's not too forward, do you know at the moment if FastAI will continue to invest in Swift? I know development was a bit stalled due to the work needed for FastAI 2.0, but I was wandering if it'll resume, or if Richard Wei and Chris Lattner leaving changes anything?
Cheers and thanks for FastAI!
PD: Was working a bit on SwiftCV, added the videoio and highgui modules. Was wondering if I should PR it to fastai's or vvmnnnkv's version of the repo?
I would be delighted. I've even spoken to the Julia core team about it. Hopefully one day they'll make that happen! (Just like we developed SwiftAI thanks to support from Chris Lattner and the s4tf team).
Probably easiest is to use Colab, which supports Swift directly. Otherwise, use one of the approaches shown on the course site: https://course.fast.ai/
(Most data scientists on Windows, including me, use SSH to connect to a GPU server running Linux for training models.)
Windows needs to die though. The sooner it dies, the sooner we can all just assume that everything has bash and a bunch of excellent compilers installed.
C++ isn't that bad if you already know it. I agree. I enjoy programming in C++ myself. For anyone just starting out, it's pretty horrifying, which is why there aren't a lot of experienced C++ programmers around. Its worst trait is that it encourages excessive cleverness, and left unchecked that can very quickly make any code impossible to understand.
Also Portuguese universities seem to be out of sync with the rest of the world if they teach C++. In the US most people with a CS degree haven't been exposed to C++. It's either Java or something functional. C++ typically doesn't even come up. Which is pretty puzzling to me, because most of the programs I use daily (including this very browser) are C++ programs.
I was also pretty excited when I heard that they were baking autodiff into the language but unfortunately Swift has very little traction outside of mobile development, which makes it a hard sell.
I think a compiled subset of python is the best way to make that happen. All of the JITs (Numba, PyTorch, Jax, etc) already handle a decent portion of the language, so it should be doable.
Last I checked, Swift is still years away from 1st class Windows support and adequate tooling. Without those in place, Swift+Tensorflow is still a very niche product for Google and I cannot think of a good enough reason why they should heavily invest into it.
Wild speculation, but my guess is that both will continue to be developed.
As far as I understand, the MLIR project predates its machine learning application and was originally intended as a new IR for clang. In that capacity it makes a lot of sense. MLIR is also currently experimental in Tensorflow, although I have no idea how mature the implementation is.
Similarly, there has been significant investment into Swift for Tensorflow, so it's probably here to stay. On the other hand, from a language design perspective Swift is not a particularly good choice for automatic differentiation and translation into Tensorflow graphs (imperative, exposing many details of the underlying machine, etc.). Without a lot of investment into this project it might just be overtaken by a better engineered competitor, or more likely, fail to gain sufficient mind-share over the "good enough" python solution that already exists.
Some of the hyphens here are fine and some aren't.
One legitimate use of hyphens is to break a word at the end of a line so that part of the word is on one line and part is on the next line. (This was uses a lot in the days of physical newspapers and magazines which uses pretty skinny columns but didn't want to leave ragged whitespace that wrapping the full word would cause.)
In this case, it looks like the text was wrapped like that, hyphens were inserted, but then the text was rewrapped (without hyphen breaking) to a different width, but the hyphens from before were still left behind.
E.g., you can see a line on text like this: "Similarly, the RISC-V architecture pro-vides unique opportunities for SoC customization at every level. This is only possible with SiFive’s ambi-tious design methodology, which is unmatched in the industry."
where "pro-vides" and "ambi-tious" are inappropriately hyphenated.
The text probably looked like this at some point:
Similarly, the RISC-V architecture pro-
vides unique opportunities for SoC
customization at every level. This is
only possible with SiFive’s ambi-
tious design methodology, which is
unmatched in the industry.
the browser won’t display any glyph unless it breaks the word at that point. Alternatively, you don’t need to insert soft hyphens at all if you’re fine relying on the browser’s hyphenization dictionary for your language, and the CSS word-break property is set. The downside there is that sometimes the browser will get really aggressive and terminate nearly every line with a broken word, reducing legibility.
I'm not sure whether GP refers to joining phrases up (like "end-to-end" or "idea-to-silicon" or "one-stop-shop") or using it instead of a comma ("I also spearheaded the creation of Swift - a programming language that powers Apple’s ecosystem - and led a team at Tesla that applies a wide range of tech in the autonomous driving space"). The former is just a matter of taste (but IMO has a teensy flavour of "marketing" about it), the latter is totally fine too.
I think GP is referring to stuff like "pro-vides" and "program-ming" which look like they were hyphenated to line-wrap, but depending on the width of your browser window probably don't actually split across lines
To dive down into the pedantic with you all, I think in the latter case the hyphen is incorrect. Normally in that place is an en(–) or em(—) dash. Hyphens are used for joining or breaking words. IIRC
The GP is talking about how the text was written with hyphens inserted where words crossed a line break, but then the text was reflowed so the lines no longer break at the same spot. For example, in the original, it looked something like this:
I have hard time connecting "machine learning" with what RISC-V is about.
Above all, the original plan for RISC-V was to make a barebone MCU ISA first, and everything else second.
This was largely to ARM being very militant with terms on RTL access for M* series cores for commercial use.
If you throw enough extension, and workarounds even on top of 8051, you should be able to make a CPU grade core with it. But you being able to do it, doesn't mean you should.
RISC-V was originally developed because some vector-processor / ML people at Berkeley needed an extensible control processor for their specialized hardware.
They'd previously been using ancient 32 bit MIPS but they needed 64 bit, a good amount of spare opcode space for custom instructions, and reasonable licensing and nothing suitable existed so they rolled their own.
RISC-V with the almost-done Vector extension is likely to be a big force in ML hardware.
Whatever number of ALUs / DSP slices you can put in an FPGA and soft-wire together, you can put just as many hard-wired in a custom SoC with lower area and cost, and faster performance.
An FPGA is good for prototyping this until you figure out the best arrangement, sure, but three months later you can have real chips.
> Tensor Processing Units (TPUs) are Google’s custom-developed application-specific integrated circuits (ASICs) used to accelerate machine learning workloads.
> Project Brainwave is a deep learning platform for real-time AI inference in the cloud and on the edge. A soft Neural Processing Unit (NPU), based on a high-performance field-programmable gate array (FPGA)
The guy who designed TPU works on RISC-V and is a fan of RISC-V. And on of the reason was his experience with TPU, he realizes that custom hardware is really great but a more generally programmable approach would have advantages.
That's exactly what the RISC-V Vector extension was designed for. When they started TPU RISC-V wasn't ready for something like that and the Vector extension was at best an idea.
Saying 'RISC-V' is bad for ML because XY product doesn't use it, is a terrible argument in general. Over the next 10 years we will have literally 1000s of different things that make AI fast. All of those come with tradeoffs.
RISC-V as a base chip for many system is clearly a great fit, even on FPGAs. The RISC-V Vector extension is an excellent for many AI problems and many companies are currently working on that.
> Above all, the original plan for RISC-V was to make a barebone MCU ISA first, and everything else second.
This is simply not correct. RISC-V was designed to allow minimal cores but by design it also tried to cover everything from minimal to HPC.
> This was largely to ARM being very militant with terms on RTL access for M* series cores for commercial use.
Again this is not correct. Are you just making this stuff up? The reason they developed RISC-V is because of complexity and license issues that would not allow them tape out say x86 or ARM.
> If you throw enough extension, and workarounds even on top of 8051, you should be able to make a CPU grade core with it. But you being able to do it, doesn't mean you should.
Why not? Is your instruction gone run slower because it spec is written down in a different PDF document? Are you mixing up ISA and micro-architecture?
If you take the whole RV64GCVBH you have a full featured core that is designed to allow super high performance implementation. And the ISA design is easily better then any of the other ISAs.
100 MIPS and 16 MB of RAM from 256 Z80s in 1981. You can get the same from a single RISC-V soft core in a cheap FPGA board today. More, because a 32 bit RISC MIP is worth several times more than an 8 bit Z80 MIP.
Observational comedy is intended to give the viewer this: without it having a very real basis in reality, the joke wouldn't have been funny (at least, not in the same way).
The Kendryte K210 looked very cool, especially with its SIMD-ish "machine learning coprocessor", but it felt like they had rushed the hardware to market without investing in scrutable documentation or software support, last time I checked.
The GD32V series looks fantastic, since the current crop of GD32VF103 chips appear to be API-compatible with the venerable STM32F103 workhorse. But I haven't been able to find a source of the raw chips yet, it seems like you can only get them on development boards at the moment.
And there are always softcores running on FPGAs, but those sort of highlight how many permutations of "RISC-V" exist. I hope that we don't end up with too many inscrutable compiler flags to juggle as more of these chips become available.