00:11:42 -!- asedeno [~asedeno@66.102.14.24] has quit [Remote host closed the connection] 00:15:18 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 00:18:01 asedeno [~asedeno@66.102.14.16] has joined #sbcl 00:22:00 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 00:49:53 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 00:51:33 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 01:12:43 fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has joined #sbcl 02:01:04 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Ping timeout: 240 seconds] 02:03:52 ltt_ [~ltt_@187.10.23.200] has joined #sbcl 02:06:00 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 02:13:40 ASau` [~user@p54AFEF5F.dip0.t-ipconnect.de] has joined #sbcl 02:16:24 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 252 seconds] 02:16:48 -!- ASau [~user@p54AFF3C7.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 03:20:16 -!- oleo [~oleo@xdsl-87-79-199-186.netcologne.de] has quit [Ping timeout: 264 seconds] 03:21:01 oleo [~oleo@xdsl-78-35-164-23.netcologne.de] has joined #sbcl 03:26:39 Bike_ [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 03:26:56 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Disconnected by services] 03:26:59 -!- Bike_ is now known as Bike 03:34:25 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 03:39:06 -!- christoph_debian [~christoph@ppp-46-244-233-28.dynamic.mnet-online.de] has quit [Ping timeout: 246 seconds] 03:52:28 christoph_debian [~christoph@ppp-46-244-239-98.dynamic.mnet-online.de] has joined #sbcl 04:06:02 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 04:06:41 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 04:09:29 -!- samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has left #sbcl 04:11:05 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds] 04:13:45 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 04:13:45 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 04:13:45 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:16:52 samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 04:20:39 heddwch [~yoshi@76.8.3.189] has joined #sbcl 04:21:57 -!- heddwch [~yoshi@76.8.3.189] has quit [Client Quit] 04:26:10 heddwch [~yoshi@76.8.3.189] has joined #sbcl 04:37:09 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 04:38:23 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer] 04:38:55 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 04:38:56 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 04:40:14 -!- ltt_ [~ltt_@187.10.23.200] has quit [Quit: Textual IRC Client: www.textualapp.com] 04:44:11 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 04:53:33 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 05:39:42 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 05:44:24 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 265 seconds] 06:00:00 -!- oleo [~oleo@xdsl-78-35-164-23.netcologne.de] has quit [Quit: Leaving] 06:10:35 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 06:11:01 echo-area [~user@182.92.247.2] has joined #sbcl 06:16:42 sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 06:18:20 -!- ASau` is now known as ASau 06:19:23 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:20:33 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 272 seconds] 06:21:23 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 06:21:23 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 06:21:23 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:22:21 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 06:36:04 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 246 seconds] 06:40:25 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 06:44:32 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 240 seconds] 06:53:03 -!- sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds] 07:15:01 prxq [~mommer@x2f6a0dc.dyn.telefonica.de] has joined #sbcl 07:41:10 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 07:46:03 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 08:13:08 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 08:41:54 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 08:46:23 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds] 09:32:35 -!- ben1 is now known as bentgf 09:42:41 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 09:46:57 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds] 09:56:42 hzp [~user@87-95-84-107.bb.dnainternet.fi] has joined #sbcl 10:30:14 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 252 seconds] 10:34:07 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:43:25 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 10:48:05 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 248 seconds] 10:51:45 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 11:10:03 rudi [~rudi@1x-193-157-200-36.uio.no] has joined #sbcl 11:17:39 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:19:50 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 11:28:40 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 11:32:27 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 11:36:12 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Client Quit] 11:38:45 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 11:44:09 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 11:48:24 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 246 seconds] 12:05:19 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 12:14:51 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Ping timeout: 272 seconds] 12:16:44 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 12:29:37 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 12:33:45 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 12:35:02 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Client Quit] 12:44:38 teggi [~teggi@123.21.198.146] has joined #sbcl 12:44:56 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 12:48:37 -!- rudi [~rudi@1x-193-157-200-36.uio.no] has quit [Quit: Client exciting.] 12:49:41 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 248 seconds] 12:50:37 eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has joined #sbcl 12:56:39 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 13:08:08 echo-area [~user@111.196.3.89] has joined #sbcl 13:25:57 LiamH [~none@129-2-129-146.wireless.umd.edu] has joined #sbcl 13:27:27 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 13:28:03 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 13:32:45 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 265 seconds] 14:04:39 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Ping timeout: 265 seconds] 14:29:26 -!- LiamH [~none@129-2-129-146.wireless.umd.edu] has quit [Quit: Leaving.] 14:36:13 back to the deadlock, so, sub-gc seems to trip on a safepoint before it gets a chance to release the gc-lock 14:38:11 oleo [~oleo@xdsl-78-35-164-23.netcologne.de] has joined #sbcl 14:41:23 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 252 seconds] 14:46:48 segv- [~mb@95-91-241-10-dynip.superkabel.de] has joined #sbcl 14:56:57 psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 15:20:39 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 15:26:38 -!- eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 15:36:07 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Quit: Textual IRC Client: www.textualapp.com] 15:50:49 luis- [~luis@kerno.org] has joined #sbcl 15:52:26 ivan``_ [~ivan@unaffiliated/ivan/x-000001] has joined #sbcl 15:52:38 -!- oleo [~oleo@xdsl-78-35-164-23.netcologne.de] has quit [Ping timeout: 248 seconds] 15:52:38 -!- luis` [~luis@kerno.org] has quit [*.net *.split] 15:52:38 -!- ivan`` [~ivan@unaffiliated/ivan/x-000001] has quit [*.net *.split] 15:53:43 oleo [~oleo@xdsl-78-35-156-132.netcologne.de] has joined #sbcl 16:06:24 eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has joined #sbcl 16:12:33 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:25:27 -!- ams [ams@Psilocybe.Update.UU.SE] has quit [Remote host closed the connection] 16:26:28 so, what alien variables should look like? they looks like special variables, but are not treated as such 16:26:43 (define-alien-variable errno int), errno => 110, (boundp 'errno) => NIL 16:28:18 kwmiebach [~kwmiebach@xdsl-213-196-192-206.netcologne.de] has joined #sbcl 16:29:09 but they can't be bound, maybe they should be like constants? 16:29:39 though, they can be changed, looks most like symbol macros 16:33:37 more like symbol macros, indeed. 16:35:26 but macroexpand-1 doesn't work on them 16:41:00 i think i have a pretty clear picture now of the deadlock, after the GC is done, the world is started, another thread wants to GC badly, and sets up some notification through safepoints, and release-mutex is tripped on the safepoint 16:41:43 so, the gc lock is not released, and this thread that wants to gc wants to lock, and the holding thread is for some reason suspended 16:42:08 probably "entering phase 2" of gc makes the thread sleep after tripping on the safepoint 16:43:37 doesn't sub-gc disable interrupts or at least being able to trigger GCs? 16:45:35 wait. there's totally a race condition for a deadlock here. 16:46:10 two threads enter without-interrupt simultaneously. 16:46:42 both set gc-pending and bind *without-gcing*. Only one gets the mutex. 16:47:35 stassats: what do you think of setting :wait-p to nil in that with-mutex? 16:48:08 if the mutex is taken, a GC is under way, so has been triggered. 16:48:11 the one waiting on the gc-lock enters sub-gc after start-the-world happens 16:48:31 but there's a third thread, doing no consing 16:49:05 yacks [~py@103.6.159.103] has joined #sbcl 16:50:05 they both wake up after start-the-world, go to check_pending_gc, one doesn't need gc, another does 16:51:12 pkhuong: so, if both threads want to gc, one performs collection, would another thread be cleaned up appropriately? 16:52:23 I'm going to need some coffee first. I'm getting the specials and globals mixed up in that function. 16:53:48 i don't think the problem is both waiting on the gc-lock, the problem is that the second thread suspends the first while the first still holds onto gc-lock 16:54:11 now, why on earth does it suspend it, if suspension is supposed only to happen when stop-the-world is executed, and that's under a lock 16:55:48 and yes, why doesn't without-interrupts stop it from suspending it in the first place 16:58:03 without-interrupts doesn't prevent stop-for-gc 16:59:08 there's a tiny tiny window during which a thread can hold the mutex but have gc-inhibit = NIL. 16:59:32 but that's ok. 17:00:07 because no one else can stop-for-gc while that mutex is held. 17:00:25 i had it lock even when it didn't leave the (*gc-inhibit* t) extent 17:00:48 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: activity lost into perpetual something] 17:01:31 interestingly, when thread 2 does check_pending_gc, it segfaults, and the address is neither the global safepoint, nor the thread safepoint 17:03:27 the next message is /thread_register_gc_trigger 17:04:32 which can only come from general_alloc_internal 17:04:32 what I don't get is why the mutex isn't only around stop-the-world. 17:05:32 or at least not around start-the-world 17:10:51 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 17:14:35 i tried :wait-p nil => heap exhaustion 17:15:28 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 264 seconds] 17:17:48 what without-thread-waiting-for is supposed to be doing? 17:19:15 I think the goal is to avoid mutexes convoying while a thread is waiting to trigger a GC. 17:19:43 I'd try to take it out. I know you want to ;) 17:20:00 i did, the deadlock i still there 17:29:56 ltt_ [~ltt_@187.10.23.200] has joined #sbcl 17:32:49 leuler [~user@p548FB1BD.dip0.t-ipconnect.de] has joined #sbcl 17:36:49 now i get why M-. is sometimes useless, make tags doesn't feed .h files to etags 17:36:54 sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 17:55:06 How did you end up in C, stassats? 17:55:20 heddwch: what do you mean? 17:56:27 now i get why M-. is sometimes useless, make tags doesn't feed .h files to etags 17:56:31 .h files 17:57:09 Sorry, I was just curious, I didn't read the whole replay if you mentioned why you were working with C 17:58:11 he's dealing with the runtime, how wouldn't he end up in C 17:58:47 Hey, optimism still has a place if you enjoy mental health 17:59:11 But I know, I was just curious what part of the work ended up delving to... /that/ place 17:59:41 i was dealing with it all the time 18:00:06 Ah 18:00:15 All right, sorry for the silly question 18:02:44 hoisting start-the-world out of the lock of course solve the deadlock 18:03:05 but, why was it made that way, and why doesn't it break on linux? 18:04:15 scheduling magic, I'm going to guess. 18:04:55 there's only a handful of instructions between start-the-world and the end of the critical section. 18:04:57 what about the call to (maybe-handle-pending-gc)? 18:05:06 that call is outside the mutex 18:05:16 right, but it says something about invariants 18:05:27 where should be relative the world start 18:05:50 that looks like a without-gcing invariant 18:06:42 that hoisting makes sense, but i'm still not convinced entirely 18:06:47 need more investigation 18:07:58 -!- teggi [~teggi@123.21.198.146] has quit [Remote host closed the connection] 18:12:25 -!- sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 272 seconds] 18:20:23 and that's why i need the third thread spinning, to slow down the consing threads, and the VM has two cores 18:20:39 without the spinning thread it happens too, but not so frequently 18:21:03 maybe i can pin sbcl on linux to only one core too and see what happens 18:24:45 -!- eudoxia [~eudoxia@r186-52-0-102.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 18:32:11 can't trigger on linux even with 8 threads and pinned to one core 18:33:21 leuler: best so far is . 18:34:29 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 18:36:47 even if i insert (sleep 0.1) after start-the-world 18:37:01 something is not right with the windows part 18:37:40 It's the "windows" part of "the windows part" 18:38:04 <|3b|> possibly getting more calls from non-lisp threads? 18:39:20 and i could trigger it on the last win32-fork, perhaps there was a mistake during the merge/regression after that 18:39:35 coudln't 18:39:48 -!- foom [~jknight@2620:15c:6:14:be30:5bff:fedf:6db6] has left #sbcl 18:39:54 foom [~jknight@2620:15c:6:14:be30:5bff:fedf:6db6] has joined #sbcl 18:40:57 pkhuong: What does "b/w Q1" mean? 18:41:17 Krystof: using swankr and evaluating "1\n2\n3\" the result is 3 times (:write-string...) which will result in a REPL output of "[1] 1[1] 2[1] 3". 18:41:35 i could look at the log of what linux does, but i'm so sick of looking at thme 18:41:50 should swankr ignore intermediate values and only output the last, or should it do a newline inbetween? 18:42:06 flip214: wrong channel? 18:43:22 leuler: right, I tried to make it fit in the width, but that failed. 18:44:07 So, I ran all the tests for the max of 10 iterations or ~1 minute. And took the first quartiles of the runtimes in cycles. Did that 6 times in fresh processes. 18:45:11 well, why is :in-progress not respected? 18:45:14 Did that for each regalloc, and then for each test, sorted the quartiles and printed the relative difference between the two. 18:45:38 stassats: no, I don't think so. I found Krystof here last time, so I'm trying again. 18:46:01 I also eliminated tests for which the relative differences were sometimes negative and sometimes positive, and those for which the difference between the values is smaller than the spread (difference between the median and the extrema) reported in parentheses. 18:46:05 I believe swankR has 1.5 users including him and me, so there's no dedicated channel. 18:46:17 there's PM, there's email 18:46:51 (CLOS/ defmethod, defclass and method+after are really tests of the compiler speed, FWIW) 18:48:30 stassats: yeah, I've done a github issue now. sorry for the noise. 18:51:04 it may examine GC_PENDING before it's set to :in-progress and decide to gc before being frozen 18:52:08 what's it? 18:52:51 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 272 seconds] 18:54:16 -!- ltt_ [~ltt_@187.10.23.200] has quit [Quit: Textual IRC Client: www.textualapp.com] 19:01:33 pkhuong: I don't get it completely enough. If I wanted to condense the numbers to the average over all tests, may I just take the average of the columns? But that gives -10.04/47 for the first and 4.76/47 for the last column. 19:02:13 actually, gc-pending is set to NIL before gc-start-the-world 19:02:56 the first column reports the best-looking ratio and the last the worst. 19:04:03 Between the best regalloc and HEAD, which is the old regalloc? 19:04:06 so these averages make sense. It's something like 10% quicker to 5% slower overall. 19:04:19 HEAD is the old 19:05:45 there's a lot of general_alloc_internal between the start of the world, but before the full mutex release 19:06:04 OK, so I take the average of the averages of the third and fourth columns and arrive at 4.15 percent faster. 19:06:28 so it cannot be explained just by scheduling issues 19:06:51 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 19:07:38 leuler: but I'm still exploring a couple changes. I should have something final in ~8 hours 19:08:14 pkhuong: Looking forward to it. 19:10:20 The way I look at these results is that, disregarding nearly equal values, that regalloc only improves runtimes in 52% of the trials, by 1.2% on (geometric) average ;) 19:11:07 but when it works, it can really help. 19:13:29 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 19:16:58 pkhuong: I wonder if these small differences, even after taking the 1Q and after averaging over all tests, mean something. When the speed of the SBCL compiler, once compiled with the old and once with the new regalloc, is noticeably different, that will be something, IMO. 19:18:09 same. 19:20:05 The strange TAK implementations (CTAK and TAKL especially) seem to reflect random changes in the runtime system. 19:20:30 well, i now get a deadlock even when with-mutex is finished 19:21:45 bah, it's all really confusing 19:26:00 I agree that the CLOS/... benches measure compiler speed. As they became much slower, did you investigate that already? Or intend to? Too many iterations due to some limit cycle or somehow not detecting that no progress is made? 19:29:17 Later. I feel like we have a better grap on the performance of our code than that of the code it generates. 19:29:22 *grasp 19:30:24 It's already < 5% in the current best. 19:33:50 i guess that's enough deadlocks for a day, at least now i know what's going on 19:35:00 Oh, yes. Sorry, I didn't notice that your paste contained CLOS/complex-methods with less than 10 percent loss. It was 5 times as slow (new allocator compared to the old) a few days ago. Then the compiler speed can indeed wait for later. 19:36:03 -!- stassats [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:39:07 drmeist__ [~drmeister@155.247.96.196] has joined #sbcl 19:39:12 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Read error: No route to host] 19:58:43 -!- oleo [~oleo@xdsl-78-35-156-132.netcologne.de] has quit [Remote host closed the connection] 19:59:38 oleo [~oleo@xdsl-78-35-156-132.netcologne.de] has joined #sbcl 20:00:20 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 20:07:50 yacks [~py@103.6.159.103] has joined #sbcl 20:10:28 -!- drmeist__ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 20:11:03 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 20:11:46 -!- cmack [~charlie@adsl-74-179-28-220.bna.bellsouth.net] has quit [Remote host closed the connection] 20:15:28 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 264 seconds] 20:25:54 Bike [~Glossina@wl-nat101.it.wsu.edu] has joined #sbcl 20:26:12 -!- leuler [~user@p548FB1BD.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 20:29:21 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 20:47:00 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 20:47:40 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 20:51:40 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 245 seconds] 20:56:22 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 21:11:33 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 21:12:10 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 21:16:43 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 272 seconds] 21:32:57 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 22:12:33 -!- prxq [~mommer@x2f6a0dc.dyn.telefonica.de] has quit [Quit: Leaving] 22:12:38 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 22:16:18 eudoxia [~eudoxia@r186-54-250-225.dialup.adsl.anteldata.net.uy] has joined #sbcl 22:17:13 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 246 seconds] 22:18:11 -!- eudoxia [~eudoxia@r186-54-250-225.dialup.adsl.anteldata.net.uy] has quit [Client Quit] 22:22:40 -!- psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:22:51 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 22:28:04 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 246 seconds] 22:29:47 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 22:31:32 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 22:32:01 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Read error: Connection reset by peer] 22:37:42 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 22:57:19 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 23:02:29 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 272 seconds] 23:07:25 drmeiste_ [~drmeister@166.137.104.11] has joined #sbcl 23:36:57 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:36:58 -!- drmeiste_ [~drmeister@166.137.104.11] has quit [Read error: Connection reset by peer] 23:40:43 -!- echo-area [~user@111.196.3.89] has quit [Remote host closed the connection] 23:45:23 stassats [~stassats@wikipedia/stassats] has joined #sbcl 23:46:08 i'm now convinced that it's a scheduling problem, because the second thread runs for a while, allocating things, before deciding he needs to see a GC 23:46:28 all the while the first thread is sitting waiting for with-mutex to release the mutex 23:49:15 and i'm convinced that moving start-the-world from under the mutex is the right thing 23:49:58 it might have been protected by without interrupts in the old signally way, but not anymore