01:21:24 -!- Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has quit [Read error: Connection reset by peer] 01:50:32 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 01:55:15 -!- nyef [~nyef@pool-70-20-50-210.man.east.myfairpoint.net] has quit [Quit: G'night all.] 02:25:12 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 02:55:31 rbarraud_ [~rbarraud@118-93-187-226.dsl.dyn.ihug.co.nz] has joined #sbcl 02:56:02 -!- rbarraud [~rbarraud@118-92-25-3.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 255 seconds] 03:03:06 -!- chandler [~n@opendarwin/developer/chandler] has quit [Ping timeout: 272 seconds] 03:03:29 chandler_ [~n@new.unmutual.info] has joined #sbcl 03:05:51 -!- chandler_ [~n@new.unmutual.info] has quit [Changing host] 03:05:51 chandler_ [~n@opendarwin/developer/chandler] has joined #sbcl 03:05:57 -!- chandler_ is now known as chandler 03:21:58 rbarraud__ [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has joined #sbcl 03:24:21 -!- rbarraud_ [~rbarraud@118-93-187-226.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 265 seconds] 03:38:05 -!- rbarraud__ [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 03:40:09 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Quit: Leaving] 04:33:41 -!- The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has quit [Read error: Connection reset by peer] 04:57:53 rbarraud [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has joined #sbcl 05:07:39 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 05:12:40 Jon Smith pasted "array weirdness" at http://paste.lisp.org/display/115292 05:12:50 Not sure what is going on in above paste 05:13:07 but it seems weird that i can use simple vector and not array 05:13:21 is in sbcl 1.0.42 05:13:44 also doesn't work for simple-array, does work for vector 05:28:47 The_Jon_Smith: arrays can be multi-dimensional. Only rank-1 arrays are subtypes of sequence. 05:29:20 hmm 05:29:45 well i'm guessing that isn't consistent across implementations/versions, found that oddity in cleric 05:30:17 -!- rbarraud [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 276 seconds] 06:00:36 rbarraud [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has joined #sbcl 06:33:11 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 07:59:32 Krystof [~csr21@nat65.mia.three.co.uk] has joined #sbcl 07:59:32 -!- ChanServ has set mode +o Krystof 08:37:59 -!- Krystof [~csr21@nat65.mia.three.co.uk] has quit [Ping timeout: 240 seconds] 08:48:08 Blkt [~user@93-33-132-91.ip44.fastwebnet.it] has joined #sbcl 08:51:21 good day everyone! 09:25:21 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 09:32:07 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:45:53 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 09:55:54 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Disconnected by services] 09:55:54 attila_lendvai1 [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 09:55:55 -!- attila_lendvai1 is now known as attila_lendvai 10:38:45 Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 10:39:03 -!- Kaer [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has quit [Client Quit] 10:39:23 Kaes [b@c-cfcee253.97-16-64736c12.cust.bredbandsbolaget.se] has joined #sbcl 10:46:36 -!- rbarraud [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:47:02 rbarraud [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has joined #sbcl 10:52:13 Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has joined #sbcl 10:52:13 -!- ChanServ has set mode +o Krystof 11:03:01 -!- Krystof [~csr21@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has quit [Ping timeout: 252 seconds] 11:18:29 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 11:19:58 Krystof [~csr21@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 11:19:58 -!- ChanServ has set mode +o Krystof 11:34:30 nyef [~nyef@pool-71-255-140-24.cncdnh.east.myfairpoint.net] has joined #sbcl 11:34:39 G'morning all. 11:43:56 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Disconnected by services] 11:43:56 attila_lendvai1 [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 11:43:57 -!- attila_lendvai1 is now known as attila_lendvai 11:50:58 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 11:50:58 -!- ChanServ has set mode +o nikodemus 12:18:11 -!- rbarraud [~rbarraud@118-92-135-151.dsl.dyn.ihug.co.nz] has quit [Read error: Connection reset by peer] 12:25:04 good afternoon 12:30:55 Hello nikodemus. 12:38:18 ccl-logbot [~ccl-logbo@setf.clozure.com] has joined #sbcl 12:38:18 -!- names: ccl-logbot @nikodemus attila_lendvai nyef @Krystof Kaes tcr Blkt mega1 The_Jon_Smith chandler slyrus lnostdal tsuru cmm minion drewc @Xof fe[nl]ix ASau specbot siccegge lisppaste2 deepfire foom angavrilov vs slyrus_ _3b` gnooth jsnell `micro joshe pkhuong luis tokenrove 13:03:58 Lovely. ATOMIC-INCF is broken. 13:08:20 ? 13:08:33 that sounds bad 13:08:59 It's a subtle broken: There's no interpreter stub. 13:09:19 So if you try to use it directly from the REPL while the evaluator mode is :interpret, -boom-. 13:09:45 at least it's easy to fix 13:09:51 Yeah. 13:10:00 I may do that today, since I'm messing with ATOMIC-INCF anyway. 13:10:07 sometimes i wonder if we should have a test that checks for missing stubs 13:10:29 YES! PLEASE! 13:10:45 I lost a -day- to a missing stub last month. 13:12:47 nikodemus pasted "lookee, 14k worth of stupid constant reference functions" at http://paste.lisp.org/display/115297 13:13:36 Heh. 13:14:01 At the same time, unless you fix the closure-docstring thing, wholesale replacement with a closure is contraindicated. 13:14:19 most of those are just (lambda ()), though 13:14:57 It's the ones which aren't just (lambda ()) that are the problem. 13:15:01 yeah 13:15:35 It's a cost of one word, maybe two, per closure, isn't it? 13:15:56 Heck, maybe I'll look into it myself. 13:15:57 right now i'm trying to verify that the 2% core bloat aren't just junk -- if i don't find anything bad, that patch goes in and next i will look into giving closures and info-slot 13:16:12 so that clos slot accessors can have names 13:16:25 and the i'll look into frame cleaning 13:16:37 goal: Better Backtraces 13:17:02 ok. at least my patch doesn't introduce any new ones like this 13:18:44 Heh. I have a couple of "better backtraces" goals myself. 13:19:58 what are yours? 13:20:20 Hrm. Okay, writing an interpreter stub for %raw-instance-atomic-incf/word isn't as obvious as it seems. :-/ 13:20:43 Backtrace from undefined-function, for starters. 13:21:03 Better backtrace of alien stack frames. 13:21:14 -Any- backtrace of alien stack frames on non-x86oids. 13:21:18 Stuff like that. 13:21:22 \o/ 13:21:38 Better Backtraces! \o/ 13:26:54 nikodemus: what's too complex to check on a (the foo (foo)) thingie, even if FOO's return type is not known? 13:27:47 tcr: long story, and i don't have all the details. but: not absolutely too complex, but too complex given the existing framework and reasonable expectation of efficient code 13:29:52 I'm also hoping to get Even Better Disassembly as well. 13:30:35 And, actually, a general improvement in the whole Debug eXperience (DX). 13:31:44 nikodemus: To be fair, jdz is /not/ the first person reporting that test failure. It's been mentioned (and confirmed) multiple times here. 13:32:02 nyef: this is the first i hear of if 13:32:12 it, even. and lp doesn't seem to have it either yet 13:32:22 Mmm. 13:32:34 I have it too, though. 13:32:52 minion: memo for LP: . 13:32:52 Remembered. I'll tell LP when he/she/it next speaks. 13:32:53 then why isn't it on lp? ;) 13:33:05 Oops :-) 13:33:37 Because it's a fairly obvious test failure? 13:33:56 ... You test primarily on x86-64 darwin, don't you? 13:34:46 nyef: yes, but i tested it on random-state.net too, which is linux 13:35:04 at least i thought i did 13:36:20 *nikodemus* builds a new sbcl there 13:38:46 ... umask 0022? 13:39:05 Non-root user, if it matters. 13:46:59 nikodemus pasted "no wonder our code is so big... we have a function like this in the component for every structure constructor" at http://paste.lisp.org/display/115299 13:48:01 What is that allocating? 13:48:37 the structure 13:49:12 So... what's the problem? 13:49:18 Inline allocation is too large? 13:49:21 for inlined constructurs we definitely _want_ it that way 13:49:34 but this is inlined in every out-of-line constructor too 13:50:32 where it probably doesn't win any speed over calling a generic structure allocator with the desired size and layout 13:50:36 Ah. So, a compiler-policy to control inline / out-of-line allocation? 13:50:44 something like that 13:50:55 ... Or that, yeah. Hrm. 13:51:23 The compiler-policy would give that little bit more control to the users, but it's also another knob for the users in the know to worry about. 13:51:25 or just generate the MAKE-FOO differently depending on if it being inlined or not 13:53:44 there are ~280 structure classes 13:54:01 (in a fresh core) 13:54:16 saving 100 bytes for each sounds like a reasonable thing to do 13:59:14 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 276 seconds] 14:02:41 I"m wondering, shouldn't it be possible to store a uint32 unboxed in a slot declared (or uint32 (member :a :b :c)) on a 64bit platform? 14:03:56 no, but it fit in a fixnum so the boxing is cheap 14:04:02 fits, even 14:04:29 Umm... In theory, yes, at the cost of a more expensive accessor, for when the slot value is (member :a :b :c). 14:04:50 But as nikodemus says, boxing is cheap in this case. 14:06:08 true enough 14:08:47 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:56:35 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 14:58:49 This is probably pretty basic, but... Is there an IR1-node type that just assigns one LVAR to another one? 15:01:47 nyef: LVARs aren't ever assigned to 15:02:05 an LVAR is pretty much like a phi-function really 15:02:41 Umm... 15:02:50 execpt it may have 1-n uses, which in IR1 parlance are the value sources, and a "value" may be multiple values 15:03:33 and the dest of an LVAR is where the thing the result of the phi-function is assigned to 15:03:43 does that make sense to you? 15:04:01 Nope, still confused. 15:04:34 I'm looking at this from the perspective of the nonlinear-LVAR bug, btw. 15:04:40 right 15:05:13 when you get into IR2, then LVARs end up having actual storage locations, etc -- which get written into 15:05:50 remember that CMUCL had "continuations", which alexey split into LVARs and CTRANs? 15:06:17 Right, the problem is earlier than that, when IR1-conversion introduces a control path through the function that assigns an LVAR twice. 15:06:21 in CMUCL a continuation represents either the value resulting from a computation, or the control transfer caused by it 15:07:31 And the first assignment to the LVAR is supposed to be "live" until and unless the second assignment kicks in, and not until after the new value is calculated. 15:07:49 right. well, every node in LVAR-USES is responsible for writing its values to the lvar 15:08:03 except that at IR1 level this writing is implicit 15:08:27 So my thought was, have two LVARs, and introduce something to move the value once it's ready. 15:09:26 at IR1 level if would look like a regular function call, i think 15:10:00 ... a BIND node? 15:10:50 hm 15:11:24 actually, i think the conversion that introduces that code-path sounds fundamentally broken 15:11:29 It -is-. 15:12:51 That said, I think the fix is to do this thing with making one LVAR dest one of the uses of a second LVAR. 15:13:20 sounds reasonable 15:14:39 Basically, though, it'd need to introduce a separate block to do this thing, so that the stack analysis doesn't screw things up. 15:15:53 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 15:43:19 does anyone have Nathan's ssh implementation? 15:48:58 rmarynch [~roman@88.135.194.233] has joined #sbcl 15:57:34 nikodemus pasted "finally, i found some of the code bloat... now to figure out why this happens..." at http://paste.lisp.org/display/115304 15:59:25 debug policy / tail-call policy? 16:01:41 possibly. could be the thing where we use policy of the call-site for inlined functions 16:06:08 oh-kay. seems to be a cross-compiler issue -- target produces the same cold as old xc 16:22:21 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 16:36:46 "waiting for root's lock in /cvsroot/sbcl/sbcl"? 16:36:51 WTF? 16:37:43 Oh well, at least it doesn't seem to have broken anything. 16:43:27 nyef: shiny! 16:43:28 Ugh. I keep forgetting up update NEWS. 16:43:54 oh crap. my commit leaked junk into the tree 16:44:27 can you fix my crap from make-host-2.lisp when you update NEWS? 16:44:49 or i can fix it rightaway too 16:44:51 Oh dear. How recent? 16:44:56 And what sort of crap? 16:45:20 sb-xc:proclaim -> proclaim 16:45:26 1.0.43.34 16:45:49 i'll commit a fix as .35 16:46:50 Eek. We didn't collide commits or anything, did we? 16:47:08 *nyef* is waiting for the git gateway to update. 16:47:17 no, but i neglegted to check the diff because i did cvs up -dP due to your changes 16:47:25 Ahh. 16:47:48 Are we keeping the NEWS entries in any kind of sorted order, or just most-recent on-the-bottom? 16:48:06 Right now it looks like all the enhancements are first, followed by the bugfixes. 16:48:58 yeah. i try to keep enchancements in order of sexyness, and bugfixes in a mostly random order. unless i think it needs ATTENTION i just add stuff to the bottom 16:49:11 but i don't think we have an actual _policy_ :) 16:49:32 oversight! 16:49:34 ok. damage fixed 16:50:03 Did you change NEWS recently? 16:52:59 Okay, hopefully this will work... This -should- work... 16:53:20 And done. 16:53:55 how often atomic incf on arrays is used? 16:54:03 I use it. 16:54:11 Never. It's never been supported before now. 16:54:27 i mean incf on arrays 16:54:41 Dunno? 16:54:43 so that the atomic incf will make the difference 16:59:30 It's more a matter of opening up options for lock-free multithreaded synchronization. 17:00:50 stassats: I've had to fake it with a VOP before. 17:02:07 stassats: i use INCF on arrays for some ray/hit/shadow counters in my raytracer 17:06:51 So, it's not an unuseful feature. 17:08:39 but what about calculating offsets and checking boundaries, etc., on (setf (aref array x) (process (aref array x))), is that done once? 17:09:41 Some amount of it would be covered by type derivation, surely? 17:11:32 well, the way i use it up personally is so that the bounds are statically know so that no bounds-checking is needed at runtime 17:12:25 nyef: you know what would be neat? (setf (aref v i) (logand word-mask (+ (aref v i) delta))) transformed into an unlocked xadd :) 17:14:03 I'll take that under advisement. 17:17:41 -!- rmarynch [~roman@88.135.194.233] has quit [Quit: Leaving] 17:25:31 -!- Blkt [~user@93-33-132-91.ip44.fastwebnet.it] has quit [Ping timeout: 240 seconds] 17:50:31 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 17:51:04 So, yesterday morning (my time), froydnj asked about inline-constant fixups, with rationale and everything. I provided a patch at about the same time he disappeared. Should I commit it anyway, or leave it? 17:51:09 tcr1 [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 17:52:04 who are you asking? 17:52:15 Anybody? 17:52:36 *nikodemus* goes for the logs 17:54:28 do you have any performance or code-size numbers? 17:54:35 Nope. 17:54:45 But losing the extra register load can't be all bad. 17:55:01 core-size? 17:55:31 Nothing. I made it go, I didn't check the various effects. 17:56:02 I guess I could commit the bits that let it happen, but not the bits that use it. 17:56:12 well, if it doesn't blow up the core and has a positive or neutral effect on performance, it sounds like a good idea 17:56:34 Just adding the support bits can't screw things up too badly, really. 17:56:40 point 17:56:51 but unless they are used, it's just more dead code 17:57:06 You mean like the :LOAD-TN option for VOP arguments? 17:57:14 yeah :) 17:57:25 (Which I've actually figured out how to use.) 17:57:32 iirc assembler has all sorts of stuff too that isn't used 17:57:50 you should write a define-vop guide some day :) 17:58:00 Probably. 17:58:14 I actually found myself wanting tool support for tweaking a VOP earlier today. 17:59:00 Just being able to have something I can run in emacs while within a VOP definition to see the argument lifetimes would be great. 18:01:22 but, regarding the fixup thing. it sounds like a good thing, but i would check the actual effects at least briefly first: compare core sizes and self-build times, and maybe time a few loops that call generic-arith routines with small fixnums 18:02:18 Mmm. I should probably do something about installing a micro-benchmarking reflex. 18:02:40 i think we need a bench/ directory in the cvs 18:02:48 There you go! 18:03:11 An easy-to-run set of benchmarks? 18:03:31 even just a place to store all the microbenchmarks would be a start 18:04:18 but an actual framework building on top of call-with-timing would be really neat 18:04:38 nikodemus: yeah. I've rewritten half of such a thing a dozen times. 18:05:08 pkhuong: The same half each time? 18:05:09 hm. i wonder if the framework should actually be a contrib 18:05:17 nyef: sadly, yes. 18:05:26 so that people could use it to benchmark their own stuff too 18:05:28 nikodemus: i think so. 18:05:30 right. 18:06:23 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 18:06:56 hey, here's a thought: we can try this collaborative git thing on that before putting it in the cvs 18:24:40 -!- tcr1 [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 18:25:32 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 19:29:04 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 20:00:51 slyrus__ [~chatzilla@dsl092-019-253.sfo1.dsl.speakeasy.net] has joined #sbcl 20:02:50 pkhuong_ [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 20:03:37 cmm- [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 20:04:43 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 245 seconds] 20:06:40 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Ping timeout: 240 seconds] 20:06:41 -!- specbot [~specbot@common-lisp.net] has quit [Ping timeout: 240 seconds] 20:08:14 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [*.net *.split] 20:08:14 -!- minion [~minion@common-lisp.net] has quit [*.net *.split] 20:08:14 -!- slyrus [~chatzilla@dsl092-019-253.sfo1.dsl.speakeasy.net] has quit [*.net *.split] 20:08:14 -!- lisppaste2 [~lisppaste@common-lisp.net] has quit [*.net *.split] 20:08:14 -!- siccegge [~siccegge@faui49j.informatik.uni-erlangen.de] has quit [*.net *.split] 20:10:05 minion [~minion@common-lisp.net] has joined #sbcl 20:10:05 siccegge [~siccegge@faui49j.informatik.uni-erlangen.de] has joined #sbcl 20:10:05 lisppaste2 [~lisppaste@common-lisp.net] has joined #sbcl 20:12:26 http://github.com/nikodemus/sb-bench # it's a start 20:14:08 depends-on alexandria? 20:14:20 mean and standard-deviation 20:14:32 i didn't bother to copy-paste them just now 20:14:52 Fair enough. 20:15:41 Nice start, certainly. 20:16:22 the next big thing would be saving results and comparing them 20:19:57 I think the default should be a dynamic number of iterations, so that even small benchmarks run for a sensible time 20:21:31 e.g. time one iteration of the benchmark, then run n iterations such that the expected runtime is e.g. 2 seconds 20:22:30 and then report time per iteration (or iterations per second, or whatever looks nice) 20:28:59 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:38:49 specbot [~specbot@common-lisp.net] has joined #sbcl 20:41:15 jsnell: i'm not sure it's the right way, actually 20:41:48 if the benchmark takes too little time, then function calls are just going to dominate 20:47:49 what I thought was that (defbenchmark foo ...) would expand to (defun foo (iterations) (dotimes (i iterations) ...)). so there would just be the loop overhead per iteration 20:48:24 that might work, yeah 20:48:28 and it'd dynamically scale the iterations to pass in based on some kind of a warmup run 20:48:42 let me see... 20:51:50 attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has joined #sbcl 20:53:55 jsnell: i'm not sure how to code that without introducing iefficiencies while preventing the compiler from flushing the loop body 20:54:45 `(let (result) (loop repeat iter do (setf result (progn ,@body)))) ; simple but misses the type-information for result 20:55:07 is it any different from what you'd have with :open-code? 20:56:00 jsnell: in case of OPEN-CODE it is the responsibility of the benchmark writer to ensure results are used 20:56:26 but it DEFBENCHMARK macro introduces a loop, i at least have a harder time to reason about it 20:56:35 and why does type inference of the result matter? and don't say boxing :-) 20:56:50 boxin^W mmm 20:57:28 since if say boxing that double-float is going to matter, it would also have mattered for the function version 20:58:19 but that boxing can be eliminated by declaring the type for a local -- so it makes hard to write microbenchmarks that test what they are supposed to test 20:58:45 what if each benchmark was just required to have a "scale" argument as the first one? 20:59:11 with define-simple-benchmark adding it magically and introducing the loop silently? 21:00:11 oh cool sb-bench is something that crossed my mind half a year ago 21:01:03 I don't understand how declaring types would help 21:01:12 Did you sneak that up from some #lisp discussion? :-) 21:01:47 (defbenchmark foo () (let ((sum 0d0)) (declare (double-float sum)) (dotimes (i 100 sum) (incf sum 1d0))) is going to have the same boxing behavior with the loop case and with the function case 21:02:57 yes 21:04:01 i was going for a but, ... but actually, yes :) 21:04:16 getting too late here obviously 21:05:48 anyway, the whole automatic scaling is just an idea. I hate hate hate the cl-bench defaults 21:17:06 -!- attila_lendvai [~attila_le@4d6f5d3b.adsl.enternet.hu] has quit [Quit: Leaving.] 21:17:10 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 255 seconds] 21:40:39 jsnell: aroundp 21:40:55 yes 21:41:37 i think i have something along the lines you suggested 21:42:01 submitted? 21:43:45 pushed 21:48:27 ooh, didn't realize github has a code review thingy in the diff view 21:48:34 it has? 21:49:14 yeah, click on a commit id, and then when you mouseover a line in the diff view, there are little comment buttons on the left 21:49:18 oh, i see! 21:49:40 of course I don't have a github account so I can't use that right now :-) 21:50:13 hah 21:50:32 github is the new backup :) 21:50:48 anyway, that looks very nice 21:51:23 ok, now we just need result storage & comparisons & fancy html output :) 21:51:24 I'm a bit doubtful about that manual loop unrolling though :-) 21:51:44 jsnell: for microbenchmarks i've really seen it matter 21:51:54 fair enough 21:52:12 but possibly for real microbenchmarks people should do that by hand with OPEN-CODE 22:10:57 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 22:11:07 -!- deepfire [~deepfire@80.92.100.69] has quit [Quit: ircII EPIC4-2.10.1 -- Are we there yet?] 22:19:07 -!- specbot [~specbot@common-lisp.net] has quit [Ping timeout: 240 seconds] 22:22:58 deepfire [~deepfire@80.92.100.69] has joined #sbcl 22:31:09 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 22:36:01 -!- Krystof [~csr21@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Ping timeout: 252 seconds] 22:47:57 rbarraud [~rbarraud@118-93-161-252.dsl.dyn.ihug.co.nz] has joined #sbcl 23:14:01 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Ping timeout: 265 seconds] 23:22:18 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 23:51:35 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.]