Having these tools as open source and freely available is a huge deal for so many industries. I've worked with these tools at an academic level and now at a startup, and it's amazing the magnitude of this enabling technology. Just the tooling investment will be huge, making the core solvers and algorithms more accessible should spawn a whole new wave of startups/research in effectivley employing them. Just these days, I've heard of my friends building theorem provers for EVM bytecode to formally check smart contracts to eliminate bugs like these [0].
These synthesis tools roughly break down like this:
1. Specify your "program"
- In EDA tools, your program is specified in Verilog/VHDL and turns into a netlist, the actual wiring of the gates together.
- In 3D printers, your "program" is the CAD model, which can be represented as a series of piecewise triple integrals
- In some robots, your program is the set of goals you'd like to accomplish
In this stage, it's representation and user friendliness that is king. CAD programs make intuitive sense, and have the expressive power to be able to describe almost anything.
Industrial tools will leverage this high-level representation for a variety of uses, like in the CAD of an airplane, checking if maintenance techs can physically reach every screw, or in EDA providing enough information for simulation of the chip or high-level compilation (Chisel)
2. Restructure things until you get to a an NP-complete problem, ideally in the form "Minimize cost subject to some constraints". The result of this optimization can be used to construct a valid program in a lower-level language.
- In EDA, this problem looks like "minimize the silicon die area used and layers used and power used subject to the timing requirements of the original Verilog", where the low level representation is the physical realization of the chip
- In 3D printers it's something like "minimize time spent printing subject to it being possible to print with the desired infill". Support generation and other things can be rolled in to this to make it possible to print.
Here, fun pieces of software in this field of optimization are used; Things like Clasp for Answer Set Programming, Gurobi/CPLEX for Mixed Integer programming or Linear programs, SMT/SAT solvers like Z3 or CVC4 for formal logic proving.
A lot of engineering work goes into these solvers, with domain specific extensions driving a lot of progress[1]. We owe a substantial debt to the researchers and industries that have developed solving strategies for these problems, it makes up a significant amount of why we can have nice things, from what frequencies your phone uses [2], to how the NBA decides to schedule basketball games.
This is the stuff that really helps to have as public knowledge. The solvers at their base are quite good, but seeding them with the right domain-specific heuristics makes so many classes of real-world problems solvable.
3. Extract your solution and generate code
- I'm not sure what this looks like in EDA, my rough guess is a physical layout or mask set with the proper fuckyness to account for the strange effects at that small of a scale.
- For 3D printers, this is the emitted G-code
- For robots, it's a full motion plan that results in all goals being completed in an efficient manner.
A lot of the tooling speed comes from a couple places:
1. The compiler optimizations being applied to code
- Things like GADT's are able to be allocated very efficiently
- Can generate code that doesn't box at runtime (smash it into a pointer is done as well)
- Pointers are word-aligned
2. The OCaml runtime
- No JIT
- No warmup
- Can emit native code
3. The HM type system
- Typecheckers for HM are really simple [1]
This simplicity + the features of the compiler combine to make the OCaml compiler very fast, and very easy to write one (some undergrad CS classes do), and developer-time tenable to make both happen.
Integrating with 20 year old PLC's and robots is such a pain. Most people we work with have stacks upon stacks of abstraction to keep them safe and give them a sane wrapper for the functionality of the robots.
So many labs have homebrew monstorous python scripts made by a grad student that left 2 years ago that everyone uses and no one can maintain.
Learning enough to make your own spin on things by mixing and matching parts is really easy once you understand the mathematical underpinnings of things.
It's true, many API-level things are opaque about how they work, but their theoretical foundations are usually possible to pick up.
I guess a good way to do this is via an example. I had to build a system to hit the following criteria:
* The data is scarce
* The data is time series
* The data follows a state machine
* The data is noisy, and contains a signal that's unique across all training samples
Gluing together multiple domains of knowledge, from generative tactics for label propagation, to EM for state-machine convolutional decoding, to 5 or 6 others gave the company something that worked, in a short timescale, that scaled well.
It's understanding where things glue together and under what circumstances to apply that glue has been what's been most helpful to me.
A great place to get an intuition of what I mean is Louppe Giles's PhD thesis on random forests, specifically stuff like the section on the bias-variance tradeoff.
Scala.js scratches that itch for me. I rarely write frontend code, but when I do the extra IDE support given to me by IDEA for Scala.js is pretty great.
I'm a full time Scala dev though, so I'm totally biased
One of my professors, while an extremely competent physicist, chose to focus far more on the "philosophy of teaching". Sanjoy's metaheuristic approach to teaching, tooling it like a hard science with real analysis of the effect of differing methodology resulted in a fantastic class, called "The art of approximation". Turns out the 80/20 rule can be stretched in so many different ways!
I don't understand why they included the butterfly synchronization model at all compared to the lazy update one, the latter is far faster, especially when you have raw access to GPU raw memory.
It's interesting to note just how applicable these talks are to other languages. That database one is something i'd recommend a high schooler listen to for their next hackathon.
Their Youtube channel [0] is excellent, they really grab the attention of someone young about a large variety of topics, and they really make you want to keep watching their videos.
The point that you make about the "old" paradigm is completely valid, in the fact that we're seeing a shift away from towers with interchangeable components to something like a NUC or mac mini for the "average" user, as these smaller formfactors are "good enough".
Project Ara on the other hand is trying to do something else entirely. They have the formfactor defined already, that of a modern smartphone. What makes it so interesting is the fact that they're trying to take that formfactor and add the inherent flexibility that comes with a larger system, but without changing the formfactor. This is akin to getting ATX full tower expansion in the same space as the mac mini or even mac pro. It's a daunting task to say the least, one with a constantly changing frame of reference, as the smartphone evolves into a thinner sleeker and lighter device. This makes the Ara developers jobs doubly hard, as they have to develop for 2 generations ahead of where we are for size and weight constrains, while still keeping the bulky, power hungry, and prone to failure interconnnect that is required to assemble disparate parts into a whole unit, as well as all the modules within this target.
It's a race that they may never win due to how rapidly those targets shift, but we can hope that it's a moonshot project that one day renders tangible benefits for the everyday phone.
To be honest, i'm less and less excited about these physical devices with the set of constraints that being physical devices imparts to them. I really wish that within the next 10 years we hit a Virtualization-level jump in how we interact with information, allowing us to abstract away trivial things like screen size and compute power. The only way this is going to happen is through augmented reality, a clear moonshot project i wish a few more companies invested in rather than the halfhearted attempt that is google glass.
I'm working on a frontend to manage arbitrary applications, and provide a centralised place to manage them all. It works across machines through ssh, and can provide pretty statistics and logging bits and pieces, but the core of it is to do something to multiple machines at once.
I can select and add arbitrary numbers of machines to a job, then run it, and also put that command on a schedule. Say i want all my packages to be upgraded at all times. I can have this every night at 00:01, to ssh to all the machines and run the appropriate command based on architecture.
This is useful for my internship, where i have to simultaneously deploy and manage many machines, and this app has proven to be immensely scaleable, with up to 1000 VM's being managed at once with no signs of slowdown.
Some of these JetBrains IDE's are really good, and hopefully this will make the mind-numbing task of writing this a lot more pleasant. Here's to their eventual MongoDB support
Its mainly used for the DP floating point that isn't limited artificially. The titan supercomputer at ORNL uses an older version of these. So heavy compute.
IMHO the only reason you'd want this is to save on a PCIe slot when you absolutely need the double-precision floating point operations to run at full speed.
Once you have a mask set and fab time, it's off to the races. IMO $1M really isn't bad for a simple chip run.
[0] https://anysilicon.com/semiconductor-wafer-mask-costs/