15:26:03 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 15:26:03 15:26:03 -!- names: ccl-logbot homie cmm loke gor[e] rootzlevel @nikodemus hlavaty @Krystof flip214 _8david antoszka fe[nl]ix chemuduguntar antgreen peddie Phoodus rpg jiacobucci redline6561 tWip slyrus pchrist tsuru scymtym joshe luis christoph_debian specbot pp206 foom ASau lisppaste2 |3b| jsnell pkhuong @Xof mtd deepfire antifuchs 15:28:08 _8david: i'm pretty sure we already rely on that happening 15:28:34 (the blocked signal being delivered after return from handler) 15:29:12 _8david: but rt signals have proven problematic because there is a global queue -- if it gets fill, rt signals can be dropped 15:29:24 gets filled, even 15:30:13 my -- possibly mistaken -- recollection is that non-rt signals are reliable, rt signals get priority, but aren't quite reliable... 15:32:05 <_8david> | Lower number signals are given priority over higher number signals. In Linux this is true across the range of all signals, which incidentally gives the regular signals higher priority than all real-time signals (POSIX says that priority of real-time versus ordinary signals is unspecified, and only the realtime signals have a specified priority relative to each other). 15:33:39 how bad of a slowdown are we ready to take in the name of: non-atrocious performance in pathological cases 15:34:03 and future hack-friendliness to actually improve the code again? 15:38:59 pkhuong: fairly little, imo 15:39:50 <10%, <5%, < 3%? :) 15:41:22 I'm willing to see a 5% slowdown in compile-time for the common case if we then manage to scale with code size 15:41:58 if this slowdown comes with a promise that we can make (optimize compilation-speed) do something meaningful in the slowed down area, I might even accept 10% 15:43:57 I'll have to try for the latter, but I have a couple ideas. They'd still be doable with the current code, just hairier 15:44:24 hm. i wanted to push a branch on github for purposes of comparison, but i can't find it 15:45:32 but i'd say <10% for worst case, and <3% for the common case (incl. self build) 15:47:11 there's basically two issues with consets 15:47:46 but the constant factors are really getting in the way. 15:51:45 have you run the numbers on how conset sizes are distributed? 15:52:12 it's on my blog 15:52:24 mostly tiny, < 10-20 15:52:45 huh 15:53:14 http://www.pvk.ca/Blog/resources/sample-pop.png 15:53:46 huh 15:54:12 it turns out that it's the code to add indices to find-constraint that slows things down 15:54:26 doh 15:55:01 you add them for small ones too? 15:55:08 yeah. 15:55:18 I didn't want to have two code paths to debug and maintain 15:56:38 understandable, but sounds like a delaying the indexing would be a big win 15:56:53 i mean, even plain lists should do decently for <10-20 elements 15:57:10 we're using ssets as lists for find-constraint 16:02:33 https://github.com/nikodemus/SBCL/tree/wip-sset # for comparison 16:02:50 is that the patch on lp? 16:02:59 approximately 16:03:07 k. 16:03:27 it didn't apply for me, so i rolled that by hand 16:03:58 it also puts back *constraint-number* instead of *constraint-universe*, and doesn't touch globaldb 16:04:07 k. 16:04:14 and just uses sxhash for hashing sset-element-number 16:04:25 simpleminded in the extreme 16:12:01 pkhuong: do those sizes hold for ssets as well? 16:12:12 no. 16:12:18 well, I don't know. 16:14:17 -!- flip214 [~marek@unaffiliated/flip214] has quit [Quit: Leaving] 16:19:32 anyway. I think we have an n^4 somewhere in our big-oh for constraint.lisp ') 16:22:41 so... I went with you sset instead of the one on lp because the globaldb stuff seems to have some impact as well. 16:23:00 for self-build, there's no change 16:23:48 with the test cases on lp, linear probing and robin hood are better, but linear probing more so (factor of ~50% ish) 16:24:45 if I scale up some more, then robin hood becomes noticeably faster... 16:25:42 (~30%) 16:27:46 of course, playing with find-constraint just wipes the floor, regardless of the sset 16:29:46 oh. I know where that 50% factor comes from. 16:30:05 the robin hood tables are ~66% as dense as the linear probing 16:31:14 so find-constraint will be ~50% faster for linear probing. 16:48:01 just to be clear -- that's without the find-constaint smarts? 16:50:46 right. 16:51:06 I'm build a version with linear probing and indexed find constraints 16:52:40 -!- hlavaty [~user@91-65-223-81-dynip.superkabel.de] has quit [Read error: Operation timed out] 16:58:10 pdlogan [~patrick@174-25-37-137.ptld.qwest.net] has joined #sbcl 17:05:21 -!- cmm [~cmm@bzq-79-177-199-45.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 17:06:30 cmm [~cmm@bzq-79-177-199-45.red.bezeqint.net] has joined #sbcl 17:08:48 -!- gor[e] [~svr@gw2.masterhost.ru] has quit [Ping timeout: 252 seconds] 17:10:52 -!- cmm [~cmm@bzq-79-177-199-45.red.bezeqint.net] has quit [Ping timeout: 252 seconds] 17:11:57 cmm [~cmm@bzq-79-177-199-45.red.bezeqint.net] has joined #sbcl 17:17:14 daimrod [~daimrod@ANantes-556-1-154-251.w109-211.abo.wanadoo.fr] has joined #sbcl 17:18:33 rmarynch [~roman@88.135.194.233] has joined #sbcl 17:27:25 -!- cmm [~cmm@bzq-79-177-199-45.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 17:28:34 cmm [~cmm@bzq-79-177-199-45.red.bezeqint.net] has joined #sbcl 17:44:54 (zeroize zero) vs (inst xor zero zero) - are they equivalent? the first is in x86-64, the second in x86 17:46:06 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 255 seconds] 17:51:17 yes 17:51:56 except that zeroize tries to pick a shorter encoding when possible 17:53:29 which one should I keep as the universal for both backends? 17:55:15 zeroize 17:55:19 (I have started with merging, so I will ask about the not-sure things) 17:55:34 the definition should work out of the box for x86 as well 17:55:45 fine, will try that 18:00:30 -!- tsuru [~charlie@adsl-74-179-198-44.bna.bellsouth.net] has quit [Ping timeout: 255 seconds] 18:02:37 -!- daimrod [~daimrod@ANantes-556-1-154-251.w109-211.abo.wanadoo.fr] has quit [Quit: WeeChat 0.3.5] 18:05:35 rpg [~rpg@mpls.sift.info] has joined #sbcl 18:07:07 when merging, should I use #-x86-64 or #!-x86-64 (with "!" or not)? 18:09:02 ! almost certainly 18:10:04 #!+ and #!- refer to features of the sbcl being built, #+ and #- refers to features of the lisp doing the building 18:10:18 clear, thanks 18:17:43 -!- homie [~levent.gu@xdsl-78-35-153-133.netcologne.de] has quit [Remote host closed the connection] 18:18:45 homie [~levent.gu@xdsl-78-35-153-133.netcologne.de] has joined #sbcl 18:22:30 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Ping timeout: 258 seconds] 14:42:21 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 14:42:21 14:42:21 -!- names: ccl-logbot cmm @Krystof Xof_ @nikodemus slyrus homie christoph_debian hlavaty scymtym workthrick Quadrescence deepfire tWip foom redline6561_ tsuru |3b| jiacobucci _8david antoszka fe[nl]ix peddie joshe luis jsnell mtd antifuchs lisppaste2 pp206 specbot 14:47:45 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 14:54:00 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 244 seconds] 14:54:51 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 15:02:20 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 15:06:04 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Remote host closed the connection] 15:06:22 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 15:14:09 -!- tcr1 [~tcr@155-dom-3.acn.waw.pl] has quit [Quit: Leaving.] 15:19:07 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 250 seconds] 15:19:58 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 15:37:18 pdlogan [~patrick@174-25-37-137.ptld.qwest.net] has joined #sbcl 15:39:50 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 258 seconds] 15:40:46 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 15:47:58 loke [~elias@bb121-6-70-100.singnet.com.sg] has joined #sbcl 15:52:12 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 15:52:30 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 252 seconds] 15:53:16 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 16:17:22 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 16:29:38 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 258 seconds] 16:30:18 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 17:00:20 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 246 seconds] 17:01:15 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 17:10:55 daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has joined #sbcl 17:21:02 -!- Krystof [~csr21@158.223.51.76] has quit [Ping timeout: 258 seconds] 17:25:55 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 17:59:33 -!- hlavaty [~user@91-65-223-81-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 18:01:53 -!- daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has quit [Quit: WeeChat 0.3.5] 18:06:33 prxq [~mommer@mnhm-590c15b5.pool.mediaWays.net] has joined #sbcl 18:14:12 -!- pdlogan [~patrick@174-25-37-137.ptld.qwest.net] has left #sbcl 18:34:37 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 244 seconds] 18:35:51 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 18:39:02 -!- tcr1 [~tcr@155-dom-3.acn.waw.pl] has quit [Quit: Leaving.] 18:49:09 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Ping timeout: 258 seconds] 18:53:33 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 18:54:33 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 18:54:51 -!- homie [~levgue@xdsl-84-44-211-78.netcologne.de] has quit [Ping timeout: 276 seconds] 18:57:50 homie [~levgue@xdsl-78-35-160-31.netcologne.de] has joined #sbcl 18:58:08 Krystof [~csr21@csrhodes.plus.com] has joined #sbcl 18:58:08 -!- ChanServ has set mode +o Krystof 19:03:11 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 246 seconds] 19:04:10 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 19:07:12 slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl 20:12:47 antgreen` [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 20:13:52 -!- antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has quit [Ping timeout: 252 seconds] 20:17:02 so, I ran a microbenchmark on my laptop, and it looks like a sofware write barrier might not be too much of a performance degradation 20:17:12 or even improve perf. 20:18:52 this is on os x, with awful syscalls and OS in general, but: 20:20:06 I'd believe that. But running the same microbenchmark on linux might be a good idea. :) 20:20:19 filling a simple vector of 2^19 element is 2.5 M cycles without interference 20:20:35 trigger the write barriers, and it goes to 75M cycles 20:21:16 a sequential store buffer costs us an extra 8M cycles. 20:22:06 we need an average of 9 writes per word per GC (for each written page) for mprotect to break even... 20:23:04 Hrm. In this benchmark, you actually write to every word in the page 20:23:11 linux is much better, but I don't know that it's more than 10 times faster (we'll see as soon as I get off the bus) 20:23:18 Which is unusual in real code, I suspect 20:23:19 yeah, that's a best case for mprotect. 20:23:28 right 20:23:50 I know linux has a very fast pagefault codepath into kernelspace 20:23:52 and even then, it's unlikely for mprotect to be worth it 20:23:55 something like 2000 cycles 20:24:16 (that's "very fast" for an interrupt) 20:24:24 yeah, going through fork for cow and write tracking was something like 5-10x fsster than mprotect, iirc. 20:25:07 the isue is that our mprotect scheme has to ping pong between kernel and user space for logging and mprotect. 20:25:15 right 20:25:24 if we had kernel-side dirty bits... 20:25:26 like windows. :) 20:25:34 or slowlaris 20:25:47 well, we can fake dirty bits with fork, actually. 20:26:19 fork, compare page maps. the in-kerenel memcpy was still faster than mprotect in the segv handler. 20:26:34 compare page maps how? 20:27:27 procfs gives us a mapping from virtual page to real page descriptor, to better understand sharing and what not 20:28:19 ASau [~user@89-178-253-73.broadband.corbina.ru] has joined #sbcl 20:30:24 second order effects like flushing the TLBs are harder to measure, even though they exist. a TLB miss is easily 2-3 hundred cycles. 22:11:37 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 22:12:46 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 22:29:40 -!- prxq [~mommer@mnhm-590c15b5.pool.mediaWays.net] has quit [Quit: Leaving] 23:00:57 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 23:27:35 -!- tcr1 [~tcr@155-dom-3.acn.waw.pl] has quit [Quit: Leaving.] 00:34:14 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Remote host closed the connection] 00:34:32 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 02:19:23 much more sane on linux 02:20:05 1.4 M cycles for the best case, add 4.2M in case of write protection, and 6.5 M for soft barriers (i can get that down to ~5.5 M with mapping trickery, but I don't know that it's worth the trouble) 02:27:13 the mapping trick is interesting, though, because the code sequence it tiny: xadd/mov. 02:37:13 well, 3 instruction: mov tmp, 16/xadd/mov :) 02:43:26 so, fork tricks is about the same as a s/w write barrier 02:56:33 so on linux, sw barrier is actually slower than current code? 02:57:09 [under best case scenario for write prot code, noted] 02:57:12 right. 02:58:32 and the fork trick isn't that interesting on linux, except that it gives us more information than pure card marking 02:58:51 what's the mapping trickery of which you speak? 03:00:02 I went with sequential store buffers 03:00:36 (because card marking doesn't seem that attractive if we're trying to get away from magic addresses) 03:01:43 are we really trying to get away from magic addresses? 03:01:45 so, keep a write-protected page at the end of the buffer. 03:02:56 when you hit the write protected page, reset the free-record pointer to the beginning of the buffer, unprotect the page, and protect the new end of the buffer (1 page below or above, for instance). 03:04:04 well, one page below; we can't reset the free pointer if we go for one page above. 03:05:54 but it's a lot of complexity. Just making sure there's enough work between the cmp and the jcc for the range check (in this case, write to the buffer and update the free pointer) is pretty good already. 03:07:01 I'm not convinced about a SSB at all; obviously if you only touch every word once there's no problem, but if you hit the same memory a lot, that's a lot of duplicate work on the GC side compared to card marking. 03:07:47 but that part is trivially parallelisable, and can be converted to card marking or what not on the slow path. 03:08:22 Sure, you can convert SSB->cards on SSB overflow or something like that. 03:08:26 right. 03:08:34 But don't card marking code sequences also only take 2-3 insns? 03:09:21 the shift is surprisingly expensive. 03:09:29 what CPU? 03:09:30 but yeah, shift, mov. 03:09:35 P4 and later. 03:09:43 P4 had the worst shift 03:09:50 the later ones are a lot better. 03:10:21 but yeah, it'd be something like shift, load card base, mov 03:10:35 (no, I'm not dedicating a register to card marking ;) 03:11:41 but that will totally die if people play tricks with the foreign heap. 03:13:20 what, you don't want to allocate 128PB of memory for the cards? :) 03:13:21 card marking also multiplies badness for random accesses. 03:14:47 yea, okay, you're right: straight up card marking is infeasible with a 64bit address space where you don't know what addrs people will be writing to. 03:15:10 you can assume sanity, though. 03:16:32 I think you've changed my mind. I don't like straight up card marking anymore. :) 03:16:33 If we go for write barriers only for remembered sets, card marking is fine as long as you don't store pointers to the lisp heap in the foreign heap. 03:17:53 ok, what sort of awful madness does ITA do? :p 03:19:53 re write barriers only for remembered sets, I don't think it's the right way to do it: heaps are getting larger, and we want to avoid major collections as much as possible. If we can track *all* writes to potential pointers, that lets us act when references disappear as well, and move closer to refcounting. 03:25:42 right. SSB might make things easier for a concurrent collector, too? 03:26:34 it definitely helps with keeping as much state as possible thread-local. 03:41:48 tells us that the difference between card marking and SSB is often negligible. 03:42:01 but they consider conditional write barriers 03:43:22 wow, clicking "Open Link in Browser" opened evince, which told me that "The specified location is not mounted." 03:43:30 thanks. 03:43:35 stupid linux desktop. :P 06:32:03 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Remote host closed the connection] 06:56:18 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 07:07:55 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 260 seconds] 07:08:25 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 07:09:33 -!- tcr1 [~tcr@155-dom-3.acn.waw.pl] has quit [Quit: Leaving.] 07:15:18 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 07:20:09 homie` [~levgue@xdsl-78-35-137-191.netcologne.de] has joined #sbcl 07:22:51 -!- homie [~levgue@xdsl-78-35-160-31.netcologne.de] has quit [Ping timeout: 250 seconds] 08:10:58 daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has joined #sbcl 08:12:29 -!- daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has quit [Client Quit] 08:12:56 daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has joined #sbcl 08:53:17 hlavaty [~user@91-65-223-81-dynip.superkabel.de] has joined #sbcl 09:20:24 -!- homie` [~levgue@xdsl-78-35-137-191.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 09:24:12 homie [~levgue@xdsl-78-35-137-191.netcologne.de] has joined #sbcl 09:27:08 misterncw [~misterncw@82.71.241.25] has joined #sbcl 09:32:38 -!- daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has quit [Quit: WeeChat 0.3.5] 09:45:41 attila_lendvai [~attila_le@catv-89-132-189-7.catv.broadband.hu] has joined #sbcl 09:45:41 -!- attila_lendvai [~attila_le@catv-89-132-189-7.catv.broadband.hu] has quit [Changing host] 09:45:41 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:44:20 -!- mtd [~martin@chop.xades.com] has quit [Ping timeout: 260 seconds] 10:44:36 mtd [~martin@chop.xades.com] has joined #sbcl 10:46:25 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 246 seconds] 10:47:21 -!- misterncw [~misterncw@82.71.241.25] has quit [Remote host closed the connection] 10:47:30 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 10:50:23 misterncw [~misterncw@82.71.241.25] has joined #sbcl 11:01:42 -!- misterncw [~misterncw@82.71.241.25] has quit [Remote host closed the connection] 11:03:09 misterncw [~misterncw@82.71.241.25] has joined #sbcl 11:13:32 -!- misterncw [~misterncw@82.71.241.25] has quit [Read error: Connection reset by peer] 11:13:37 misterncw [~misterncw@82.71.241.25] has joined #sbcl 11:23:00 misternc_ [~misterncw@82.71.241.25] has joined #sbcl 11:24:57 -!- misterncw [~misterncw@82.71.241.25] has quit [Ping timeout: 255 seconds] 11:53:28 -!- misternc_ [~misterncw@82.71.241.25] has quit [Remote host closed the connection] 11:54:05 -!- tcr1 [~tcr@155-dom-3.acn.waw.pl] has quit [Quit: Leaving.] 12:33:58 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 258 seconds] 12:34:45 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 12:47:22 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 240 seconds] 12:48:22 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 12:51:45 -!- tsuru [~charlie@adsl-74-179-25-40.bna.bellsouth.net] has quit [Ping timeout: 250 seconds] 12:54:37 daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has joined #sbcl 12:54:54 -!- daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has quit [Client Quit] 12:56:07 daimrod [~daimrod@ANantes-556-1-326-23.w90-59.abo.wanadoo.fr] has joined #sbcl 13:24:15 -!- cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has quit [Ping timeout: 246 seconds] 13:25:27 cmm [~cmm@bzq-79-177-212-194.red.bezeqint.net] has joined #sbcl 13:48:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 13:50:22 tsuru [~user@c-68-53-57-241.hsd1.tn.comcast.net] has joined #sbcl 13:54:17 -!- antgreen` [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 14:03:14 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 14:19:35 stassats [~stassats@pppoe.178-66-54-180.dynamic.avangarddsl.ru] has joined #sbcl 14:19:39 -!- stassats [~stassats@pppoe.178-66-54-180.dynamic.avangarddsl.ru] has quit [Changing host] 14:19:39 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:35:34 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 14:37:58 where is the stable branch of sbcl located at ? 14:38:11 master ? 14:38:37 there's no stable branch 14:38:51 ok which one is the recommended one then ? 14:38:59 master 14:39:05 ok thank you 14:39:17 well, actually, it's recommended to use releases 14:39:35 they're supposedly stable (but where's fun in that?) 14:40:24 hmm, ok what does tracked branches in git mean, do they get into my master checkout ? 14:40:57 or is that only history ? 14:42:06 when you clone, it makes branches called "origin/" 14:42:19 those are the tracked branches 14:42:48 when you make your own branch (e.g. "master") it tracks "origin/master" 14:43:17 so the diffs are made against that one ok 14:43:23 can i manually promote objects into older gc generations? 14:43:37 stassats: you can promote *all* live objects 14:43:51 foom: how? 14:43:51 (sb-ext:gc :gen N) 14:46:01 well, i allocate many objects which will stay indefinitely, i don't think calling GC on all generations after each object is allocated will be reasonable 14:46:40 what kind of objects are they? 14:46:47 clos instances 14:47:12 never mind then. Do you allocate those in batch, e.g. at the beginning of the program? 14:47:21 yes 14:47:25 you could save a core that has all the objects in it 14:47:43 it's a persistence layer, so that's not really an option 14:47:44 then you can promote all live objects once you're done allocating them. 14:48:23 let me try that 14:50:36 well, it's quite slow, i assume it scans all the heap when doing (sb-ext:gc :gen 6), i assume that if i could tell it to scan only those objects it'll be faster 14:53:46 unfortunately, the design of gengc doesn't really work well with large remembered sets 14:54:53 old pages that may point to new ones are just scavenged at each gc. It's not clear to me that hacking things to promote only these objects would be much better. 14:55:43 alright then, i'm just exploring microoptimization paths, and GC takes 40% time and i produce only live objects 14:55:52 GC less. 14:56:28 i can increase sb-ext:bytes-consed-between-gcs, but it'll just shift those times, won't it? 14:57:05 no. If it performs GCs less often, it won't spend as much time in GC. 14:57:22 it's generational! 14:57:55 Then again, if your program doesn't fit the weak generationality hypothesis that young objects die at a significantly higher rate than old ones, then you could also reduce the number of generations 14:58:45 and basically end up with a two-space collector, if only, e.g., at the beginning of your program. 14:59:11 doubling bytes-consed-between-gcs decreased overall time 14:59:45 our GC costs are proportional to the live data in the GCed generation. 15:00:12 If your stuff is always live, the generationality hurts. 15:01:31 so, if i know how much i will allocate, do (sb-ext:gc) increase bytes-consed to that amount, allocate objects, do (sb-ext:gc), reset bytes-consed, it'll be better? 15:02:04 sure. 15:02:17 i'll try that 15:02:26 Make sure you have enough space for the copying collection. 15:03:05 in the heap? 15:03:18 right. 15:03:49 it's currently in the order of tens of megabytes, so won't be a problem 15:04:04 you could just disable the GC then ;) 15:05:03 but i guess some limit will on how much to increase bytes-consed will be reasonable if i were to scale on to more objects 15:05:23 half the available heap. 15:06:29 right, and about disabling GC, it's a long-living image, but the operation of creating objects may be done multiply times, that's why it may be feasible to optimize it 15:08:47 but even if it's done just one time, the rest of the system may allocate arbitrarily, so again disabling the GC isn't feasible 15:19:54 hm, maybe i misunderstood how without-gcing could be used in this case 15:20:51 increasing bytes-consed-between-gcs will increase it for other threads too? but if another thread is triggering gc, it'll wait until without-gcing is finished, right? 15:28:32 right 15:29:45 ok. So, it turns out that, in my loop, the overhead did not come from the instrumentation per se 15:30:11 but from the additional bandwidth usage from the SSB 15:42:08 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 15:48:06 When breaking into the debugger (because of an error being thrown) in SLIME, is there a way I can jump to the source code for a specific stack frame? I haven't been able to find any feature in SLIME that would make that possible, and the SOURCE command from within the debugger doesn't seem to provide me with a location reference (and most of the times it doesn't give me anything). Am I searching in vain? 15:50:04 loke: press v 15:50:25 woohoo 15:50:29 how could I have missed that one? 15:51:24 and it's not really an #sbcl question 15:52:08 stassats: True, but I had been trying to get the SOURCE command to work properly in SBCL, and I kept getting messages like "no source information" or something like that. 15:52:43 However, that happened in the office, and I never tried it at home yet. I just assumed it was an SBCL issue. 15:53:38 or maybe something's wrong with your office 15:53:45 COuld be 15:53:51 I'll check when I get back there tomorrow 15:54:17 I'm running the same version of SBCL though, although the office runs Redhat and I'm using Ubuntu at home, the rest should eb the same 15:54:22 Oh well. 15:54:32 if you want good debugging info, compile your code with debug 2 15:54:51 I put debug 3, is it better? :-) 15:54:57 it's worse 15:55:05 how could it be? 15:55:18 too much debugging 15:55:44 well, for specifically debugging it may be good, but i always use debug 2 15:56:14 even when not debugging 15:56:32 What's the best way to set a specific debug option by default, but to be able to reduce debug level for production? I've seen code use something like (declaim #.foo) 15:57:17 (sb-ext:restrict-compiler-policy 'debug 2) 15:57:39 i have it in my sbclrc 16:02:21 -!- tcr1 [~tcr@155-dom-3.acn.waw.pl] has quit [Ping timeout: 240 seconds] 16:02:44 tcr1 [~tcr@155-dom-3.acn.waw.pl] has joined #sbcl 16:09:26 which is the primary url for sbcl ? 16:09:26 pdlogan [~patrick@174-25-37-137.ptld.qwest.net] has joined #sbcl 16:09:41 for git and/or cvs checkouts i mean 16:10:14 i got the sourceforge repo (master) 16:10:25 but it fails on some thread stuff... 16:16:19 did you build it with threads? 16:16:55 are you on linux? 16:17:33 yes and yes 16:17:45 then how does it fail? 16:18:22 wait i'll just run the tests again and paste it somewhere (the last lines i mean) 16:19:06 expected failures are expected. 16:19:52 hmm, ok i'll look it up if it was indeed expected 16:26:44 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 16:26:44 -!- ChanServ has set mode +o nikodemus 16:28:13 so, I think I can get soft write barriers to something like mprotect tricks. 16:29:36 but first, off to the mall ;) 22:34:04 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 22:34:04 22:34:04 -!- names: ccl-logbot ignis_ pchrist tunes tsuru pdlogan christoph_debian deepfire cmm scymtym luis hargettp_ loke peddie fe[nl]ix ASau cow-orker pkhuong mtd Xof_ slyrus Quadrescence tWip foom redline6561_ |3b| jiacobucci _8david antoszka joshe pp206 jsnell antifuchs lisppaste2 23:16:27 hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has joined #sbcl 23:29:10 -!- pdlogan [~patrick@174-25-37-137.ptld.qwest.net] has left #sbcl 03:19:07 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 03:19:07 03:19:07 -!- names: ccl-logbot rpg ignis_ pchrist tsuru christoph_debian deepfire cmm scymtym luis hargettp_ loke peddie fe[nl]ix ASau cow-orker pkhuong mtd Xof_ slyrus Quadrescence tWip foom redline6561_ |3b| jiacobucci _8david antoszka joshe pp206 lisppaste2 jsnell antifuchs 03:57:14 -!- ignis_ [~quassel@12.50.98.2] has quit [Ping timeout: 250 seconds] 04:32:51 tcr1 [~tcr@80-218-247-218.dclient.hispeed.ch] has joined #sbcl 05:28:33 -!- tcr1 [~tcr@80-218-247-218.dclient.hispeed.ch] has quit [Ping timeout: 255 seconds] 05:47:11 flip214 [~marek@2001:858:107:1:7a2b:cbff:fed0:c11c] has joined #sbcl 05:47:11 -!- flip214 [~marek@2001:858:107:1:7a2b:cbff:fed0:c11c] has quit [Changing host] 05:47:11 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 05:51:48 -!- cmm [~cmm@109.65.214.78] has quit [Ping timeout: 276 seconds] 05:52:33 cmm [~cmm@109.65.214.78] has joined #sbcl 06:46:40 gor[e] [~svr@gw2.masterhost.ru] has joined #sbcl 07:45:24 hlavaty [~user@91-65-223-81-dynip.superkabel.de] has joined #sbcl 08:16:01 tcr1 [~tcr@217-162-207-189.dynamic.hispeed.ch] has joined #sbcl 09:13:48 hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has joined #sbcl 09:41:10 -!- hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has quit [Quit: Leaving...] 09:44:12 hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has joined #sbcl 11:32:43 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Remote host closed the connection] 11:48:28 -!- hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has quit [Quit: Leaving...] 11:51:14 ignis_ [~quassel@12.50.98.2] has joined #sbcl 11:51:47 -!- ignis_ [~quassel@12.50.98.2] has quit [Client Quit] 12:15:13 -!- peddie [~peddie@repl.esden.net] has quit [Ping timeout: 246 seconds] 12:16:41 peddie [~peddie@repl.esden.net] has joined #sbcl 12:17:03 -!- jsnell [~jsnell@178.63.66.6] has quit [Remote host closed the connection] 12:17:08 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 12:19:02 -!- tWip [u258@gateway/web/irccloud.com/x-sggvdvowstlusmcb] has quit [Ping timeout: 250 seconds] 12:25:11 tWip [u258@gateway/web/irccloud.com/x-ixkoqootltxzwqcm] has joined #sbcl 12:45:35 -!- tWip [u258@gateway/web/irccloud.com/x-ixkoqootltxzwqcm] has quit [Remote host closed the connection] 13:04:06 Krystof [~csr21@host86-141-133-140.range86-141.btcentralplus.com] has joined #sbcl 13:04:06 -!- ChanServ has set mode +o Krystof 13:11:31 tWip [u258@gateway/web/irccloud.com/x-pyecjtkwhbwpfiop] has joined #sbcl 13:12:21 -!- hargettp_ [~hargettp_@dhcp-161.mirrorimage.net] has left #sbcl 13:14:49 -!- gor[e] [~svr@gw2.masterhost.ru] has quit [Quit: leaving] 13:15:28 hargettp_ [~hargettp_@dhcp-161.mirrorimage.net] has joined #sbcl