back

by teleforce·5y ago·view on hn ↗
Call me skeptical but to claim 1000x improvement for circuit simulation is at least hyperbole or outright lying. I will love to be proven wrong though. This by the fact that Julia is still depending on third party numerical libraries, e.g. OpenBLAS that depends on faster numerical languages like Fortran.

If you want to see next generation circuit simulation and automation that already working check out JITX. The simulator is using their advanced LB Stanza language which similar if not better than Julia[1]. This is the same team from Berkeley that proposed CHISEL and FIRRTL.

Other promising efforts on next generation digital and analog circuit design are from MLIR by LLVM team and LLHD from ETH Zurich [2][3].

[1]http://lbstanza.org/ [2]https://github.com/llvm/circt [3]http://llhd.io/

2 comments
Those efforts are quite different, focusing primarily on the design side with a focus on digital, while our effort is on ML-accelerated simulation of continuous time analog domain problems. I've met Chris Latter many times, and I'm pleased to see him work on tooling improvement in this space. He has a very good design sense for what compilers ought to look like. I've also met Patrick Li and we had an extensive discussion around the design space of multiple dispatch, which is of course Julia's core paradigm. I hadn't realized that Stanza was in use at JITX, but I'm glad to see it since there's enormous room for PL-based improvements. They are very different efforts though, so I'm somewhat confused by the off-hand dismissal of our work, without seeing any of the details.

One additional point: Julia depends on OpenBLAS not because Fortran is faster, but because doing the architecture tuning for all supported architectures and sizes is a bit of a pain and for standard BLAS problems there's very little reason to switch. We do have pure Julia packages that outperform OpenBLAS, but nobody has gone through the effort of replacing the base usage of BLAS usage and completing the pure Julia packages to achieve 100% API coverage. There's just no good reason to as long as the vendor BLAS packages (or OpenBLAS) work fine.

Most of the methods I've mentioned apart from FIRRTL can be used for analog design. In fact, the JITX's product in particular only support ML-accelerated analog based design mainly circuit board level at the moment but nothing stopping them for doing it for both analog and digital design later on.

Don't get me wrong I'm not dismissing your work, I'm just dismissal of the outrages 1000x claim, as they say "extraordinary claims require extraordinary evidence"(ECREE). I believe Chris Lattner and Patrick Li will probably cringe to hear the 1000x claim ;-). Like I've mentioned before, I love to be proven wrong.

Regarding OpenBLAS, it will be very good to have native Julia alternative as you've claimed. It is nothing new to be better than OpenBLAS since D language has done it with probably less than 10x (100x?) man power compared to Julia several years back[1].

[1]http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

The pure Julia (sub)BLAS (because they are incomplete right now) that benchmarks the best right now are Octavian and PaddedMatrices.jl. On Ryzen these BLAS's are doing extremely well:

https://github.com/JuliaLinearAlgebra/Octavian.jl/issues/24#...

but also on Intel:

https://chriselrod.github.io/PaddedMatrices.jl/dev/arches/ca...

I personally wouldn't spend too much time on BLAS-limited applications though, and this kind of circuit modeling is not one of them as I describe in another post. Also, it's 1000x at 99% accuracy: it's essentially a form of automated model order reduction which allows you to choose a tolerance and get more speedup matching the original circuit to the given tolerance.

Also, the major point is that BLAS has little to no role played here. Algorithms which just hit BLAS are very suboptimal already. There's a tearing step which reduces the problem to many subproblems which is then more optimally handled by pure Julia numerical linear algebra libraries which greatly outperform OpenBLAS in the regime they are in:

https://github.com/YingboMa/RecursiveFactorization.jl#perfor...

And there are hooks in the differential equation solvers to not use OpenBLAS in many cases for this reason:

https://github.com/SciML/DiffEqBase.jl/blob/master/src/linea...

Instead what this comes out to is more of a deconstructed KLU, except instead of parsing to a single sparse linear solve you can do semi-independent nonlinear solves which are then spawning parallel jobs of small semi-dense linear solves which are handled by these pure Julia linear algebra libraries.

And that's only a small fraction of the details. But at the end of the day, if someone is thinking "BLAS", they are already about an order of magnitude behind on speed. The algorithms to do this effectively are much more complex than that.

I am not sure why you are downvoted.

Google has been doing electronic with ML for some time now : https://ai.googleblog.com/2021/02/machine-learning-for-compu...

Python and Tensorflow work just fine for that task, the speed comes from LLVM and dedicated hardware such as TPU. The language in which the high level ML network/algorithm is specified doesn't matter much.

It is always good to have several paths explored, but I'm skeptical on the Julia hype since its beginning.

What it's doing is searching through circuit architectures, not accelerating the circuit simulation itself. If you have small quick circuits that's fine, but if solving the circuit once is a hard enough problem (which is true in the problems which we are targeting) then this problem would be infeasible with Google's algorithm because it relies on whatever simulator to exist. So it's just different methods targeting completely different sets of problems.
Well, that was just one public blog post. I would expect Google's R&D to go beyond what they publicly present.