# HG changeset patch # User Steve Losh # Date 1550981712 18000 # Node ID a2ef5c2005d613daef1e55e27015467c655f70d3 # Parent fff81c4f00d4667747fac282bf7d73aff9536828 Update diff -r fff81c4f00d4 -r a2ef5c2005d6 README.markdown --- a/README.markdown Sat Feb 23 14:37:26 2019 -0500 +++ b/README.markdown Sat Feb 23 23:15:12 2019 -0500 @@ -224,3 +224,36 @@ [cl-netpbm](https://sjl.bitbucket.io/cl-netpbm/) and sent a request to get it into Quicklisp. The project backlog continues to shrink. +Started reading the Bioinformatics Algorithms book. Set up a new repo for it. +Did the first problem just to make sure all the pieces are hooked up. The first +problem is trivial to do serially. Dicked around with lparallel to exercise my +fancy machine a bit. Learned a few things: + +* You can give each lparallel worker thread its own thread-local bindings with + `:bindings '((*foo* . (form to eval) …))`. This is nice to give each thread + its own random number generator so they can work concurrently. +* Generating ~32gb of random DNA is a *lot* faster when you do it on 16 cores + instead of 1. +* Giving SBCL all of my 64gb of memory is a bad idea. It will try to use *all* + of it, and I usually have at least another few GB used, and the Linux OOM + killer does not fuck around. +* I need a better interface for cl-pcg. The current one blows. + +Asked #sbcl for clarification on a couple of things: + + Are there any thread safety guarantees for writing to separate elements of SIMPLE-ARRAYs? + Example: I want to initialize a large (~30gb) array with random data (DNA bases) for testing purposes. + If I make the array a (SIMPLE-ARRAY CHARACTER (*)) and initialize it using LPARALLEL:PDOTIMES to work in chunks, it appears to work fine, but I assume I can't rely on that behaviour. + I'm guessing if I switched to something more compact like (SIMPLE-ARRAY (INTEGER 0 3) (*)) this would no longer Just Work™. + Would I then need to use the CAS stuff to guarantee that one thread writing to (AREF FOO N) and another writing to (AREF FOO (1+ N)) don't step on each others' toes? + sjl: bytes and larger are safe. + there is no guarantee + except for the fact that it's implemented that way + threading is outside the spec. developing a formal memory model is expensive. + Yeah + It seems unlikely that "bytes and larger are safe" would stop being true in the future, right? + correct. + I think I can live with that. + Thanks. + don't run on itanium. I'd double check the disassembly on ARM. + Ah, not using either at the moment, but good to know.