1932812267

5 ms·

1.
by 1932812267 1y ago
One thing that's changed in the past decade is that college professors are now competing against youtube. There are really bad lecturers in college (and also really good ones!). But now, when you encounter a bad one, that's okay--
2.
by 1932812267 1y ago
I've seen the talk! The issue with using a global lock on a global work queue is that, unless the work items have drastically different compute times, there _will_ be high contention on the lock. I ran a benchmark [1], which shows that
3.
by 1932812267 1y ago
Clojure's loop/recur is specifically tail recursion like scala's tailrec or the optimization described in the blogpost. It doesn't use trampolines to enable tail calls that aren't tail recursion.
4.
by 1932812267 1y ago
This isn't a _general_ tail call optimization--just tail recursion. The issue is that this won't support mutual tail recursion. e.g.: (defun func-a (x) (func-b (- x 34)) (defun func-b (x) (cond ((<= 0 x) x)
5.
by 1932812267 1y ago
Scala has been using this technique for years with its scala.annotation.tailrec annotation. Regardless, it's cool to see this implemented as a bytecode pass.
6.
by 1932812267 1y ago
Sure! However, the work-stealing queue in rayon [1] uses three atomic operations instead of the two atomic operations for a mutex for a global lock. The difference, however, is the three atomic operations for the thread-local queue should b
7.
by 1932812267 1y ago
While it's true that par_iter() uses a concurrent data structure under the hood, it's specifically designed to use work-stealing to avoid needing threads to communicate. Why would putting a lock over a global workqueue be faster t
8.
by 1932812267 1y ago
I love your username, btw :)
9.
by 1932812267 1y ago
I've written a fair bit of SIMD code in Rust, and it definitely had lots of sore spots. The main advantage was that, because Rust doesn't use TBAA, it's completely legal (and safe, if you use bytemuck) to freely cast pointers