Chris Lattner to Lead SiFive Platform Engineering Team
sifive.com
sifive.com
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.
You can get raw chips from taobao. I used taobao and a reseller, superbuy to get mine. Not bad at all!
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.
Thanks for the extra information!
https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF...
SeeedStudio has a few others as well:
https://www.seeedstudio.com/tag/RISCV-Board.html
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.
Also they are rated for higher clock speeds and claim better power efficiency.
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.
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.
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.
80K is pocket change compared to what they would have to pay in their home markets for experienced devs.
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.
I'm assuming they'll just die on the vine now?
I would assume the Swift/Tensorflow stuff will die, it was more of a thought experiment anyway…
How so?
Edit: Jesus it was a legitimate question, why the downvotes?
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.
This was a Tesla hiring mistake. You get an expert in a field, you can't just shove a guy whos good at one thing and expect him to excel in another.
Andrej Karpathy basically threw everything out once he replaced Latner.
> 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.
IIRC, he and Elon had some disagreements on software things.
Do a DuckDuckGo search for "lattner elon musk" and you'll find the info you are looking for. There was significant media coverage at the time.
I wouldn't read anything else into it.
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?
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.
also: https://twitter.com/JokerEph/status/1221831507351748608
I wasn't even aware of http://fast.ai's existence.
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)
https://swift.org/getting-started/#using-the-repl
> On macOS
1> import Darwin
2> arc4random_uniform(10)
$R0: UInt32 = 4
1> import Glibc
2> random() % 10
$R0: Int32 = 4
And lets not put Swift and performance on the same sentence, they still need to catch up a bit.
Aside from .NET and Rust, all the others are not players in 2020.
By the way, it is a list of languages with compilers that currently outperform Swift.
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...
(0..<10).randomElement()There are plenty of other examples I can look for, like file handling.
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.
There are widely popular FOSS languages with much much less documentation...
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.
Basically they set a portability boundary in the wrong place.
I had to manually set LD_LOAD_PATH on macOS, but then everything worked on macOS and Linux.
https://en.m.wikipedia.org/wiki/David_Abrahams_(computer_pro...
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.
That would be a weird move if they were looking to outright drop it.
[0]https://twitter.com/DaveAbrahams/status/1207690883782467584 [1]https://en.wikipedia.org/wiki/David_Abrahams_(computer_progr...
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
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.
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.
.. 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.
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.
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.
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.
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.
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.
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.
* 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.
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".
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.
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).
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 data scientists on Windows, including me, use SSH to connect to a GPU server running Linux for training models.)
Anyone that cares about bash on Windows can install mingw or WSL, preferably WSL2.
Tablets don't have CLIs by default.
Even if UNIX clones ruled the world, chsh is a thing.
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 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.
All of them much more mature than Swift, outside Apple's eco-system, including being able to target CUDA.
Also C++17/C++20 isn't that bad.
I learned C++ARM at the age of 16, and many Portuguese universities teach it at first year students, surely newcomers can grok it.
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.
Also, I actually learned C++ during high school, back when C++ARM was the only "standard", and most C compilers still did a mix of K&R and C89.
Nowadays many high schools do stuff with Raspeberry PI and Arduinos (Processing is just C++).
And you have books like these available https://www.amazon.de/f%C3%BCr-Kids-Grundlagen-Spieleprogram...
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.
But more than that, what makes me confident is the traction we are getting outside Google. First, we landed MLIR in LLVM last month: https://github.com/llvm/llvm-project/commit/0f0d0ed1c78f1a80...
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/ ).
I'm less familiar with S4TF, but I know they recently got some nice new hires, including https://twitter.com/DaveAbrahams/status/1207690883782467584
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.
Python Tensorflow, Julia, ML.NET, Tensorflow for C++, Pytorch, DL4J do all pretty well on Windows.
an ex-
ample
But on GP's (and my) screen it looked like this:
an ex-ample
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.https://en.m.wikipedia.org/wiki/Soft_hyphen
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.
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.
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.
https://cloud.google.com/tpu/docs/tpus?hl=en
> 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)
https://www.microsoft.com/en-us/research/project/project-bra...
I got the TPUs wrong and Brainwave right.
What they certainly are not is RISC-V.
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.
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.
Quite a worldchanging blog entry.