00:47:15 rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has joined #sbcl 00:59:23 -!- hargettp [~anonymous@pool-71-174-140-140.bstnma.east.verizon.net] has quit [Quit: hargettp] 01:02:17 -!- Fare [~Fare@ita4fw1.itasoftware.com] has quit [Ping timeout: 276 seconds] 01:09:22 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 01:14:10 Fare [~Fare@63.107.91.99] has joined #sbcl 02:33:33 -!- rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 03:11:07 stassats [~stassats@wikipedia/stassats] has joined #sbcl 03:15:36 rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has joined #sbcl 04:11:13 -!- rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 252 seconds] 04:12:02 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 04:43:59 rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has joined #sbcl 04:49:42 -!- Fare [~Fare@63.107.91.99] has quit [Ping timeout: 272 seconds] 05:01:45 Fare [~Fare@ita4fw1.itasoftware.com] has joined #sbcl 05:19:18 -!- JonSmith [~jon@c-98-229-249-43.hsd1.ma.comcast.net] has quit [Ping timeout: 245 seconds] 05:22:32 JonSmith [~jon@c-98-229-249-43.hsd1.ma.comcast.net] has joined #sbcl 05:23:04 -!- JonSmith [~jon@c-98-229-249-43.hsd1.ma.comcast.net] has left #sbcl 09:38:49 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 09:38:49 -!- ChanServ has set mode +o nikodemus 10:44:22 tcr [~tcr@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has joined #sbcl 10:48:53 -!- tcr [~tcr@cpc1-bour2-0-0-cust414.15-1.cable.virginmedia.com] has quit [Ping timeout: 245 seconds] 10:55:07 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 11:10:18 Blkt [~user@net-93-151-225-193.cust.dsl.teletu.it] has joined #sbcl 11:10:36 good evening everyone 11:10:50 err, afternoon 11:18:37 afternoon 11:18:42 hi 11:18:52 may I bother you for a second? 11:19:03 sure 11:19:23 could you tell me what are the main differences between SBCL 1.0.11 and 1.0.42? 11:20:03 I know it sounds odd, but Google AI Challenge organizers found 1.0.11 packaged for their distribution and were not willing to change it unless we give good reasons 11:20:44 I'd start by reading the NEWS file 11:20:49 I did 11:20:58 -!- `micro [~micro@www.bway.net] has quit [Ping timeout: 245 seconds] 11:21:29 I took a few changelogs with some huge optimizations, like SUBSEQ and COPY-SEQ optimizations 11:22:09 31 one months of development... let me find a few standouts 11:29:58 attila_lendvai [~attila_le@adsl-89-134-30-105.monradsl.monornet.hu] has joined #sbcl 11:33:58 I'll be back in a few minutes 11:40:01 -!- rbarraud [~rbarraud@118-92-15-104.dsl.dyn.ihug.co.nz] has quit [Ping timeout: 252 seconds] 11:41:34 So, now that I have this huge SSE contrib (api-compatible with the ECL one), what do I do with it? :) 11:41:40 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 11:51:13 Blkt: aie! i tried to filter the list down important bugfixes, but i give up -- i only got from .42 to .23, and the list was already massive but i'm not sure how obvious it is to other people that many of those fixes are imo critical 11:51:22 ASau [~user@83.69.227.32] has joined #sbcl 11:51:29 Hello! 11:51:34 I need hint, 11:51:50 how can I make SBCL recompile FASLs after by default? 11:52:04 after update 11:52:12 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 11:52:38 Blkt: perhaps the most important argument in favor of a relatively recent sbcl is that anyone running 1.0.11 and having trouble is going to be asked to upgrade pretty much the first thing 11:53:46 1.0.11 is sufficiently old that sbcl hacker's can't remember half the bugs that been fixed since, and are likely to give outdated advice -- referring to enhancements not present in 1.0.11, etc 11:55:01 ASau: http://paste.lisp.org/display/114672 11:55:26 nikodemus: thank you 12:05:33 thanks nikodemus 12:05:48 would you mind if I post the logs of this conversation? 12:22:10 Blkt: not at all. actually, i started on a shorter list though -- i'll have it ready soon 12:37:46 Blkt: http://paste.lisp.org/display/114673 12:43:00 thanks, that was very usefull 12:45:08 now it's up to us to make good publicity to SBCL during the contest 12:52:19 good luck! 13:05:00 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:27:16 rmarynch [~roman@bras-11-ge-62.122.200.238.utm.if.ua] has joined #sbcl 13:27:31 Why doesn't sbcl parse /proc/ for getting a good value for the dynamic space size? 13:28:04 what do you mean? 13:29:15 what if you hot-plug in another 32 gigs of memory while your long-running lisp session is, uh, running? :) 13:29:56 What then? 13:30:34 I'm talking of calculating the initial value 13:31:06 oh, it can be changed dynamically? /me is so out of date 13:31:15 it can't, not right now 13:31:28 david has a patch for it, though 13:31:46 tcr: what do you want to calculate the initial value from? total available vm? 13:31:51 cmm: I'm not talking of changing it dynamically 13:33:28 nikodemus: Perhaps. I don't know. I'm just wondering and growing tired of running out of heap because the default value is so small 13:34:46 tcr: i don't think there is a sane way to guess. maybe there is, but i have no idea what it might be 13:35:18 but getting david's GC patches in would make life better for you, since they allow extending dynamic space at runtime 13:36:53 What does it make difficult to guess? I'm setting it to 2/3 of available ram manually 13:38:35 tcr: well, write a patch and send it to the list for discussion. i don't really know -- i can't say i've thought much at all about the issue before now 13:41:40 there's more important stuff to do :-) for example if I want to smash a header for a (simple-array (unsigned-byte 8)) in front of a sap, what would be a good starting point? 13:45:10 allocate-static-vector should have code you can steal 13:47:44 excellent 14:11:13 -!- rmarynch [~roman@bras-11-ge-62.122.200.238.utm.if.ua] has quit [Quit: Leaving] 14:36:39 micro_ [~micro@www.bway.net] has joined #sbcl 14:37:09 -!- micro_ is now known as micro- 14:41:29 -!- attila_lendvai [~attila_le@adsl-89-134-30-105.monradsl.monornet.hu] has quit [Ping timeout: 265 seconds] 14:48:11 attila_lendvai [~attila_le@adsl-89-134-30-105.monradsl.monornet.hu] has joined #sbcl 15:02:14 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 15:25:19 How can I make the contrib build only if sse is enabled in the core? 15:27:57 angavrilov: good question. we don't really have a conditional-contrib setup at all 15:29:36 Today I've reached API compatibility with my ECL contrib, so I wonder what should I do next? 15:29:51 angavrilov: option #a: make the contrib build and test without sse, but signal an error at runtime. option #b: make a portability layer so the contrib's API works on non-sse ports as well 15:30:25 It's whole api is wrapping around sse instructions, so there is no point in in without them 15:30:29 (or figure out a sane way to specify some contribs as limited to some ports) 15:31:13 angavrilov: then maybe it should not be a contrib? 15:31:42 It's 2MB in total fasl size (btw I wonder where all that comes from...) 15:32:10 it could be in the core as well, i think. it needs its own package still, obviously, but i expect that we might want to use more sse stuff internally as well 15:32:46 angavrilov: next step: end in the patch! 15:35:29 It's based on top of pkhuong's code from last December 15:43:38 How do you find this api description? http://github.com/angavrilov/sbcl/commit/b8ced8716a3336b061001bb2e26e60ae3822045e 15:44:12 For some reason github doesn't want to show texinfo files when not in diff mode. 15:51:00 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 16:03:09 I wonder why an alignment violation causes sbcl to report 'memory fault at 0'?.. 16:09:55 nitpicks: x86-sse is a bad name for something that works on x86-64 only 16:10:13 plain sse or sb-sse seems better 16:12:12 a lot depends on what the longer-term maintenance plan is 16:13:24 nikodemus: fyi, an older patch by fe[nl]ix: http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=commit;h=b29d1492d81da16c05bf856f38ca1791ec06f8b2 16:14:09 (ECL references, package naming, etc.) but at a glance the docs look good. a few examples would be good, though 16:15:32 attila_lendvai: i'm aware of it -- but it breaks serve-event 16:16:26 i have one more to come in the poll/select/serve-event series today or tomorrow 16:16:37 nikodemus: our servers are running with that patch, i didn't notice anything. but it's also a FYI only... i don't have any attachment to that path 16:16:51 you don't use serve-event, though, do you? 16:16:54 s/path/patch/ 16:17:01 not directly 16:18:07 the patch that is coming up uses poll there when it's ok to do so -- when there are no handlers on other streams, and when there are no periodic polling functions, etc 16:18:36 linux/epoll stuff i'm leaving for later 16:28:20 nikodemus: On ECL it should work whenever enabled, but obviously sse code would crash if used on a cpu that doesn't support it. Paul chose 64-bit only for sbcl because 1) it is guaranteed to have sse, 2) heap objects are already properly aligned 16:29:27 angavrilov: sooner or later we well have SSE for x86 as well, though 16:29:46 but naming is a nitpick, like i said 16:30:21 maintenance plan is more important, imo. is the intention to maintain the ECL and SBCL versions separately, or in a single master tree? 16:30:39 I actually called the contrib sse at first (see the package nickname too), but then renamed to x86-sse 16:31:15 This code is a thin wrapper around the underlying instructions (essentially, a compiler plugin), so there is very little code that can be shared between implementations. 16:31:54 i *suspect* that we really want to use intrinsics internally as well, though, so eventually having it as a contrib will cause trouble 16:32:05 JonSmith [~jon@c-98-229-249-43.hsd1.ma.comcast.net] has joined #sbcl 16:32:06 But on the other hand the api is determined by the same instructions, so there is little place for future enhancements too. 16:32:17 hi 16:32:29 hi there 16:32:52 angavrilov: but a patch on the mailing list might be the best context for hashing the details out 16:34:00 Maybe a set of patches? Understanding everything at once may be more difficult. Plus, there are Paul's own commits, which I didn't touch other than by resolving a few trivial merge conflicts. 16:34:24 patch or a series -- either is fine, whichever seems clearest 16:34:30 Although, there are some my commits that fix bugs in his code. 16:34:42 here's my plan: only patch in support for sse values 16:34:54 and (dis)assembler definitions 16:35:07 And I have fixed a few problems in his instruction definitions (already committed code) 16:36:22 pkhuong: ? 16:36:34 The rest doesn't need to be baked in, and, for optimization purposes, it'll probably be clearer to define specific VOPs (that do have sse packs as arguments and return values) anyway 16:37:03 So a contrib for the rest of stuff is fine? 16:37:47 sure. 16:38:20 sorry, i came in a little late, is this about using packed instructions? 16:38:51 -!- Blkt [~user@net-93-151-225-193.cust.dsl.teletu.it] has quit [Ping timeout: 265 seconds] 16:39:13 talking about angavrilov's work on sse stuff for sbcl 16:39:17 JonSmith: it's about exposing SSE packs (128 bit short vectors) as first class values. 16:39:22 pkhuong: Here is my branch: http://github.com/angavrilov/sbcl/commits/sse/ 16:39:44 pkhuong's plan sounds good to me 16:40:13 pkhuong: What should I do with your experimental code at the base of my patches? 16:40:55 i would prefer to name the contrib sb-sse, though, unless we are explictly trying to be compatible with ecl, in which case i think there should be a separate master from which both ecl and sbcl can pull the API stuff 16:41:16 agreed on the separate master 16:41:38 once support is in the compiler/runtime, the rest is just a regular library. 16:41:54 Only it heavily leans on the compiler internals... 16:41:59 common-lisp.net project that we include as a contrib? 16:42:14 sure; so does sb-cga. 16:42:50 angavrilov: that's why I'm interested in getting the very low-level interface right. Once that's fixed, depending on internals is fine. 16:43:06 oh ok that's cool 16:43:13 Could you make good use of sse for sequence matching? Should it really be a contrib? 16:43:55 Currently it weight 2MB in fasls and exports 338 symbols 16:44:02 I sometimes would have liked to use stuff from sb-introspect in parts of sbcl itself but couldn't because it's a contrib 16:44:02 tcr: only the part that exposes sse instructions as functions would be a contrib. 16:44:59 SSE can be used to speed up SEARCH, but it's a bit heavy, and you need > SSE2 16:45:45 I'd try something simple like rabin karp first... 16:48:25 on a slightly different topic, has anyone given thought to vectorizing math instructions on 64 bit? 16:48:47 pkhuong: could be used to speed up FIND and POSITION 16:49:21 pkhuong: also REPLACE or FILL if we ever get crazy enough to write our own assembly versions 16:49:30 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:49:42 JonSmith: there has been some work on generating vector code for MAP and friends 16:51:12 and complex arithmetic uses SSE2 now. 16:54:11 hargettp [~anonymous@pool-71-174-130-208.bstnma.east.verizon.net] has joined #sbcl 16:54:46 This file can probably be augmented with information that'll make it usable for ECL, but other code is pretty much separate by necessity: http://github.com/angavrilov/sbcl/blob/sse/contrib/x86-sse/intrinsics.lisp 16:56:58 I have to get a draft article out by tonight, but I'll try to go through your patches, review and commit those I feel should be in the core. 16:57:12 probably around wednesday or thusday 16:57:57 What I have doubts about, is whether is it completely correct to make objects EQL-by-value when they are not typep number 16:58:59 That patch had to tweak quite a lot of places for the specific reason that they assumed this property, and I cannot be certain that's all there is. 17:26:06 so what i was thinking about was 17:26:19 I wonder what is more disruptive: a non-number type with EQL, or a non-real non-complex subtype of number... 17:26:53 if you do a disassembly of the C nbody, and a disassembly of the lisp nbody on the 'computer language benchmarks game' 17:27:05 (which i know is not a good metric to go by) 17:27:40 the main difference is that C nbody uses more pd instructions, Lisp uses all sd instructions 17:29:25 so it might be possible to do some graph analysis and figure out when there are (for example) math instructions that would take advantage of being vectorized 17:30:40 The way I'm going to use my sse library is a lot simpler: a macro that expands into a vectorized loop. The burden of proof that this is correct is on the user =) 17:36:35 that seems like a good goal 17:37:45 would be cool as a compiler macro 17:42:04 JonSmith: the C and C++ versions of NBODY use SSE intrinsics directly 17:42:53 that doesn't seem fair 17:43:31 fair's got nothing to do with it 17:43:50 hmm :-/ 17:44:09 it still seems like something that could be done to me 17:44:13 almost anything goes in the shootout 17:44:27 there are even algorithmic differences there sometimes 17:45:00 no reason why the sbcl version could not use intrinsics on x86-64 once pkhuong and angavrilov are done 17:55:59 I wonder if there is an accepted name for an 'if' function, i.e. something that evaluates both branches, and then discards one value?.. 17:56:43 Since SSE instructions can only express such a function, auto-vectorizers in compilers tend to bail out on conditionals - even if a function would be actually acceptable. 18:18:56 autovectorizers can handle conditionals just fine 18:21:25 angavrilov: I call that select. 18:21:36 re EQL, that can be fixed much later. 18:21:44 it's not like SAPs are EQL either. 18:28:54 froydnj: I remember unsuccesfully trying to make gcc vectorize a loop with a ?: inside. Admittedly, it was a long time ago, and it is likely to have improved. 18:29:57 pkhuong: some kind of comparison is necessary for identifying special sse constants like 0, and coalescing identical immediates 18:34:25 -!- attila_lendvai [~attila_le@adsl-89-134-30-105.monradsl.monornet.hu] has quit [Quit: Leaving.] 18:39:53 -!- JonSmith [~jon@c-98-229-249-43.hsd1.ma.comcast.net] has left #sbcl 18:40:52 angavrilov: gcc is smarter now, though there are safety considerations (e.g. trapping memory accesses) involved in vectorizing conditionals 18:48:28 -!- Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has quit [Ping timeout: 252 seconds] 18:50:53 angavrilov: convert to a bignum and use EQL. 18:51:06 same as SAPs 18:52:25 is there a benefit from making sse-values and saps EQL-comparable? 18:52:56 an indistinct feeling of it being TRT? 18:53:14 the compiler has a few optimizations that assume only EQL is different from EQ only for non-fixnum numbers 18:53:29 which is often easy to prove 18:54:42 would the type of eq-comparable things really become much more complex? 18:54:56 maybe not 18:55:06 FWIW, I'm also a fan of losing the invariant that EQ = EQL for fixnums 18:55:07 what's the cost for EQL? 18:56:00 depends on how we implement it. The simplest implementation adds a case in generic-eql and a couple transforms. 18:57:44 reading CLHS EQL, it seems to be pretty clear that only characters and numbers are allowed to be EQL when not EQ 18:59:24 does any of the standard equality predicates allow non-EQ comparisons for non-standard types? 19:00:50 nope 19:01:18 then *I* wouldn't feel so bad about doing non-standard things for non-standard types. 19:01:44 but i think adding a specific case for a non-standard type to EQUAL would be less surprising 19:02:03 In ECL foreign pointers are EQUAL, but in CCL they are EQL 19:02:26 Krystof [~csr21@84-51-132-95.christ977.adsl.metronet.co.uk] has joined #sbcl 19:02:26 -!- ChanServ has set mode +o Krystof 19:02:44 Krystof! just the man we were looking for! 19:04:21 Of course, in ECL the pointers are UFFI style, and carry an additional type tag; that may make them feel inappropriate for EQL. 19:08:00 anyways, i'm not dead set against tweaking EQL, but i'm not convinced it is right either 19:08:34 then again, i mostly use EQL to compare numbers when one of the values may also be NIL 19:09:27 What I think is definitely wrong is individually tweaking every place that assumes that eql means number, to include sse packs or saps. That knowledge has to be centralized somehow. 20:16:34 ok, interesting to see what havoc my serve-event change wrecks... 20:17:42 I'm looking forward to testing clx 20:23:37 I had a thought re. function debug-names 20:24:40 if the name isn't actually FBOUNDP -- and never will be -- like (FLET FOO), (EMF BAR), etc, maybe use a keyword in the CAR: (:FLET FOO) (:EMF BAR), etc 20:27:30 Blkt [~user@net-93-151-225-193.cust.dsl.teletu.it] has joined #sbcl 20:37:30 ASau` [~user@83.69.227.32] has joined #sbcl 20:40:02 -!- ASau [~user@83.69.227.32] has quit [Ping timeout: 276 seconds] 21:12:34 The_Jon_Smith [~The_Jon_S@ip24-250-13-137.ri.ri.cox.net] has joined #sbcl 21:15:10 -!- Blkt [~user@net-93-151-225-193.cust.dsl.teletu.it] has quit [Ping timeout: 272 seconds] 21:56:09 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep]