01:55:24 -!- christoph_debian [~user@2001:a60:f01c:0:42::1] has quit [Remote host closed the connection] 02:19:27 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 02:45:00 LiamH [~none@96.231.220.53] has joined #sbcl 02:51:13 sw2wolf [~czsq888@118.112.70.134] has joined #sbcl 03:00:35 -!- sw2wolf [~czsq888@118.112.70.134] has left #sbcl 03:02:31 kanru`` [~kanru@118-163-10-190.hinet-ip.hinet.net] has joined #sbcl 03:18:47 christoph_debian [~user@2001:a60:f01c:0:42::1] has joined #sbcl 03:26:21 -!- wbooze [~wbooze@xdsl-78-35-134-140.netcologne.de] has quit [Ping timeout: 276 seconds] 04:18:41 -!- LiamH [~none@96.231.220.53] has quit [Quit: Leaving.] 04:22:36 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 04:27:56 why can't sbcl avoid runtime dispatch for (VECTOR FIXNUM) ? 04:32:49 Qworkescence: not a simple-array. 04:33:05 why does it need to be a simple-array 04:33:23 are expressly adjustable arrays forever hairy in SBCL? 04:33:24 Because complex arrays are more complicated. 04:34:27 Yeah, we could try to inline the code for adjustable arrays, but I think there are type system issues for now. 04:34:37 :( 04:47:51 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Read error: Operation timed out] 05:23:58 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 07:35:09 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 07:39:17 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 07:51:33 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 08:03:26 jdz [~jdz@85.254.212.34] has joined #sbcl 08:59:52 -!- kanru`` [~kanru@118-163-10-190.hinet-ip.hinet.net] has quit [Ping timeout: 272 seconds] 09:30:57 prxq [~mommer@mnhm-4d013270.pool.mediaWays.net] has joined #sbcl 10:13:17 -!- Fare [~fare@c-68-81-138-209.hsd1.pa.comcast.net] has quit [Quit: Leaving] 10:45:27 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 10:46:20 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 10:47:19 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 10:47:55 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 10:54:10 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 11:51:22 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 12:07:23 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 12:13:38 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 12:24:25 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 12:35:25 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 13:19:24 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 13:58:05 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:19:48 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 14:24:19 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 265 seconds] 14:42:15 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 14:46:02 wbooze [~wbooze@78.35.175.143] has joined #sbcl 14:51:15 Thra11 [~thrall@87.112.247.54] has joined #sbcl 15:01:01 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 15:08:04 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 15:17:00 lichtblau: I guess you would have the best handle on this, so: do you think it'd be possible trigger GCs while allocating an object, rather than waiting for the end of the PA region? 15:55:08 slyrus [~chatzilla@97-122-255-171.hlrn.qwest.net] has joined #sbcl 16:08:13 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 16:12:42 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 264 seconds] 16:40:07 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 16:49:23 so we shipped 1.1.3 with the sb-sprof test failure on darwin? sorry I've been unavailable to help here. 16:52:06 not that I even looked at the thing either. 16:54:27 think of it as a christmas present to all OS X users 16:57:03 so... only make-array (and maybe allocate-code-object) can really cons at such coarse granularity that GCing before allocation is useful. 17:12:13 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Quit: Leaving.] 17:24:07 -!- Thra11 [~thrall@87.112.247.54] has quit [Remote host closed the connection] 17:27:48 Thra11 [~thrall@54.247.112.87.dyn.plus.net] has joined #sbcl 17:28:40 first, waste time at the bank, then I think I see how to do this. 17:30:39 also, can someone confirm that allocating unboxed arrays in the unboxed region is useless? Either it's a large object, in which case it'll be handled in-place, or it's a small one, and it'll be copied to an unboxed region if still live. 17:35:54 -!- slyrus [~chatzilla@97-122-255-171.hlrn.qwest.net] has quit [Ping timeout: 276 seconds] 18:12:24 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 18:16:53 -!- tcr [~tcr@88-134-109-42-dynip.superkabel.de] has quit [Ping timeout: 255 seconds] 18:29:01 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 18:51:36 tcr [~tcr@88-134-109-42-dynip.superkabel.de] has joined #sbcl 19:38:25 huangjs [~huangjs@69.84.244.131] has joined #sbcl 19:39:28 snowylike [~sn@91-67-171-156-dynip.superkabel.de] has joined #sbcl 20:43:58 Should I be worried about "STYLE-WARNING: Undefined alien: "pthread_kill""? 20:57:10 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:57:20 pkhuong: where is that? 20:57:38 sb-sprof? 21:00:52 stassats`: yup. 21:01:43 is that a non-sb-thread build? 21:01:54 oh, right, duh. 21:02:38 well, that define-alien-routine could be #+sb-threaded too 21:18:03 https://github.com/pkhuong/sbcl/tree/cleverer-array-alloc <- two-step allocation for vectors 21:18:16 first only allocates if it doesn't trigger a GC. 21:18:52 A function called via ~// doesn't seem to get inlined despite an inline declamation. 21:19:24 if a GC is triggered, we leave PA, handle pending interrupts, and then alloc for real. 21:20:06 we're breaking PA invariants, but it's fine for pretty much all allocation sequences! 21:39:19 pkhuong: what is a PA invariant? 21:41:14 pseudo-atomic invariants. We'll handle interrupts, but only to note that they should be handled as soon as we leave the PA region 21:41:49 PA regions protect non-reentrant or GC-unsafe code. 21:52:46 sdemarre [~serge@198.184-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 21:53:06 -!- sdemarre [~serge@198.184-64-87.adsl-dyn.isp.belgacom.be] has quit [Client Quit] 22:09:16 pkhuong: ok, thanks. I gather your changes will make sbcl faster? 22:09:38 array allocation, I mean 22:12:20 prxq: no, less crashy, hopefully. 22:12:55 gencgc has a ton of timing issues because we don't GC during/before allocation 22:13:20 We can only trigger a GC after allocation has succeeded. If we don't have enough free space, we throw a heap exhaustion error. 22:13:59 That's incredibly silly, and it should be more robust to simply be able to trigger a GC instead of failing to allocate. 22:16:40 -!- hydan [~user@ip-89-102-13-27.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 22:19:22 ah ok 22:20:46 that sounds indeed like a serious improvement. I presume one can also try to signal an error instead of dropping into ldb 22:21:09 significant, I mean 22:21:34 that's already the case. 22:21:41 ldb only happens when we run out of heap while GCing. 22:21:45 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 22:22:07 The "easy" way to fix this is to always leave half the heap unused. 22:22:32 it also seems silly that it's so easy to run out of heap while GCing. 22:22:37 A GC-bound test case also shows a speed-up from 26 sec in GC to 20, but I don't think it's representative of anything 22:23:30 foom: well, lichtblau and I agree that TRT would be to have a copying GC for the nursery and mark/sweep for the rest (as a single generation, most likely), but that's not gonna happen for a long while. 22:23:54 You ought only need a couple pages free to guarantee ability to complete a GC. 22:25:01 huangjs [~huangjs@69.84.244.131] has joined #sbcl 22:28:09 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:39:09 -!- prxq [~mommer@mnhm-4d013270.pool.mediaWays.net] has quit [Quit: Leaving] 22:44:07 -!- huangjs [~huangjs@69.84.244.131] has quit [Quit: This computer has gone to sleep] 22:53:22 that's for a marking GCs. Making that work for cheney is harder 22:55:06 slyrus [~chatzilla@97-122-255-171.hlrn.qwest.net] has joined #sbcl 23:19:21 -!- slyrus [~chatzilla@97-122-255-171.hlrn.qwest.net] has quit [Ping timeout: 255 seconds] 23:23:53 danlentz [~danlentz@2601:c:3680:1c:140e:ddf3:838c:1ad0] has joined #sbcl 23:26:16 -!- wbooze [~wbooze@78.35.175.143] has quit [Ping timeout: 272 seconds] 23:33:37 -!- danlentz [~danlentz@2601:c:3680:1c:140e:ddf3:838c:1ad0] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 23:39:39 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:45:31 huangjs [~huangjs@69.84.244.131] has joined #sbcl 23:47:42 psilord1 [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:54:57 -!- snowylike [~sn@91-67-171-156-dynip.superkabel.de] has quit [Quit: Nettalk6 - www.ntalk.de]