00:18:13 -!- davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has quit [Ping timeout: 248 seconds] 00:19:43 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 241 seconds] 01:03:54 -!- wbooze [~wbooze@xdsl-78-35-164-34.netcologne.de] has quit [Ping timeout: 252 seconds] 01:29:42 -!- drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has quit [Remote host closed the connection] 01:41:37 Bike_ [~Glossina@67-5-224-154.ptld.qwest.net] has joined #sbcl 01:43:31 -!- Bike [~Glossina@67-5-203-114.ptld.qwest.net] has quit [Read error: Operation timed out] 01:47:56 -!- Bike_ [~Glossina@67-5-224-154.ptld.qwest.net] has quit [Ping timeout: 255 seconds] 01:49:21 drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 01:49:57 Bike [~Glossina@67-5-230-237.ptld.qwest.net] has joined #sbcl 02:26:52 Bike_ [~Glossina@71-222-51-15.ptld.qwest.net] has joined #sbcl 02:28:57 -!- Bike [~Glossina@67-5-230-237.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 02:36:51 -!- Bike_ is now known as Bike 02:38:28 -!- christoph4 [~christoph@ppp-188-174-89-112.dynamic.mnet-online.de] has quit [Ping timeout: 245 seconds] 02:49:41 attila_lendvai [~attila_le@92.47.218.225] has joined #sbcl 02:49:41 -!- attila_lendvai [~attila_le@92.47.218.225] has quit [Changing host] 02:49:41 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 02:51:10 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 02:52:47 christoph4 [~christoph@ppp-188-174-77-82.dynamic.mnet-online.de] has joined #sbcl 03:35:47 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 03:42:11 teggi [~teggi@113.173.3.200] has joined #sbcl 04:21:09 -!- Bike [~Glossina@71-222-51-15.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 04:36:28 -!- drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 04:39:08 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 05:02:16 Bike [~Glossina@71-222-51-15.ptld.qwest.net] has joined #sbcl 05:17:12 pranavrc [~pranavrc@122.174.31.83] has joined #sbcl 05:17:12 -!- pranavrc [~pranavrc@122.174.31.83] has quit [Changing host] 05:17:12 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 05:22:28 Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has joined #sbcl 05:33:59 attila_lendvai [~attila_le@87.247.61.148] has joined #sbcl 05:33:59 -!- attila_lendvai [~attila_le@87.247.61.148] has quit [Changing host] 05:33:59 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:44:34 prxq [~mommer@mnhm-590c153c.pool.mediaWays.net] has joined #sbcl 05:45:48 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 05:51:33 -!- Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 06:28:06 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 06:37:12 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:59:55 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:09:06 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 07:30:57 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 08:02:39 can ptest be used for (eql x 0d0)? 08:02:50 benkard [~benkard@dhcp-138-246-84-173.dynamic.eduroam.mwn.de] has joined #sbcl 08:03:12 hm, it's only SSE4.1 08:12:23 enupten [~neptune@c-24-18-243-195.hsd1.wa.comcast.net] has joined #sbcl 08:14:16 Has anyone else noticed slime-compile-defun broken with the new version of SBCL (or SLIME) ? It doesn't seem to compile things in the right package anymore for some odd reason. 08:19:32 enupten: that can't be true 08:19:39 something else is broken for you 08:20:13 or your expectation of what is the right package are different 09:23:50 stassats: Hmm, I should check my installation. 09:39:35 -!- benkard [~benkard@dhcp-138-246-84-173.dynamic.eduroam.mwn.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 10:03:56 *stassats* can't decide what's better: http://paste.lisp.org/display/137557 10:04:24 size is the same, but no jumps 10:18:35 is there a replacement for the now gone sb-vm::vector-total-size? 10:20:13 attila_lendvai: does this http://paste.lisp.org/display/137558 do what it did? 10:20:39 size would be the third value 10:21:14 stassats: to be hones, I have no idea without digging up the old deleted definition. but I've found sb-vm::array-total-size and staring at it 10:22:03 well, you were using it for something, does this do what you expect? 10:25:33 stassats: I wish it was that simple... :) I've added your suggestion in a comment, used array-total-size, and we'll see. it's not a crucial part, just some statistic gathering do debug memory usage. thanks for the hint! 10:25:53 (it's works not only for vectors) 10:46:14 -!- scymtym_ [~user@ip-5-147-122-209.unitymediagroup.de] has quit [Ping timeout: 256 seconds] 11:19:21 -!- enupten [~neptune@c-24-18-243-195.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds] 11:20:03 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:39:25 drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 12:38:36 benkard [~benkard@dhcp-138-246-84-78.dynamic.eduroam.mwn.de] has joined #sbcl 12:44:33 -!- scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 12:45:43 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:47:46 davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has joined #sbcl 12:55:03 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 252 seconds] 12:56:42 -!- drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 12:57:49 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 13:00:58 Hi all. I'm one of the GSoC students. 13:01:00 I'm looking at the IR1 right now Is the IR1 the same thing as what the Python paper calls ICR (implicit continuation representation)? 13:01:15 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 13:02:08 drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 13:05:36 looks like, looking at the "Compiler Overview" chapter, the files for ICR sections are ir1 13:06:28 -!- davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has quit [Ping timeout: 256 seconds] 13:06:41 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 13:09:48 Ah! I didn't even think of the Design of CMU Common Lisp report. I'm sure it was on my reading list, but I must have lost it somehow. I'll dig into that. Thanks. :) 13:14:29 the index of the cmucl manual says "implicit continuation representation (IR1)" 13:14:34 so, yeah, ICR is IR1 13:15:20 benkard: and which python papers are you talking about? 13:15:22 *stassats* can't find any 13:16:18 http://www.cs.cmu.edu/~ram/pub/lfp.ps 13:16:39 thanks 13:16:40 That's what's linked from http://www.pvk.ca/Blog/2013/04/13/starting-to-hack-on-sbcl/ 13:16:56 you're working on register allocation, right? 13:17:24 No, that's the other person. :) 13:17:38 so, interpretation 13:19:03 Yup. IR1 might or might not be a useful starting point for that. I haven't quite grokked it enough to know. 13:20:46 is that going to be direct interpretation or through bytecode? 13:24:41 I'm planning to experiment with a few approaches, but the Feeley/Lapalme approach (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.90.6978) looks promising, I think. 13:25:28 what does cmucl do? 13:26:52 davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has joined #sbcl 13:29:51 IIUC, it generates bytecode. 13:30:09 I think it can output the bytecode to FASLs, too. 13:33:29 It also bases it on IR1. 13:36:55 wbooze [~wbooze@xdsl-78-35-131-92.netcologne.de] has joined #sbcl 13:53:09 psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 13:54:31 -!- davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] 13:57:56 segv- [~mb@95-91-241-56-dynip.superkabel.de] has joined #sbcl 14:01:55 -!- danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has quit [Remote host closed the connection] 14:08:01 attila_lendvai [~attila_le@95.56.79.25] has joined #sbcl 14:08:01 -!- attila_lendvai [~attila_le@95.56.79.25] has quit [Changing host] 14:08:01 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:39:30 hlavaty` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 14:41:02 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 255 seconds] 14:42:13 slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has joined #sbcl 14:44:49 foreignFunction1 [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 14:44:55 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Read error: Connection reset by peer] 14:45:32 -!- foreignFunction1 is now known as foreignFunction 14:47:37 -!- benkard [~benkard@dhcp-138-246-84-78.dynamic.eduroam.mwn.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 15:02:29 -!- Bike [~Glossina@71-222-51-15.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 15:03:28 Bike [~Glossina@67-5-247-95.ptld.qwest.net] has joined #sbcl 15:04:39 benkard [~benkard@dhcp-138-246-84-78.dynamic.eduroam.mwn.de] has joined #sbcl 15:04:40 Krystof: do I have any paper work to fill out for GSoC, or you do get all the fun? 15:04:55 I don't think you have to do anything immediately 15:05:52 you have to do "midterm evaluations" July 29-Aug 2; everyone has extra paperwork September 23-27 15:06:40 (hi benkard; welcome!) 15:07:25 @Krystof: hi. :) 15:13:40 hello been 15:13:43 benkard: even 15:18:19 hi. :) 15:21:31 -!- teggi [~teggi@113.173.3.200] has quit [Remote host closed the connection] 15:29:51 -!- slyrus [~chatzilla@adsl-108-80-229-231.dsl.pltn13.sbcglobal.net] has quit [Ping timeout: 240 seconds] 15:30:04 leuler [~user@p548F92C1.dip0.t-ipconnect.de] has joined #sbcl 15:30:08 -!- antifuchs [~foobar@boots.boinkor.net] has quit [Ping timeout: 256 seconds] 15:31:59 antifuchs [~foobar@boots.boinkor.net] has joined #sbcl 15:34:32 found the cause of stack allocation problems, i got ref-ordering of PUSH-VALUES somehow wrong 15:47:36 finally, apparent success 15:47:44 ant the core savings are... 768KB 15:47:49 at the first try 15:59:55 nice. 15:59:56 Impressive! 16:02:50 i had to resort to using t-vectors instead of (unsigned-byte 16) ones, once i resolve this, should be more 16:03:04 and i have another couple of slots which can go away 16:03:21 and i need to settle with template/vop-info/vop conventions 16:03:23 it's a mess 16:03:23 hooray, I can add lots more Unicode data tables 16:04:09 there was a function cunningly named "emit-vop", which actually just emitted vops for assembly routines 16:05:15 ah, my kingdom for file-local functions. 16:05:43 i renamed it to emit-assembly-vop 16:05:47 lol. that which stassats giveth, krystof takeths to featureland :) 16:06:52 one thing i can't decide, i changed attribute things to be functions, not macros (because i wasn't expanding to it anymore, but computing at run-time), so now it's (ir1-attributep x 'attribute) instead of (ir1-attributep x attribute) 16:07:13 antoszka_ [~antoszka@unaffiliated/antoszka] has joined #sbcl 16:07:26 mulk [~benkard@dhcp-138-246-84-78.dynamic.eduroam.mwn.de] has joined #sbcl 16:07:27 and is a full call, instead of expanding being optimized, i can make them all INLINE 16:07:49 %ir1-attributep for the function? 16:08:00 and i find (ir1-attributep x attribute) to be clear to the uninitieted, it looks like an ordinary function call, but good luck finding the attribute variable 16:08:08 err 16:08:11 -!- mulk [~benkard@dhcp-138-246-84-78.dynamic.eduroam.mwn.de] has quit [Client Quit] 16:08:14 the uninitiated 16:08:20 and not clear 16:08:51 i found it clear that, say flushable, wasn't evaluated. 16:09:50 i really don't want to have both functions and macros 16:10:08 I'm fine with a functional ir1-attributep 16:10:31 if you're worried about efficiency you could take a leaf out of sb-int:info and have compiler macros for constant attribute names 16:11:17 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 246 seconds] 16:11:17 -!- benkard [~benkard@dhcp-138-246-84-78.dynamic.eduroam.mwn.de] has quit [Ping timeout: 246 seconds] 16:11:17 -!- vi1 [~vi1@93.92.216.186] has quit [Ping timeout: 246 seconds] 16:11:35 davazp [~user@77.225.147.21] has joined #sbcl 16:11:43 yes, compiler macros is what i thought about resorting to 16:11:59 maybe i can just declare them foldable 16:12:19 how would that work? 16:12:42 not for (ir1-attributep x 'attribute), but for (ir1-attributes 'flushable 'foldable) 16:13:15 ah yes. 16:14:38 i don't think that even full-calls would present any problems, though 16:17:03 i only need to find a way to prevent define-vops bodies from being evaluated at cold-init 16:18:07 i already found it to be hard enough to reason about what should go into the cross compiler, what should happen during cross compilation, and what should happen when loading the results of cross compilation, and what should happen at normal run-time 16:18:15 all different needs 16:19:30 i probably need the define-vop macro to be evaluated inside cold-init itself, to get it into shape for redefining vops at run-time 16:20:09 bootstrapping is hard 16:21:30 does anybody redefine storage classes or storage bases at run-time? 16:21:44 stassats: is that even possible? 16:22:18 -!- antoszka_ is now known as antoszka 16:22:30 currently, no, it would sweep all the move-funs away, and you won't be able to proceed getting the move-funs there 16:22:45 but if it were possible, would people do that? 16:24:22 I would... once every five year. 16:24:26 so, not really. 16:25:36 rebuilding is takes just 3 minutes, so, i probably would be ok too, if i wanted to redefine them 16:25:52 speaking of minutes, who can i whine to about a mips failure to build? 16:26:04 (where's nyef?) 16:26:38 after 58 minutes i got failed AVER: (NOT (FUNCTIONAL-HAS-EXTERNAL-REFERENCES-P CLAMBDA)) 16:31:00 stassats: backtrace? 16:33:39 http://paste.lisp.org/display/137561 even though it funnily is during compiling define-vop, it's a HEAD from some days ago, not my define-vop changes 16:38:24 -!- drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 16:39:23 I'm more wondering why it only shows up on mips 16:39:39 does mips enable the scheduler? 16:39:40 (it's a qemu mips) 16:39:53 maybe it's broken in some way 16:40:49 sparc enables the scheduler. 16:40:58 there's a newer version of qemu around, i should try on it too 16:42:19 so, what seems to be happening is something like (lambda ... (return (lambda ...))), and the outer lambda is marked dead, but the internal one is accessible via an xep? 17:08:38 can we somehow make some functions both compute results and be conditional? 17:09:03 to get rid of SUB RSI, 2 _CMP RSI, 0_ JNL L0 17:10:22 well, can have subtract-and-test 17:14:10 I honestly think this one should be done with a post-pass ("peephole"). Because the simplest possible post-pass suffices here: Looking only at one basic block at a time, at the assembly level, and with a simple algorithm to find out which values are alive (assume everything is alive at the end of the block and work backwards from there), and here using a pattern of only two adjacent instructions. 17:17:35 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:18:53 there's still no peephole optimizer in sight 17:21:40 OK. Personally, I thought so far that this is caused more by fear that the gain is too little to be worthwhile the effort than by lack of time/motivation to implement something. 17:23:50 stassats: Are you still interested in your paste 137557 from earlier today? I could offer some thoughts. 17:24:01 i am 17:25:28 Fine. Your criteria to decide between the two options are which? Performance? 17:25:43 benkard [~benkard@ppp-93-104-162-129.dynamic.mnet-online.de] has joined #sbcl 17:25:52 since they are of the same size, yes 17:26:22 if you didn't recognize it, it's (setf *special* x) 17:26:47 it first checks for a tls binding, then uses the global value 17:26:56 i'm not sure which branch is more often taken 17:27:10 Yes, I found the source in cell.lisp, for set-symbol-value. 17:28:22 -!- davazp [~user@77.225.147.21] has quit [Remote host closed the connection] 17:30:24 stassats: it would take some surgery. I'd rather do that via an IR2 (VOP) rewrite pass than try to extend the mapping from IR1 to Ir2. 17:32:39 First approach: Latency. We can assume the branch is predicted correctly. The first variant takes longer because of the LEA. The calculation this does costs no time when done directly in the memory access (cmp [r+r], i takes the same time as cmp [r], i). 17:34:22 But: As RCX in most cases is read immediately before from [RIP-const] the whole memory read dependency chain can start to execute as soon as the load of RCX is decoded. If the reorder buffer of the processor is large enough this may make the latency difference disappear. 17:35:03 i couldn't see a difference between them during simple testing 17:35:09 on SB 17:35:37 Second approach: Number of instructions executed (dynamically). Version 2 wins. 17:36:17 i'm trying to understand how binding works, maybe it can be simplified altogether 17:36:59 getting the TLS index at load-time would be good. 17:37:01 Third consideration: Intel processors before SB are limited by the number of simultaneous register reads. Here version 1 wins, but this will be only visible if the number of register reads is a bottleneck here. 17:38:12 Fourth consideration: Variant 2 has one unconditional jump more than variant 1. This may cost branch _target_ prediction resources. 17:38:23 i thought if the tls slot could always point to the right place, either global or not 17:38:37 but i haven't finished understanding binding on sb-thread yet 17:38:59 a symbol can have a tls index and not be bound locally. 17:39:55 My conclusion: It is too complicated to predict anything here, so find or construct an application where this is a bottleneck and measure it. Barring any difference, just leave it as it is. 17:40:11 madanyang [~irc@opensuse/member/toganm] has joined #sbcl 17:40:16 i left it as is 17:47:41 -!- madanyang [~irc@opensuse/member/toganm] has left #sbcl 17:52:05 XOR RAX, RAX MOV [RCX-8], RAX MOV [RCX-16], RAX is smaller than MOV [RCX-8], 0 MOV [RCX-16], 0 17:52:32 i also tried an sse move some time ago, it was smaller too, but don't remember by how much 17:52:43 *stassats* looks at UNBIND 17:53:03 drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has joined #sbcl 17:55:13 something like lazily emit a load-time-value entry to get the symbol's tls index whenever we create a global-var of kind :special. 17:55:55 and we can pass that to bind/set/ref during ir2tran. 17:56:17 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 17:56:53 That would mean one memory indirection less in set-symbol-value? 17:57:13 and a lot less code. 17:57:23 (in bind) 17:58:44 I see set-symbol-value (and the getter, too), always inlined in many places (in the disassemblies of many functions). Is that the case with bind, too? 17:58:56 yes. 17:59:11 and bind has to dynamically generate the TLS index too 17:59:25 OK, then a lot less code is a fine effect. 17:59:46 moving RAX appears to be a bit faster 17:59:58 in addition to saving 5 bytes 18:00:09 xor temp-reg-tn ;) 18:00:22 ah, but it's larger. 18:00:39 well, it's not rax, it's a temporary happened to be RAX here 18:02:11 does MOV [RDX], [RAX] work? 18:02:19 i.e., ea for both operands 18:03:39 apparently not, bogus arguments to MOV: 18:04:42 no, two memory operands are only possible implicitly with MOVS, which moves from [rsi] to [rdi]. 18:10:25 If you want to live out the space savings with storing a register instead of an immediate, stassats, take a look at SB-C::BUILD-SEQUENCE-ITERATOR, the stuff after L0. 18:11:49 -!- drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has quit [Remote host closed the connection] 18:11:56 oh my 18:12:22 that's loop initializing things to NIL 18:12:46 can pkhuong do that with VOP rewriting? 18:14:48 for more fun code: http://paste.lisp.org/display/137564 18:14:54 i have real code which compiles to this 18:17:06 vi1 [~vi1@93.92.216.186] has joined #sbcl 18:17:32 i'm not even sure where it comes from, probably LOOP as well 18:17:50 (or xchg) 18:17:57 The labels are presumably reached from some conditional jump where ordering the two following blocks differently might improve the situation. 18:18:01 can I do what? 18:18:16 pkhuong: magic, can you do magic? 18:19:08 pkhuong: Change repetitions (with different i) of mov [rbp-i], nil, to mov reg, nil, mov [rbp-i], reg. 18:19:18 drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 18:19:30 hard. 18:19:33 See build-sequence-iterator, as mentioned above. 18:19:41 I sometimes hack around that by hand 18:20:16 most of those moves can be probably removed, if it knows that those NILs won't be used 18:20:23 If it's all in the same basic block, sure, but I don't know that hoisting stuff out of loops is our priority.. 18:21:59 and it's COLLECT, actually 18:22:13 and then loop 18:22:41 LOOP really doesn't emit SBCL-friendly code :\ 18:26:51 more context: http://paste.lisp.org/display/137564#1 18:27:33 type tests? 18:27:54 yeah, I didn't convert them to only compute the flags. 18:28:19 Thanks for the context. I just pasted a patch I tried a while ago that might help here. 18:28:49 if you change the relevant vops to be, e.g. (:conditional :e), then you'll get cmov conversion for free. 18:29:28 It reorders the two blocks succeeding an IF block if their block numbers allow to determine a good topological order. 18:29:33 it's a generic memory copying function, with destination and source sizes specified and with direction too 18:29:42 leuler: ah, is that why my DFO hacks didn't work? You have to do that in control.lisp, not DFO? 18:29:56 I have not committed it as it sometimes makes things worse. 18:30:27 I was trying to make it so loops with multiple exits wouldn't have the exit branch in the middle of the loop. 18:30:28 it gets this crazy after being inlined into another generic function 18:30:42 gets normal after inlined into a specialized version, so i'm not worried much 18:30:59 ok then. 18:31:06 otherwise I'd suggest to typecase into specialised code. 18:31:25 it's basically inling instead of macros 18:31:52 so, i don't really care for the code of intermidiate functions 18:32:24 ASau` [~user@p4FF96A04.dip0.t-ipconnect.de] has joined #sbcl 18:32:25 and functions are easier to write than macros, and inlining can be turned off for easier recompilation 18:34:24 leuler: it makes the whole code slightly smaller, but that sequence is still there 18:35:07 Sorry, but I think it was worth a try. 18:35:43 stassats: of course. the only way to convert that to conditional moves is to change some of the VOPs to just compute cc 18:36:10 -!- ASau [~user@p5797EE78.dip0.t-ipconnect.de] has quit [Read error: Operation timed out] 18:37:06 danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has joined #sbcl 18:37:21 actually, this very function is not inlined 18:37:50 and the only of non-inlined having such a property 18:41:01 -!- ASau` is now known as ASau 18:41:39 -!- benkard [~benkard@ppp-93-104-162-129.dynamic.mnet-online.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 18:44:50 pkhuong: I just looked it up; my loop rotation change (67f44c92) also affected control.lisp, so, yes, changes there have an effect on block ordering. 18:45:02 benkard [~benkard@ppp-93-104-162-129.dynamic.mnet-online.de] has joined #sbcl 18:48:03 looks like the right place to tension jmp to jmp away 18:49:05 -!- ASau [~user@p4FF96A04.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 18:50:58 what (disassemble (lambda (string) (sb-sys:sap-int (sb-sys:vector-sap string)))) 18:51:53 (declare (type (simple-unboxed-array (*)) x)) 18:51:57 just (disassemble (lambda (string) (sb-sys:vector-sap string))) 18:52:38 yes. because (type (simple-unboxed-array (*)) x). 18:53:26 hah, if anyone wants to bring back the significant-changes rss feed for boinkmarks, check out http://codeascraft.com/2013/06/11/introducing-loupe/ (: 18:53:29 ASau [~user@p4FF96A04.dip0.t-ipconnect.de] has joined #sbcl 18:53:55 antifuchs: nice. 18:54:09 pkhuong: so it tries all the wide-tags? 18:54:17 right? that's a thing I've always wanted for monitoring (: 18:54:23 stassats: yes. 18:54:36 antifuchs: that's a thing my sysadmin friends have always wanted ;) 18:54:47 yep yep! (: 18:54:56 stassats: expand simple-unboxed-array. it's an or type. 18:56:47 what would be a better type? 18:59:05 a simple-string on my side is enough, but such a forest of typechecks doesn't look right if i don't want to specify any types 18:59:23 I would check that (and (simple-array * 1) (not simple-vector)) works 19:00:23 same for unboxed-array. 19:00:42 and then be paranoid for regressions. 19:20:03 if I remember correctly, there's a nasty lurking subtypep thing there 19:20:14 failed AVER: SB!C::SAETP 19:20:20 I think the type system might not know that (and (simple-array * 1) (not simple-vector)) is equivalent to 19:20:23 ... 19:20:23 "doesn't work" 19:20:28 yes 19:21:50 (I'm not sure I would have predicted exactly that failure mode, mind you) 19:24:11 it's during a subseq transform 19:25:30 for what change? Just (def.type simple-unboxed-array () ')? 19:26:05 i may have made a typo, let me try again 19:26:35 _8david` [~user@eth1-2.bob.askja.de] has joined #sbcl 19:26:44 possibly the "right" ahahaha or maybe "less wrong" solution is to special-case simple-unboxed-array in compiler/*/*type-vops.lisp 19:27:59 -!- lichtblau [~user@eth1-2.bob.askja.de] has quit [Remote host closed the connection] 19:27:59 -!- _8david` [~user@eth1-2.bob.askja.de] has quit [Remote host closed the connection] 19:29:30 ok, it's (sb!xc:deftype simple-unboxed-array (&optional dims) `(and (simple-array * ,dims) (not (simple-array t)))) 19:30:11 it obviously picks up (simple-array *) 19:30:24 right. So making that work transparently involves messing with the type system again 19:30:49 probably simplest would be to implement array types a bit like character-set types, with a bitvector to indicate possible specialisms 19:31:11 hzp [~user@eth1-2.bob.askja.de] has joined #sbcl 19:31:13 Krystof: yes, that really helped simplify the logic for simd pack types. 19:31:26 (I just used lists as sets, mind you) 19:32:00 sure, some set representation 19:32:45 you still wouldn't get a good type test without some extra cleverness, I think, either in src/compiler/typetran or src/compiler/*/type-vops 19:33:25 or both 19:33:46 it would be entertaining to find out how much breaks if an ARRAY-TYPE can represent unions of specialized arrays 19:34:04 I bet there's lots that assumes that an array type is either wild or a single specializer 19:34:25 oh, that reminds me. I might have a bright 18-year-old working on sbcl for me over the summer 19:34:42 (has taught himself haskell, likes the idea of working on compilers, etc etc) 19:34:47 any ideas for suitable projects? 19:34:48 I think we mostly go through some functions that give-up if it can't find a single specialised though? 19:35:08 what motivates him? 19:35:18 Bike_ [~Glossina@67-5-247-95.ptld.qwest.net] has joined #sbcl 19:35:31 any project's first step would be 1) get to know SBCL 19:35:34 -!- Bike [~Glossina@67-5-247-95.ptld.qwest.net] has quit [Disconnected by services] 19:35:39 -!- Bike_ is now known as Bike 19:38:38 yeah. Dunno. Head of Department's child 19:39:12 The kid we saw for 10 seconds at SBCL 10? 19:41:31 IR2 pattern matching? 19:42:00 proper instruction selection? 19:42:05 Very symbolic, doesn't have to deal with grotty internals too much. 19:42:13 stassats: isel? that'd be a huge change. 19:45:19 -!- vi1 [~vi1@93.92.216.186] has quit [Ping timeout: 246 seconds] 19:46:22 sdemarre [~serge@8.65-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 19:48:01 pkhuong: no, different Head of Department 19:48:13 but also, good point, hm, should we use GoogleDollars to fund SBCL14? 19:50:39 What else could we do with it? 19:51:06 buy itanic hardware :) 19:51:39 would it be enough? 19:51:53 stassats: I'm pretty sure I can find one for cheap. 19:52:03 new? 19:52:07 Hosting is usually more of an issue, but if Krystof can get some deal with his dept ;) 19:52:14 stassats: hah. 19:57:14 maybe I could use one as a heater, to offset the stupid airflow through the floor cooling system 19:58:21 vi1 [~vi1@93.92.216.186] has joined #sbcl 19:59:01 Ebay has used Itanium servers from approx. USD 300 upwards. 19:59:35 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 20:00:21 I was joking! 20:00:31 I know. 20:00:48 Can one find an expensive ARM machine? 20:02:00 leuler: probably not yet. 20:02:05 not used on ebay,anyway 20:02:07 a galaxy S4? 20:02:27 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: dead] 20:02:47 we could buy google adwords 20:17:21 -!- benkard [~benkard@ppp-93-104-162-129.dynamic.mnet-online.de] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 20:17:43 -!- drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 20:33:04 scymtym_ [~user@ip-5-147-122-209.unitymediagroup.de] has joined #sbcl 20:33:14 -!- leuler [~user@p548F92C1.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 20:49:09 -!- sdemarre [~serge@8.65-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 20:51:46 sdemarre [~serge@8.65-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 21:09:31 -!- sdemarre [~serge@8.65-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 264 seconds] 21:18:51 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Read error: Operation timed out] 21:23:48 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Ping timeout: 252 seconds] 21:38:22 -!- psilord [~pkeller@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 21:40:23 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 21:40:42 -!- prxq [~mommer@mnhm-590c153c.pool.mediaWays.net] has quit [Quit: Leaving] 22:21:00 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 22:47:48 -!- wbooze [~wbooze@xdsl-78-35-131-92.netcologne.de] has quit [Read error: Operation timed out] 22:54:12 drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 23:01:07 -!- segv- [~mb@95-91-241-56-dynip.superkabel.de] has quit [Ping timeout: 260 seconds] 23:07:59 davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has joined #sbcl 23:12:02 -!- davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has quit [Remote host closed the connection] 23:12:10 davazp [~user@254.Red-79-144-63.dynamicIP.rima-tde.net] has joined #sbcl 23:22:38 -!- drmeister [~drmeister@173-162-165-237-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 23:25:10 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 23:30:03 drmeister [~drmeister@h69-21-18-138.nwlnnh.dedicated.static.tds.net] has joined #sbcl