00:07:43 -!- sellout [~Adium@75-25-126-88.lightspeed.sjcpca.sbcglobal.net] has quit [Read error: Connection reset by peer] 00:11:31 sellout42 [~Adium@75-25-126-88.lightspeed.sjcpca.sbcglobal.net] has joined #ccl 02:51:05 -!- rme [~rme@50.43.141.161] has quit [Quit: rme] 03:59:09 -!- DataLinkDroid [~DataLinkD@1.154.137.175] has quit [Quit: Bye] 04:37:53 DataLinkDroid [~DataLinkD@1.154.137.175] has joined #ccl 05:07:19 -!- |3b| [foobar@72.179.19.4] has quit [Ping timeout: 246 seconds] 05:18:06 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #ccl 06:47:50 -!- DataLinkDroid [~DataLinkD@1.154.137.175] has quit [Quit: Bye] 11:31:26 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Ping timeout: 248 seconds] 12:11:23 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 13:16:14 alms_ [~alms_@wrls-249-193-217.wrls-client.fas.harvard.edu] has joined #ccl 13:39:44 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 14:08:50 -!- alms_ [~alms_@wrls-249-193-217.wrls-client.fas.harvard.edu] has quit [Quit: alms_] 14:16:26 alms_ [~alms_@wrls-249-193-217.wrls-client.fas.harvard.edu] has joined #ccl 14:17:58 -!- alms_ [~alms_@wrls-249-193-217.wrls-client.fas.harvard.edu] has quit [Client Quit] 14:28:58 alms_ [~alms_@wrls-249-193-157.wrls-client.fas.harvard.edu] has joined #ccl 14:38:06 rme [~rme@50.43.140.70] has joined #ccl 14:42:57 -!- rme [rme@C721ACF9.2D6491A5.699BA7A6.IP] has quit [Ping timeout] 14:43:06 rme_ [~rme@50.43.147.80] has joined #ccl 14:44:42 -!- rme [~rme@50.43.140.70] has quit [Ping timeout: 276 seconds] 14:44:42 -!- rme_ is now known as rme 14:49:51 -!- rme [rme@F5BBBDA6.5174A474.699BA7A6.IP] has quit [Ping timeout] 14:50:46 rme_ [~rme@50.43.159.151] has joined #ccl 14:51:51 -!- rme [~rme@50.43.147.80] has quit [Ping timeout: 276 seconds] 14:51:51 -!- rme_ is now known as rme 14:57:39 rme_ [~rme@50.43.138.191] has joined #ccl 14:59:11 -!- rme [rme@9258F1F4.F0008889.699BA7A6.IP] has quit [Ping timeout] 14:59:13 -!- rme_ is now known as rme 14:59:39 -!- rme [~rme@50.43.159.151] has quit [Ping timeout: 276 seconds] 14:59:39 -!- rme_ is now known as rme 15:02:26 rme_ [~rme@50.43.140.95] has joined #ccl 15:02:42 -!- rme [rme@EF64A9C6.BBBE3EE8.699BA7A6.IP] has quit [Ping timeout] 15:03:53 -!- rme [~rme@50.43.138.191] has quit [Ping timeout: 245 seconds] 15:03:54 -!- rme_ is now known as rme 15:07:26 when ccl does a full gc, i know it moves conses around to sort of unfragment the heap -- does it try to do anything to keep "nearby" conses together, e.g., if X = (A . B), will A/B end up near X? Or is the resulting order just sort of random? 15:07:36 rme_ [~rme@50.43.142.89] has joined #ccl 15:07:55 -!- rme [rme@AECC0882.2D6491A5.699BA7A6.IP] has quit [Ping timeout] 15:07:55 -!- rme_ is now known as rme 15:08:16 The order is preserved. 15:08:59 -!- rme [~rme@50.43.140.95] has quit [Ping timeout: 260 seconds] 15:09:00 -!- rme_ is now known as rme 15:10:38 do you have any opinion about whether that's important, e.g., for preserving memory locality and keeping cache hit rates up? 15:10:58 It's too application dependent to say. 15:11:10 If it matters to your implementation, use vectors: then you will be able to manage locality. 15:11:35 right, i shoudl say i'm not hitting a performance problem 15:11:37 what i'm doing is.. 15:12:21 It can be. I learn new things all the time here. "Use vectors". Sounds laughable, but you wouldn't have just said some random half-right thing would you ? 15:12:45 we wrote a toy lisp with a very dumb GC algorithm that, after moving X, just puts A and B on the end of the working list 15:12:52 but this can end up making A/B be very far away from X 15:13:19 and we're wondering if this might be just a terrible idea 15:13:58 rme_ [~rme@50.43.176.222] has joined #ccl 15:13:59 we need to do some tests to see if that's what we're really hitting, but i figured maybe you guys had run into something like it before 15:14:59 -!- rme [rme@3EF2CFC9.F74FD1E8.699BA7A6.IP] has quit [Ping timeout] 15:15:35 Well, actually it may be a good thing that your data be separated too. (depending on your algorithms). See for example: http://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathological-case-for-caches/ 15:15:48 You may want your conses to be spread around randomly 15:15:52 The cases where other GC strategies can work better than CCL's involve destructive operations - X and Y are far apart in memory but (RPLACA X Y) occurs. Some GC strategies will reorder memory so that they wind up near each other and that can matter (if there are lots of Xs and Ys.) 15:16:16 Yep. Why get cache hits ? Silly machines with caches ... 15:16:33 -!- rme [~rme@50.43.142.89] has quit [Ping timeout: 276 seconds] 15:16:33 rme__ [~rme@50.43.150.61] has joined #ccl 15:16:50 -!- rme_ [rme@6D4E5FFD.B9DC2DEB.699BA7A6.IP] has quit [Ping timeout] 15:17:35 aha, so you don't reorder them in this rplacd/rplaca case, but instead sort of just shift everything downwards in address order to fill in the free spaces? 15:18:20 -!- rme_ [~rme@50.43.176.222] has quit [Ping timeout: 260 seconds] 15:18:39 Yes, it's an order-preserving in-place compaction. If X and Y survive lots of GCs they'll tend to get nearer to each other, but that isn't guaranteed. 15:18:44 i guess that seems easy to implement if you have separate mark and reorder phases 15:19:04 thanks, that makes sense 15:20:04 The GCs that I know of that do/have done things differently are generally 2-space copying GCs. 15:21:05 the one in our toy lisp is like that: divide the heap into two halves, then copy reachable stuff from one half to the other 15:21:30 which is also too bad because it's a lot of wasted space :) 15:22:07 The order in which you do the copying can matter: you copy a CONS to new space. Do you copy is CAR first, or its CDR ? 15:24:37 so there's a working list of visible conses 15:24:46 er 15:25:50 hrmn, from what magnus wrote, it sounds like he somehow copies X over first and then adds its CAR and CDR to the working list 15:25:57 i'm not sure quite exactly how that would work though 15:26:15 copying X before you copy its children, i mean 15:28:54 -!- rme__ [~rme@50.43.150.61] has quit [Ping timeout: 276 seconds] 15:29:08 About 20 years ago, I saw someone give a talk about the performance of general-purpose hardware vs lisp machines. Their conclusion was that the general-purpose hardware of the day was generally faster, but the LispM's GC got feedback about memory usage and could make better decisions about preserving locality. Long-running programs would become unusable on stock hardware but were still responsive on the lispms. 15:33:30 gbyers: http://www.managedruntime.org/ 15:35:02 if you can get the kernel patch to apply, compile and work properly 15:35:42 http://web.archive.org/web/20100405184808/http://blogs.azulsystems.com/cliff/2008/11/a-brief-conversation-with-david-moon.html 15:47:31 rme_ [~rme@50.43.134.54] has joined #ccl 15:47:50 -!- rme_ is now known as rme 16:26:07 -!- alms_ [~alms_@wrls-249-193-157.wrls-client.fas.harvard.edu] has quit [Quit: alms_] 16:32:46 alms_ [~alms_@wrls-249-196-62.wrls-client.fas.harvard.edu] has joined #ccl 17:21:33 -!- alms_ [~alms_@wrls-249-196-62.wrls-client.fas.harvard.edu] has quit [Quit: alms_] 17:29:26 alms_ [~alms_@wrls-249-197-33.wrls-client.fas.harvard.edu] has joined #ccl 19:10:31 -!- bzzbzz [~franco@modemcable151.155-57-74.mc.videotron.ca] has quit [Quit: leaving] 20:14:54 -!- sellout42 [~Adium@75-25-126-88.lightspeed.sjcpca.sbcglobal.net] has quit [Ping timeout: 276 seconds] 20:15:14 sellout42 [~Adium@75-25-126-88.lightspeed.sjcpca.sbcglobal.net] has joined #ccl 20:59:58 -!- alms_ [~alms_@wrls-249-197-33.wrls-client.fas.harvard.edu] has quit [Quit: alms_] 22:32:56 -!- sellout42 is now known as sellout 22:35:21 -!- kanru_ [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [Remote host closed the connection] 22:42:15 kanru_ [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #ccl 22:42:54 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 23:39:58 -!- rme_ [~rme@50.43.134.54] has quit [Quit: rme_] 23:52:00 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Ping timeout: 276 seconds]