02:11:25 ASau` [~user@p5083DB57.dip0.t-ipconnect.de] has joined #sbcl 02:14:43 -!- ASau [~user@p5083DF2D.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 02:18:15 -!- slyrus [~chatzilla@107.200.11.207] has quit [Ping timeout: 272 seconds] 02:39:09 -!- christoph_debian [~christoph@ppp-88-217-33-100.dynamic.mnet-online.de] has quit [Ping timeout: 252 seconds] 02:52:34 christoph_debian [~christoph@ppp-88-217-33-147.dynamic.mnet-online.de] has joined #sbcl 03:46:20 slyrus [~chatzilla@107.200.11.207] has joined #sbcl 05:07:13 sdemarre [~serge@195.127-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 05:54:34 attila_lendvai [~attila_le@92.47.252.40] has joined #sbcl 05:54:34 -!- attila_lendvai [~attila_le@92.47.252.40] has quit [Changing host] 05:54:34 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:58:33 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:01:59 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:14:48 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Quit: Reconnecting] 06:15:02 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 06:33:44 prxq [~mommer@x2f6cfac.dyn.telefonica.de] has joined #sbcl 09:35:09 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 272 seconds] 09:37:34 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:12:42 -!- ASau` is now known as ASau 10:14:59 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 10:49:15 -!- sdemarre [~serge@195.127-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 272 seconds] 11:01:17 -!- oleo [~oleo@xdsl-78-35-175-252.netcologne.de] has quit [Ping timeout: 272 seconds] 11:01:44 oleo [~oleo@xdsl-78-35-170-225.netcologne.de] has joined #sbcl 11:18:45 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:23:53 weird, SOME causes consing 11:27:58 which causes sb-pcl::class-has-a-forward-referenced-superclass-p to cons quite a bit 11:42:31 stack-allocating the closure solves this, but i'm not sure that this is the best way, since it doesn't have to stack allocate anything in theory 11:44:58 the compile macro can sense 'function or #'function and avoid creating closures 12:40:53 chris_l [~quassel@p5091E4BF.dip0.t-ipconnect.de] has joined #sbcl 13:22:26 Fare [~fare@c-68-81-138-209.hsd1.pa.comcast.net] has joined #sbcl 13:34:19 -!- Fare [~fare@c-68-81-138-209.hsd1.pa.comcast.net] has quit [Ping timeout: 248 seconds] 13:40:59 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 13:58:55 LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has joined #sbcl 14:55:41 davazp [~user@92.251.170.90.threembb.ie] has joined #sbcl 15:25:47 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 15:34:15 -!- davazp [~user@92.251.170.90.threembb.ie] has quit [Remote host closed the connection] 15:46:36 -!- chris_l [~quassel@p5091E4BF.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 15:53:29 Fare [~fare@c-68-81-138-209.hsd1.pa.comcast.net] has joined #sbcl 16:21:57 -!- Fare [~fare@c-68-81-138-209.hsd1.pa.comcast.net] has quit [Ping timeout: 252 seconds] 16:27:30 Fare [~fare@68.81.138.209] has joined #sbcl 16:39:19 attila_lendvai [~attila_le@92.47.254.186] has joined #sbcl 16:39:19 -!- attila_lendvai [~attila_le@92.47.254.186] has quit [Changing host] 16:39:19 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:55:47 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 17:06:16 Krystof: do you have plans for a freeze, or can I break stuff? ;) 17:07:13 lp 1070635 17:07:13 https://bugs.launchpad.net/bugs/1070635 17:17:22 that's a trivial fix. 17:24:30 -!- LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has quit [Quit: Leaving.] 17:31:22 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:41:34 btw, can some sbcl developer upgrade asdf to 3.0.3 ? it has many meaningful bugfixes. 17:43:34 lmj` [~lmj`@c-71-192-48-197.hsd1.ma.comcast.net] has joined #sbcl 17:48:10 There's some interesting behavior in my multi-core benchmarks. Making a function name 3 characters longer results in almost 10% speedup. 17:48:40 Just a curious coincidence with cache boundaries or something, I suppose. 17:48:59 lmj`: does (disassemble) show a difference? 17:49:31 disassemble on the function? No, the name is the only thing being changed. 17:49:32 ISTR that SBCL pads to 64 bytes anyway. 17:49:44 This is 32-bit sbcl linux. 17:51:20 -!- yacks [~py@103.6.159.103] has quit [Ping timeout: 260 seconds] 17:52:45 lmj`: running gc a couple times can help too 17:53:31 pkhuong: I run gc several times between each benchmark trial 17:53:41 ok. 17:53:43 It's reproducible, at least on my machine. git clone git://github.com/lmj/lparallel ; (ql:quickload :lparallel-bench) (lparallel-bench:execute 4 'bench-pfib) ; remove "-xx" in src/kernel/core.lisp to get 10% slowdown 17:54:11 not in quicklisp yet 17:54:34 (assuming clone into local-projects, of course) 17:57:46 Perhaps it's just that gc behavior happens to be different with that particular benchmark. 17:58:33 I'd be interested in hypothetical reasons. 17:59:08 lmj: alignment changes can also affect a benchmark, if a longer name makes thing bad 17:59:43 lmj: what if you make the name say 35 characters instead of 3 ? 18:00:22 lmj`: alignment sounds likely. 18:00:34 especially if it doesn't happen on x86-64. 18:00:41 Fare: it was a step function; the 3 added characters just take you across the step 18:01:01 I haven't tried on x64 18:01:09 But you can probably compensate for that by moving the IF inside the LET and avoid the redundant specials lookup. 18:01:22 lmj: does it get slower again if you add 7 chars instead? 18:01:29 or 11? 18:02:14 Fare: there's some length X. Shorter than X is one timing, longer than X is another. 18:03:01 lmj`: Fare's trying to determine if there's another transition point Y > X. 18:05:37 pkhuong: re the LET, the aim was to optimize the fast path; when the special is non-nil then speed is less important 18:06:32 lmj`: binding a value lexically doesn't translate into any code. 18:06:36 Fare: I haven't investigated apart from just the one step -- there could be another critical length, I don't know 18:08:10 pkhuong: on all platforms? I figure some would at least increment a stack pointer? 18:10:08 lmj`: no? A binding in itself doesn't exist. 18:10:18 It's just giving a name to a value. 18:16:42 pkhuong: ok, but is there some case (not this one) where LET is translated to a stack variable? Like a highly-optimized fixnum binding? 18:17:28 if register allocation spills. 18:18:07 but that could also happen for anonymous temporary values. 18:19:30 the potential downside of performing common subexpression elimination is that it lengthens live ranges and increase register pressure. In your case, there's nothing happening between the IF and the LET, so there is no change to the live range. 18:21:39 there are also other even more marginal considerations, like potential for source-to-source rewriting. 18:32:51 pkhuong: isn't there an instruction to store the value of the special lookup? 18:33:27 pkhuong: I was using 'stack variable' in a loose sense. Whether a local variable in C is in a register or not, I call it a stack variable. 18:35:56 pkhuong: I thought I had frozen 18:36:32 and yet, clearly the mail did not get through 18:36:34 I wonder where it is 18:37:01 sbcl-devel@lists.sourceforeg.net 18:37:04 well crap 18:44:07 Krystof: the freeze mail got through now. 18:46:24 yacks [~py@103.6.159.103] has joined #sbcl 18:52:33 well yes now I resent it 18:52:56 (re-sent, not feel deeply annoyed about) 18:53:05 gotcha. 18:55:07 does the current frozen sbcl include a fix for https://bugs.launchpad.net/asdf/+bug/1225898, BTW? 18:55:29 yes, that's ASDF, but SBCL has ASDF included, right? 18:56:50 sbcl hasn't upgraded to asdf 3.0.3 yet 18:56:59 I don't think it will happen during this freeze 18:57:11 hopefully after the freeze 18:57:23 in the meantime, upgrade your asdf 18:57:30 and sorry for the bug 18:58:09 Fare: please don't apologize! 18:58:22 bugs are something software people have to live with. 18:58:53 I produce (and distribute) enough of them, too. 18:59:16 Fare: do compile-op and other ops currently work as expected? It doesn't seem right, but maybe I misunderstand them https://gist.github.com/lmj/7af84c9e3f23e2aa746d 18:59:40 lmj: question for #lisp 19:01:02 is there buffering for stdout vs stderr? 19:02:05 are you running in slime or some such that does such buffering? 19:02:19 what if you arrange for all those streams to be one and the same? 19:03:29 Fare: each message is flushed. I brought it up in #lisp last week; I'll re-ask now 19:05:06 LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has joined #sbcl 19:20:29 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 19:35:37 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 19:40:50 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 19:46:06 lmj`: yes. there is also an instruction to store the value so that it can be compared. 19:46:47 the only way the value of the lookup wouldn't be stored anywhere is if that value weren't used. 19:54:27 pkhuong: so adding the LET would be a slowdown, however minor, to the fast path. I don't care that the slow path is slower without the LET. 19:56:33 This is a competition with multicore GHC Fibonacci, and SBCL now wins substantially. Maybe I'll write a blog post. 19:57:21 CL is also able to properly abstract the function, whereas in GHC one has to write it twice (fast path and slow path). 19:58:19 lmj`: no, it wouldn't. 19:58:42 your whole line of questioning is premised on a flawed performance model. 20:04:37 giving names to temporary values (e.g. conversion to A-normal form) has no effect on the final generated code, unless debugging annotations interfere. 20:07:07 lmj: have SBCL recognize the pattern for fibonacci, and emit code for a polylog fast fibonacci? 20:08:09 Fare: no. 20:18:31 (just kidding... but that's what benchmarks often end up being) 20:36:09 pkhuong: ok, the special value is placed into a register in any case, thus LET has no disadvantage here, right? Using LET reduces the number of instructions by 6, which is a good in itself. 20:36:30 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 20:38:40 With some of these benchmarks I've found that smaller code is faster than inlining/macrology. 20:41:50 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 21:05:02 lmj: "sbcl lets me use inline assembly!" 21:38:34 -!- lmj` [~lmj`@c-71-192-48-197.hsd1.ma.comcast.net] has quit [Quit: Lost terminal] 21:48:58 -!- Fare [~fare@68.81.138.209] has quit [Ping timeout: 268 seconds] 22:18:29 -!- prxq [~mommer@x2f6cfac.dyn.telefonica.de] has quit [Remote host closed the connection] 23:09:25 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 23:19:12 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 23:23:15 -!- LiamH [~none@pool-173-73-122-143.washdc.east.verizon.net] has quit [Quit: Leaving.] 23:42:51 -!- oleo [~oleo@xdsl-78-35-170-225.netcologne.de] has quit [Ping timeout: 248 seconds] 23:43:43 oleo [~oleo@xdsl-78-35-154-107.netcologne.de] has joined #sbcl 23:50:47 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Ping timeout: 272 seconds]