01:42:36 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: Textual IRC Client: www.textualapp.com] 01:48:21 -!- yacks [~py@103.6.159.103] has quit [Ping timeout: 272 seconds] 01:54:16 yacks [~py@103.6.159.103] has joined #sbcl 02:12:08 -!- oleo [~oleo@xdsl-78-35-189-219.netcologne.de] has quit [Ping timeout: 260 seconds] 02:12:36 oleo [~oleo@xdsl-84-44-155-50.netcologne.de] has joined #sbcl 02:13:38 ASau` [~user@p5083D591.dip0.t-ipconnect.de] has joined #sbcl 02:13:54 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 02:16:53 -!- ASau [~user@p5083DB6A.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 02:36:02 hargettp [~hargettp@c-65-96-162-255.hsd1.ma.comcast.net] has joined #sbcl 02:43:38 -!- hargettp [~hargettp@c-65-96-162-255.hsd1.ma.comcast.net] has quit [Quit: Leaving...] 02:57:11 prxq_ [~mommer@x2f6cc33.dyn.telefonica.de] has joined #sbcl 03:00:31 -!- prxq [~mommer@x2f6cba8.dyn.telefonica.de] has quit [Ping timeout: 252 seconds] 03:38:33 -!- christoph_debian [~christoph@ppp-46-244-235-213.dynamic.mnet-online.de] has quit [Ping timeout: 252 seconds] 03:52:03 christoph_debian [~christoph@ppp-88-217-51-196.dynamic.mnet-online.de] has joined #sbcl 04:41:27 -!- heddwch is now known as heddwch_sleeps 04:47:55 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 04:47:55 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 04:47:55 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:54:14 -!- yacks [~py@103.6.159.103] has quit [Remote host closed the connection] 05:00:50 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 264 seconds] 05:41:34 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 06:21:57 -!- ASau` is now known as ASau 06:33:37 sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 06:45:24 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 06:53:50 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 07:38:04 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:00:32 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 240 seconds] 08:54:29 Odyessus [~odyessus@089144193206.atnat0002.highway.a1.net] has joined #sbcl 08:58:23 -!- Odyessus [~odyessus@089144193206.atnat0002.highway.a1.net] has quit [Client Quit] 10:33:53 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 10:36:37 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:38:37 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 265 seconds] 10:42:48 looks like *already-in-gc* lock is where it deadlocks, not clear why 10:54:42 -!- heddwch_sleeps is now known as heddwch 11:17:01 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:27:26 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 11:32:55 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 272 seconds] 11:34:58 so, another thread happens to end up GCing, while another gc haven't yet finished 11:52:42 and what on earth is *stop-for-gc-pending*? 11:53:53 is it "a gc stop is pending", or, "stop, for gc is nigh" 11:56:23 I'm sure whoever wrote it knew the obvious answer 11:59:05 the fact that whoever wrote it left it broken, doesn't inspire any confidence 12:01:38 Maybe wasn't broken on monoproc =p But I know what you're saying 12:03:44 *stop-for-gc-pending* is older then win32 threading, but the thing is full of such unwritten conventions 12:04:46 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: lifetime interrupted by memory explosion] 12:04:50 and emacs is killing me too, opening a 400M file? no problem. reloading a 20M file, let's freeze for a while 12:05:03 *stassats* generates a lot of logs for this 12:05:24 lol The 20M file has more to parse 12:05:50 no, it's the same file, if i kill the buffer, and open it anew, it's snappy, but not if i ask to reload it 12:06:14 ...hm 12:22:41 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 12:28:13 i like the name of phases too, GC_QUIET, GC_SETTLED 12:28:29 and, you could have guessed, no explanation as to what on earth that means 12:29:10 Just add a third GC_QUIESCENT and pretend nothing ever happened 12:29:16 -!- sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has quit [Read error: Operation timed out] 12:35:09 i guess i know what happens, in sub-gc, it holds the lock to *already-in-gc*, stops the world, does its job, and starts the world, all while holding it 12:35:59 now, a thread awoken from sleep during start-the-world, wants to gc, grabs the *already-in-gc*, which is taken already, waits, but while it grabs, it probably also grabs some other lock to some state thing 12:36:21 now, when the original thread wants to release its lock, it wants to grab this another state lock => a deadlock 12:36:30 that's just a theory so far 12:36:52 Probable 12:37:02 , but the trick is finding some state thing* 12:37:36 the runtime has a lot of logging, and i'm adding some more as i pinpoint things 12:38:18 Ah, nice! 12:39:19 if you want to enable it for yourself, you can build with :sb-qshow, then start SBCL_DYNDEBUG=all sbcl 2> log 12:39:32 seems to be enabled by default on windows 12:40:24 Cool, thanks! 12:41:04 hargettp [~hargettp@c-65-96-162-255.hsd1.ma.comcast.net] has joined #sbcl 12:41:07 -!- hargettp [~hargettp@c-65-96-162-255.hsd1.ma.comcast.net] has quit [Client Quit] 12:52:32 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 12:59:12 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: Textual IRC Client: www.textualapp.com] 13:08:29 -!- milosn_ is now known as milosn 13:26:48 ok, i see the second lock 13:31:53 while i lost the first one 13:32:43 Oh no lol 13:35:01 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 13:54:30 no, it's still the gc lock, but who it should have been released by that time 13:58:39 sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 14:07:56 leuler [~user@p548F8784.dip0.t-ipconnect.de] has joined #sbcl 14:21:15 -!- sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds] 14:22:19 LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has joined #sbcl 14:31:02 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 14:39:27 milosn_ [~milosn@user-5af5020b.broadband.tesco.net] has joined #sbcl 14:40:08 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 14:42:23 -!- milosn [~milosn@user-5af50a8a.broadband.tesco.net] has quit [Ping timeout: 272 seconds] 14:53:21 -!- oleo [~oleo@xdsl-84-44-155-50.netcologne.de] has quit [Ping timeout: 268 seconds] 15:06:13 oleo [~oleo@xdsl-78-35-143-152.netcologne.de] has joined #sbcl 15:16:19 -!- oleo [~oleo@xdsl-78-35-143-152.netcologne.de] has quit [Quit: Leaving] 15:16:24 hargettp [~hargettp@c-65-96-162-255.hsd1.ma.comcast.net] has joined #sbcl 15:17:44 -!- echo-area [~user@114.254.99.176] has quit [Remote host closed the connection] 15:18:37 echo-area [~user@114.254.99.176] has joined #sbcl 15:26:04 -!- hargettp [~hargettp@c-65-96-162-255.hsd1.ma.comcast.net] has quit [Quit: Linkinus - http://linkinus.com] 15:30:37 i can't pry out the owner of the lock, it keeps telling me the address is invalid 15:31:00 could be so that the thread has moved, but the mutex reference haven't been updated, causing all sorts of trouble? 15:31:59 that doesn't sound too windows-specific 15:33:27 oleo [~oleo@xdsl-78-35-143-152.netcologne.de] has joined #sbcl 16:04:21 and the printer just cuts off at 32-bit, while my address is 32-bit 16:04:34 37 16:21:10 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:23:45 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Client Quit] 16:24:05 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 16:24:05 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 16:24:05 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:24:23 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 16:26:50 maybe the printer is right, but something else fucks up the pointer 16:39:53 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 16:50:44 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 16:52:29 kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has joined #sbcl 16:53:20 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 17:01:04 -!- kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has quit [Quit: Leaving] 17:02:42 oh my, sizeof(unsigned long) => 4 17:46:02 -!- leuler [~user@p548F8784.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 17:46:49 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 17:47:57 leuler [~user@p548F9D97.dip0.t-ipconnect.de] has joined #sbcl 17:49:25 stassats: didn't we switch everything to uword/sword? 17:49:57 apparently not 17:50:33 grep shows a lot of longs/unsigned longs 17:50:45 maybe they are unimportant 17:51:47 leuler: I've got something that makes more sense than annotations in the assembler. It can even unscrew the [jcc next; jmp case; next: ...] sequences in arg parsing... sadly, I don't think that straightening arg parsing to move the defaulting sequence "[default n arguments] [default n-1] ... [default 1 arg] jmp body" just before the body. I don't feel comfortable preserving nice loop ordering and the invariant that blocks for a given 17:53:56 perhaps control could detect blocks that do nothing but move values and order them optimistically. 17:54:44 i changed them to intptr_t/uintptr_t, but i still get cut off thread address 17:55:18 there's some mockery with printf going on as well 17:56:38 pkhuong: I can't parse your second and third sentence above. 17:57:38 yacks [~py@103.6.159.103] has joined #sbcl 18:00:51 leuler: http://paste.lisp.org/display/139983 18:05:01 printf %p is clearly broken 18:05:37 or i need to cast to unsigned long long there too 18:05:38 anyway. I don't think it's practical to achieve the ideal ordering (and even then... moving the ERROR break out of line and falling through to L0 is arguably pretty good too), at least not this late. 18:09:27 print.c is not 64-bit at all 18:16:37 pkhuong: How do you do that? (the changes in paste 139983) 18:17:20 the runtime seems to have 25 different definitions of word types 18:17:26 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 18:17:36 some are even used to declare the same thing 18:20:14 i got to print some proper values, but it didn't get me any closer 18:20:47 the gc lock still seem to be belonging to the thread which seemingly released it 18:21:39 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 246 seconds] 18:22:37 leuler: linear scan over IR2 blocks to find blocks that only perform no-op moves (a combination of a test on the move-vop for a "identity move" property and location= test) 18:22:44 and perhaps an unconditional branch. 18:22:50 pkhuong: In the meantime: I have looked into your sb-assem-jump-jump branch. It works. It sometimes leaves behind dead code (if the second jump of a chain is reached only by jumps, not by fall-through). 18:23:19 then flatten such chains exactly like the sb-assem-jump-jump branch does. 18:23:56 OK. 18:24:13 After that, it's a backward traversal of the IR2 blocks to remove trailing branch VOPs in otherwise empty blocks, and then rewrite the tail of each non-empty block. 18:29:13 it's x86, but on virtualbox, it could be memory ordering issue 18:29:15 Is the test for no-op moves precise (no false negatives, no false positives)? 18:29:27 but i reproduced it on a bare hardware too, i think 18:29:31 leuler: there may be false negative. No false positive. 18:30:44 move vops that assemble to nothing when the source and destination are location= are declared as such in define-move-vop. 18:32:01 i check after the mutex is released => not locked, but it becomes locked the next time it tries to grab it 18:32:08 i see no other paths to the mutex 18:32:14 stassats: what mutex is this again? 18:32:31 sb-kernel::*already-in-gc* 18:32:45 it's used only in one place, sub-gc 18:34:29 pkhuong: That (declaration in define-move-vop) sounds good. 18:34:41 i'm tracing through call-with-mutex, i need to try call-with-recursive-lock too 18:34:56 stassats: could it be without-thread-waiting-for? 18:35:29 Are these kinds of move vops the only sources of empty blocks? 18:36:57 leuler: I don't think so. We also have VOPs that do nothing but denote where functions begin, at least. But it seems to catch most cases I see. 18:36:58 pkhuong: good idea, that's another path to the mutex 18:37:04 through thread-waiting-for 18:39:20 pkhuong: I remember seeing an aligned jump to the next aligned position 16 bytes later where a local function begins. That would exactly be what you mention, and it would be nice to spare the jump and the 16 bytes of space there. 18:40:05 but it just clears thread-waiting-for, and sets it back 18:41:03 leuler: I think my patch will skip the intermediate jump but still emit it. 18:43:49 pkhuong: I wonder if it's time to implement some kind of searching/backtracking, so that to decide if a block was empty one would tentatively emit it. If the guess turns out wrong, decide on another order and try again, then compare the cost of both alternatives and choose the better one. 18:44:33 leuler: mm... so move all of control.lisp into codegen? 18:44:55 that would be a most interesting hack. 18:45:23 some VOPs are stateful, but I think they just overwrite all the things anyway. 18:45:54 oh no. that'd really mess with regalloc. 18:46:04 another reason *not* to reorder blocks (: 18:46:25 I don't get your remark about codegen. There is no search yet there, is it? 18:47:21 no, but that's the only practical way that I see. Unless you really meant backtracking over half the IR2 pipeline? 18:48:03 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 18:49:57 wait no. emission order can't affect regalloc. that's already that. 18:50:28 (until live ranges get split) 18:53:01 I don't know the order of compiler steps good enough. I just looked it up: control-analyze is currently called way before generate-code. So I think I really meant backtracking over half the IR2 pipeline. Oops. 18:53:05 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 18:56:05 leuler: One day I'll write a fully integrated toy code generator. It'll take hours to emit twenty instructions, but there'll be none of this phase ordering madness ;) 18:56:57 pkhuong: +1! We need (declare (optimize (compilation-speed -1))) then. 18:58:28 Probably, if one doesn't want to make the compiler source code too complex, some optimizations simply can't be had. 18:58:45 pkhuong: So you're going to make another ITS-style lisp? ;) 18:58:59 -!- |3b| [bbb@2600:3c00::f03c:91ff:fedf:5b65] has quit [Read error: Connection reset by peer] 18:59:09 -!- reb [user@nat/google/x-slkbxlnmbtmbwwup] has quit [Remote host closed the connection] 18:59:26 -!- foom [~jknight@2620:15c:6:14:be30:5bff:fedf:6db6] has quit [Ping timeout: 240 seconds] 18:59:26 reb [user@nat/google/x-rmjknxfbabhazxvx] has joined #sbcl 18:59:44 leuler: I think the lesson here is that we should have more CFG information on IR2 blocks and instead move control to after regalloc and representation selection. 19:00:10 word to the unwise who'll try to write another python-style compiler ;) 19:02:10 i'd love to write a compiler, but i don't want to write a run-time 19:02:36 foom [~jknight@2620:15c:6:14:be30:5bff:fedf:6db6] has joined #sbcl 19:03:02 The runtime could be made much simpler with different design choices that put more pressure on the compiler. 19:03:41 interface to the OS is what drives me off 19:04:32 if it's just one sane OS, then maybe 19:09:09 lol Aren't you working on trying to fix the Windows port, stassats? 19:09:23 heddwch: that's why i don't like it 19:09:36 Yea, I don't envy you and wish you the best of luck 19:09:51 after debugging the windows port, solaris port, ppc port 19:10:08 Your mention of a "sane OS" made me remember what OS you were working on =p 19:10:13 well, and linux-x86 too 19:10:40 the main difficulty is C, bad debuggers, and the lack of REPL 19:10:42 PPC port is something I'm planning on using. That's linux-ppc, no? 19:10:56 I think darwin would be pretty sane nowadays, in that we could pretend it's a bsd. 19:11:20 heddwch: yep, should be fine now, except for occasional memory ordering issues 19:11:33 Cool, thanks for the work! 19:12:14 Darwin-ppc is a kind of pointless port by this point 19:13:43 -!- heddwch is now known as heddwch_kills_an 19:14:02 -!- heddwch_kills_an is now known as hedd_kills-imac 19:14:09 after tracing mutex-grab and mutex-release, i now don't see the mutex being released 19:14:32 grab-mutex and release-mutex, that is 19:14:46 leuler: also, I was looking at the PA sequence. It currently does xor / jcc next / break / next: ... What do you think of instead moving the break out of line (in elsewhere), and having the forward branch not be taken in the common case? 19:18:33 could unwind-protect be broken on windows again? 19:25:53 win64 would break differently 19:28:26 changed to progn, but i see really strange things 19:30:19 as if the clean up form is called twice, but only the first form is actually evaluated 19:31:08 first, but evalauted twice 19:32:34 -!- milosn_ is now known as milosn 19:35:36 sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 19:36:21 32-bit sbcl demonstrates the same kind of nonsensical output 19:37:41 the streams may be just cooked up 19:42:58 indeed they are, only outputting to a file is guaranteed to work properly 19:44:15 abarch [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 19:44:43 pkhuong: hey, i have conducted cl-bench tests and compared my latest version with your newest 19:45:01 pkhuong: and it seems that in a lot of tests your version is a bit worse 19:46:27 pkhuong: PA: Difficult to say. There are two possible advantages to have the common case being "not taken": 19:48:22 First, Agner Fog says "The fetching of code after an unconditional jump or a taken conditional jump is delayed by typically 1-3 clock cycles, depending on the microprocessor." This may make the code slower, but only if it is code fetch limited. I don't know how often that happens in typical SBCL code. 19:48:22 19:48:47 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 19:49:16 Second, if it's possible that the jump is never taken, that would be optimal as it then consumes no branch prediction resources. 19:49:37 leuler: that seems very plausible for PA. 19:50:58 The only disadvantage is that the code size will often grow: Now we have (on x86[-64]) 2 bytes for the conditional jump and 2 bytes for the trap. With the trap out of line the branch will often be 6 bytes long. 19:51:26 abarch: how long would it be to bisect through the development branch (https://github.com/pkhuong/sbcl/commits/regalloc-cleanup-2)? 19:53:15 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds] 19:53:18 pkhuong: i have tried regalloc-cleanup-staging-rewrite-history-again 19:53:37 pkhuong: is there a branch which is closer to my code? 19:53:54 abarch: the development branch has all the intermediate commits from your code to the final result. 19:54:54 pkhuong: i suspect it might be better, if i try to take a look at your current version. maybe i can see, what tweaks are missing. 19:55:22 pkhuong: it might be some sort, that used to improve the results 19:56:16 I was hoping you'd remember all the important details well enough for that. If all else fails, bisecting through 130-some commits may not be *that* bad. 19:56:34 pkhuong: :) 19:56:37 there's the initial sort before constructing the interference graph that was lost. 19:57:05 pkhuong: the ideas that you have mentioned in the email sound awesome 19:57:15 pkhuong: do you want to do this, or should i try? 19:57:42 well, I'd rather fix the regression first, if possible ;) 19:58:00 I'll send you my notes re coalescing later today. 20:00:20 pkhuong: ok, then i will first try to see, whether any of the originally important stuff is missing in the current version 20:00:25 abarch: I took this sort out without trying to replicate it (the next step is to sort by tn-spill-cost). 20:01:43 pkhuong: examining 130 version with cl-benchmarks might not be a good idea 20:02:19 abarch: but a bisecting would need ~7 in the worst case. 20:02:28 -a 20:03:58 pkhuong: for this purpose one would need to inspect all 66 tests in each step per hand 20:04:09 or is there any other better solutions? 20:04:37 I don't see how to script this, sadly. 20:05:01 fisxoj [~fisxoj@24-212-142-77.cable.teksavvy.com] has joined #sbcl 20:05:10 -!- fisxoj [~fisxoj@24-212-142-77.cable.teksavvy.com] has quit [Remote host closed the connection] 20:06:16 abarch: also, another issue might be that wired TNs are not in the interference graph. They're taken into account in the domain for each vertex instead. That may affect the prespilling heuristic. 20:09:34 pkhuong: which part of the prespilling heuristic do you mean? 20:10:41 abarch: https://github.com/pkhuong/sbcl/blob/0bce0278e6c45d3841826267a30eaae9cc225546/src/compiler/pack-iterative.lisp#L496 20:18:08 abarch, pkhuong: I may be able to help with benching and bisecting. I have comparing two or more SBCL versions with respect to cl-bench runtimes (per test and aggregated, median and variation coefficient of 5 runs) automated here. 20:18:37 pkhuong: the sort that you have taken out used to be important in my old implementation 20:18:57 pkhuong: as far as i understand in the interference-graph the sorting is in the opposite direction 20:19:10 pkhuong: compared to my version 20:19:39 abarch: not quite. In your version, the interference graph's vertices are always processed in the opposite order to the initial sort. 20:21:13 but the initial sort may still be important: it imposes a different order on otherwise equal vertices. 20:21:42 pkhuong: at least as during tests this version seemed to make a positive effect 20:23:14 pkhuong: i think the easiest way is to try it out 20:23:20 right. 20:23:48 I'd just reinsert the stable sort before passing the vertex list to the interference graph construction routine 20:39:45 leuler: would you like to have a look at https://github.com/scymtym/sb-benchmarks? it is modeled after the test harness in SBCL's tests directory and mainly aimed at automation of benchmarks and detection of performance regressions. it uses a form of your recent runtime* macro as well :) 20:47:46 scymtym_: I will take a look! Did you find any benchmarks that are more meaningful and less erratic than the cl-bench ones? 20:48:22 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 20:49:03 leuler: not many so far. i added some microbenchmarks for recent commit, e.g. restart-* equalp-for-raw-structure-slots also the mcmc example from sbcl-devel 20:50:15 i don't think any of these are particularly illuminating by themselves but i'm hoping to be able to automatically detect performance regressions at some point 20:51:08 i also added adapted versions of most of the cl-bench benchmarks 20:56:03 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 272 seconds] 20:57:34 |3b| [bbb@2600:3c00::f03c:91ff:fedf:5b65] has joined #sbcl 21:03:50 kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has joined #sbcl 21:16:34 ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has joined #sbcl 21:33:24 lacedaemon [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 21:33:50 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Ping timeout: 252 seconds] 21:33:50 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [Ping timeout: 252 seconds] 21:34:21 -!- brucem [~bmitchene@waywardmonkeys.com] has quit [Ping timeout: 252 seconds] 21:34:37 brucem [~bmitchene@waywardmonkeys.com] has joined #sbcl 21:34:52 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #sbcl 21:41:27 -!- kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has quit [Quit: Leaving] 21:42:21 kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has joined #sbcl 21:42:44 -!- kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has quit [Read error: Connection reset by peer] 21:43:25 kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has joined #sbcl 21:50:52 -!- kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has quit [Ping timeout: 264 seconds] 21:52:14 cl-bench now takes 4 minutes to run for me, but at least the results seem to show little variance. I've switch to using call-with-timing and sb-vm::with-cycle-counter (to compute the least number of cycles for a single iteration). 21:53:34 kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has joined #sbcl 21:53:34 -!- kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has quit [Client Quit] 21:55:34 My approach so far was to set the number of iterations so high that each test takes about one second and measure using get-internal-real-time. The variations are low that way, too. 22:03:16 pkhuong: I would really like to compare abarch's final version with the last one of yours (mostly I'm curious to see if this CLOS benchmark behaves the same in both). Could you provide me with a pointer to abarch's final version? 22:04:38 My code is based on 22:10:54 -!- sdemarre [~serge@31.103-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 246 seconds] 22:16:18 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 22:18:04 Thanks! 22:20:44 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 22:23:18 -!- prxq_ [~mommer@x2f6cc33.dyn.telefonica.de] has quit [Remote host closed the connection] 22:30:25 -!- yacks [~py@103.6.159.103] has quit [Ping timeout: 272 seconds] 22:32:04 yacks [~py@103.6.159.103] has joined #sbcl 22:42:43 -!- hedd_kills-imac is now known as heddwch 22:43:14 i forgot to mention, that i used 50 for the number of iterations 22:43:28 for the cl-bench tests 22:44:57 CLOS benchmarks are always better for pkhuong's version 22:46:02 kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has joined #sbcl 22:46:42 -!- kwmiebach [~kwmiebach@xdsl-87-79-225-178.netcologne.de] has quit [Read error: Connection reset by peer] 22:46:47 ... these benchmarks are compiler-bound with fancy regalloc 22:47:10 ... walk-list benchmarks are silly. 22:48:19 the last step is to null out the big list. So multiple iterations are useless. 22:51:17 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 22:52:05 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 22:55:33 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 248 seconds] 22:56:14 pkhuong: walk-list: I did not expect cl-bench to be that bad! 22:56:48 Fixed that here, at least. 23:03:50 there may be an array-related regression: http://cl-test-grid.appspot.com/blob?key=byp8keh1fp; the corresponding code is available here https://ci.cor-lab.org/job/sbcl-master-test-grid/label=ubuntu_quantal_32bit/ws/cl-test-grid/work-dir/agent/quicklisp/dists/quicklisp/software/opticl-20120703-git/*zip*/opticl-20120703-git.zip 23:04:58 -!- ltt_ [~ltt_@189-19-120-48.dsl.telesp.net.br] has quit [Quit: Textual IRC Client: www.textualapp.com] 23:10:04 from what i can tell, one problems seems to be (WHEN (= (ARRAY-RANK IMAGE) 3) (ARRAY-DIMENSION IMAGE 2)) in a context in which IMAGE is known to have rank 2 23:12:32 old bug, but I had some hope that we downgraded all realistic cases to style warnings 23:13:16 seems to be the opposite: that particular compiled before 23:14:42 s/particular/particular code/ 23:16:53 -!- abarch [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 248 seconds] 23:22:05 -!- leuler [~user@p548F9D97.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 23:39:34 reduced test-case: (defun f (foo) (etypecase foo ((array t (* *)) (when (= (array-rank foo) 3) (array-dimension foo 2))))) 23:41:56 the transform for array-dimension needs a (delay-ir1-transform :constraint) before abort-ir1-transform. 23:42:20 perhaps abort-ir1-transform should always delay for constraints. 23:42:52 did this surface as a result of the improved typep transforms? 23:43:04 probably. 23:43:24 i see 23:43:48 i have to go now; should i file a launchpad bug? 23:43:56 oh yes, definitely. There's no way constraint propagation could have figured that out otherwise. 23:44:06 when you can. Thanks for the heads up 23:44:28 sure, byte 23:44:30 bye 23:49:56 lp 1252108 23:49:56 https://bugs.launchpad.net/bugs/1252108 23:49:59 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:51:54 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 23:55:58 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds]