3 ms·
I really liked Cliff Click's talk on why transactional memory didn't live up to it's promises (at least for accelerating general purpose locking of Java code no
by monocasa 5y ago
I really liked Cliff Click's talk on why transactional memory didn't live up to it's promises (at least for accelerating general purpose locking of Java code not written specifically for transactional memory).
Cliff Click — The Azul Hardware Transactional Memory experience
https://www.youtube.com/watch?v=GEkeOHw87Sg https://www.youtube.com/watch?v=GEkeOHw87Sg
TL;DW: Transactional memory sort of promised lock elision to speed up gratuitously lock heavy code, particularly for read heavy workloads. Think a caching hash map that only has the occasional writer. It didn't live up to that since the max transaction size is really easy to overflow (far easier than you may think), and general code has a nasty habit of writing metrics even in read cases which means that transactions all write to the same address, which means constant transaction conflicts, which means slower code than just using a lock. Cliff Click then makes the argument that the right move in the vast majority of cases if you're having lock contention is to rewrite the algorithm so that threads (or at least cores) communicate via messages and share nothing rather than trying to use transactional memory so that you can cleanly fork out across a cluster rather than being constrained to a single box still after the rewrite. And for context he comes to that conclusion while working on massive 768 core boxes where the value add is "we sell you a giant non-NUMA single box that absolutely eats Java for breakfast, lunch, and dinner".
Even if you read the TL;DW, I still encourage you to listen to his talk; he's an incredibly smart engineer and I learn something pretty much every time I listen to him.
- rayiner 5y agoCliff Click, aside from being a brilliant programmer, is a great technical communicator. He came out of a fantastic department at Rice that’s produced some of the most readable academic papers on compilers and VMs I’ve encountered.
- tptacek 5y agoOn this endorsement I watched the video upthread. I didn't care at all about HTM, but that was super interesting. If you've got more Click things to check out, I'll check 'em out.
- tjalfi 5y agoI'm also a fan of Cliff and other Rice alumni; here are a few of his videos that I like. [0] The Sea of Nodes and the HotSpot JIT [1] A JVM Does That? [2] A Crash Course in Modern Hardware [3] Bits of Advice for the VM Writer [0] https://www.youtube.com/watch?v=9epgZ-e6DUU https://www.youtube.com/watch?v=9epgZ-e6DUU [1] https://www.youtube.com/watch?v=-vizTDSz8NU https://www.youtube.com/watch?v=-vizTDSz8NU [2] https://www.youtube.com/watch?v=OFgxAFdxYAQ https://www.youtube.com/watch?v=OFgxAFdxYAQ [3] https://www.youtube.com/watch?v=Hqw57GJSrac https://www.youtube.com/watch?v=Hqw57GJSrac
- monocasa 5y agoIs there any chance you can point out some other Rice alumni that come to mind for their communication skills of engineering topics?
- rayiner 5y agoThere are some great, readable papers on compiler design from Keith Cooper, Ken Kennedy, and Linda Torczon's Compiler Group: https://www.cs.rice.edu/CS/compilers/index.html https://www.cs.rice.edu/CS/compilers/index.html. Preston Briggs came out of that group, and did his PhD thesis on register allocation via graph coloring, one of the early papers on that technique: https://www.cs.utexas.edu/users/mckinley/380C/lecs/briggs-thesis-1992.pdf https://www.cs.utexas.edu/users/mckinley/380C/lecs/briggs-th.... That's a great, very readable paper. Cooper & Simpson's paper on SCC-based value numbering is one of the more readable works on the subject: https://www.cs.rice.edu/~keith/Promo/CRPC-TR95636.pdf.gz https://www.cs.rice.edu/~keith/Promo/CRPC-TR95636.pdf.gz Vikram Adve worked there. He was the PhD advisor to Chris Lattner, who developed LLVM.