a2ef5c2005d6

--- 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:
+
+    <sjl> Are there any thread safety guarantees for writing to separate elements of SIMPLE-ARRAYs?
+    <sjl> Example: I want to initialize a large (~30gb) array with random data (DNA bases) for testing purposes.
+    <sjl> 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.
+    <sjl> I'm guessing if I switched to something more compact like (SIMPLE-ARRAY (INTEGER 0 3) (*)) this would no longer Just Work™.
+    <sjl> 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?
+    <pkhuong> sjl: bytes and larger are safe.
+    <pkhuong> there is no guarantee
+    <pkhuong> except for the fact that it's implemented that way
+    <pkhuong> threading is outside the spec. developing a formal memory model is expensive.
+    <sjl> Yeah
+    <sjl> It seems unlikely that "bytes and larger are safe" would stop being true in the future, right?
+    <pkhuong> correct.
+    <sjl> I think I can live with that.
+    <sjl> Thanks.
+    <pkhuong> don't run on itanium. I'd double check the disassembly on ARM.
+    <sjl> Ah, not using either at the moment, but good to know.