HN user

peterhj

52 karma
Posts0
Comments29
View on HN
No posts found.

On the contrary, "dark silicon" instead suggests that separating fp32 and int32 (now in GA102/104, fp32 and int32/fp32) data paths at the cost of more die space usage currently makes excellent sense. (See also: tensor cores, ray tracing cores.) Jensen Huang very briefly alluded to this when during the GA102/104 announcement he mentioned the end of Dennard scaling.

PyTorch 1.5 6 years ago

Fun fact: Alex Krizhevsky's cuda-convnet was also an early adopter of CHWN tensor layout. Basically, having the batch size N as the major dimension limits you to running batch sizes that are multiples of the warp size (typically 32), but then you also have an easier time of implementing fast kernels for all your neural and tensor ops, including tensor convolutions, without getting nearly as stuck in the weeds of microarchitectural optimizations.

rustc does have a working nvptx target today, though it’s not supported nearly as well as the mainstream cpu targets, and some things you would really want for gpu programming (e.g. shared memory address space) are not currently exposed in the rust language. But kernels written in rust can compile to ptx; you’ll still need to write glue code.

Due to the complexity involved, Cerebras is not only designing the chip, but they also must design the full system. ... The WSE will come in 15U units with a chassis for the WSE and another one for the power and miscellaneous components. The final product is intended to act like any other network-attached accelerator over a 100 GbE.

So it's NIC bandwidth bottlenecked. Though 100 GbE is in the same ballpark as PCIe 3, but last I heard 40-100 GbE were pretty CPU-intensive compared to alternatives.

Cool to see this on HN. I briefly worked there on a closely related project during high school after this paper was published. It was my first real experience doing wet lab work-- learned a bunch, met cool people, was fun. (Also did a lot of pipetting and PCR.)

To expand a bit, as I understand it, Remora gives a type system (and type inference) to APL- and J-style reranking, which is called rank polymorphism in Remora. The key thing is that type inference in Remora is based on Presburger arithmetic (0,+) which is decidable, unlike the stronger but overly powerful (for their purposes) than full Peano arithmetic (0,1,+,*).

Have you looked into SageMath? (Technically it's "Python-based" rather than "just" Python.) I'm also curious if you're specifically looking for something in Python, or if doing symbolic computation/computer algebra in other languages would work for you, barring license costs.

Pratt parsing is great. Quoting from the original paper itself:

One may wonder why such an "obviously" utopian approach has not been generally adopted already. I suspect the root cause ... is our universal preoccupation with BNF grammars and their various offspring...

If you have an assembler or C compiler you can implement matrix multiplication (GEMM) which usually does most of the heavy lifting in your neural net. Now you correctly alluded that it may not be simple to efficiently implement GEMM but if you have a simple architecture without a complex memory hierarchy then using whatever SIMD facilities are available and some standard tricks will get you in ballpark of peak FLOP/s.

Or, just download a fast BLAS from your hardware vendor...

I'm curious if you have a particular language/microcontroller/microwave/badger you have in mind? Depending on which, YMMV.

I'm not sure that there's a mature Rust alternative to "all of the above" quite yet. Some things that I've had to build for my own work (not always "built," sometimes I just wrote FFI bindings) include:

* N-D dense arrays, fashionably simply called tensors these days ;) (this I wrote from scratch to suit my own needs, but there are several implementations of this in Rust, as well as in C++)

* linear algebra (bindings to BLAS, LAPACK etc.)

* numerical integration (bindings to GSL or QUADPACK)

* optimization and machine learning (this I work on day-to-day)

* neural networks (I also work on this)

* multicore/manycore/GPU/distributed support (and this)

There's also the more practical aspects of using Pandas/iPython (Jupyter)/Spark for data science, including ETL, interactive work, and plotting, which IMO are not quite there yet in the Rust ecosystem. But I think that a lot of the pieces are there, e.g. bleeding fast CSV parsing libraries (https://github.com/BurntSushi/rust-csv), and what's left is the important last mile of bringing these things together in ergonomic libraries or frameworks.

Rust has been pretty critical to me for getting my work up and running with minimal debugging (I'm in CS grad school, working on deep learning and optimization). I'm super productive programming in Rust, which is also generally a pleasure to write in.

Just last week I had to land a pretty major refactoring (swapping out a single wrapper type for a differentiable "operator" with an implicit operator graph instead). It basically just worked out of the box as soon as I got it to compile. Definitely something to be said for working _with_ the compiler and its messages on moving, borrowing, mutability etc. (Incidentally, if I had to program exclusively in C++11/14, thanks to Rust I'd have become much better at programming in C++.)