00:00:57 does logbitp compile into bt? 00:01:02 we shouldn't use BT anymore. 00:01:05 the new one, yes 00:04:25 well no, it's just higly uarch dependent, looks like. 00:07:31 stassats: can you try disabling on-stack operands in the VOP definitions? 00:08:24 i'm feeding it the results of integer-length 00:21:56 and the costs of logtest vops seems to be wrong 00:22:31 i'm selected the fixnum one, although the unsigned can be used instead 00:23:41 though the fixnum one uses TEST AL, 2, unsigned uses a larger TEST RAX, 1 00:26:10 -!- jl_3 [~jl_2@184-96-179-27.hlrn.qwest.net] has left #sbcl 00:27:47 it generates the TEST for AL only for any-reg descriptor-reg 00:27:58 any reason to omit unsigned-reg? 00:28:34 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 00:30:45 I don't think so 00:31:22 -!- davazp [~user@212.129.66.115] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 00:33:38 it also checks (or (= offset eax-offset) (= offset ebx-offset) (= offset ecx-offset) (= offset edx-offset)) for lower registers, but x86-64's r8-r15 can be r8l-r15l too 00:34:03 not sure it's a win in encoding size 00:34:45 well, this would require some untangling 00:35:03 i need to finish with integer-length optimizations first 00:35:11 likely not. You need the REX byte to get the upper 8 registers anyway. 00:35:37 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 00:35:45 I'm pretty sure the 8-bit version is better? "test rax, 1" would use the "test r/m64, imm32" encoding, I think 00:36:33 test doesn't seem to have a "test r/m64, imm8" option if I'm reading this right (but like, 'add' does?) 00:37:57 but then logtest vops do not demonstrate their preference for eax/ebx/ecx/edx/whatever, instead choose the lowest possible for the registers they are assigned 00:38:09 I'm thinking of submitting a proposal for the google summer of code for working on vectorization for sbcl and I was wondering what kind of simple work I could help with to get an idea of the sbcl code base 00:38:27 if I had to guess, the eax/ebx/ecx/edx thing is because on x86_32, there's no 8-bit registers for the other regs? 00:38:51 Fiora: yes, that was a copy of x86-32 code 00:39:05 i'm reviewing it 00:39:13 ah 00:40:23 Fiora: see 7a2a31f commit 00:40:46 it's not just a port oversight: the goal of that optimisation is to emit a smaller instruction. 00:41:24 can a vop :target a range of registers? 00:41:48 al/cl/dl/bl are smaller to encode. Not so for the other 8 bit registers. 00:42:27 um, I think they still are? because the immediate gets smaller 00:42:28 stassats: it's shaving something like 1 or 2 bytes. Even if it were possible, I wouldn't bother. 00:44:08 so, the main problem is how to assign the costs correctly 00:44:34 sure, you're still saving a couple bytes even with the REX prefix. 00:45:06 test r/m8,imm8 is... REX+F6 /0 ib and test r/m32,imm32 is... F7 /0 id... so I guess the difference is 2 bytes unless I'm reading this wrong 00:50:28 so, shouldn't it use :variant and :variant-cost then? 00:51:04 are we still talking about code size? I don't think it amtters enough to try and encode that in the cost. 00:51:28 no, i'm talking that i'm selected c/fixnum instead of c/unsigned 00:52:04 even if assign them equal costs 00:52:14 it should still pick the smallest way to encode a given instruction, right? I mean like ignoring costs 00:52:26 I think for any assignment cost costs to fixnum and unsigned variants, I've managed to find bad cases, so far. 00:52:56 stassats: I guess I'd do like the rest of the code and give slightly priority to the /fixnum variant. 00:53:51 -!- TuckerD [~tucker@c-98-216-148-67.hsd1.nh.comcast.net] has quit [Quit: Leaving] 00:53:57 Fiora: sure. I'm just saying it's not worth trying to do more than take advantage of the situation without doing anything to get tightly-encodable instructions. 00:54:04 maybe the vop selector should be fixed than? to not select a VOP which needs boxing if the one which doesn't have the same cost? 00:54:05 TuckerD [~tucker@c-98-216-148-67.hsd1.nh.comcast.net] has joined #sbcl 00:54:25 stassats: that's what representation selection is supposed to take care of. 00:55:01 ah, it doesn't declare any types of args, that's why 00:55:25 or maybe it's inherited 00:55:36 pkhuong: okay, so it should try to optimize it, but not try to bias towards them in the instruction selection? that makes sense 00:55:55 right, it's inherited 00:59:34 -!- TuckerD [~tucker@c-98-216-148-67.hsd1.nh.comcast.net] has quit [Quit: Leaving] 01:00:12 TuckerD [~tucker@c-98-216-148-67.hsd1.nh.comcast.net] has joined #sbcl 01:02:08 I'm thinking of submitting a proposal for the google summer of code for working on vectorization for sbcl and I was wondering what kind of simple work I could help with to get an idea of the sbcl code base 01:05:27 -!- TuckerD [~tucker@c-98-216-148-67.hsd1.nh.comcast.net] has quit [Quit: Leaving] 01:06:32 TuckerD [~user@c-98-216-148-67.hsd1.nh.comcast.net] has joined #sbcl 01:09:29 Hello, I'm thinking of submitting a proposal for the google summer of code for working on vectorization for sbcl and I was wondering what kind of simple work I could help with to get an idea of the sbcl code base 01:10:02 yes, that's the third time 01:13:45 oh, sorry, i wasn't sure it sent 01:15:02 well, i don't know anything simple 01:15:19 try "easy" tag on launchpad 01:18:04 -!- TuckerD [~user@c-98-216-148-67.hsd1.nh.comcast.net] has quit [Remote host closed the connection] 01:28:19 -!- Bike [~Glossina@67-5-198-42.ptld.qwest.net] has quit [Ping timeout: 246 seconds] 01:28:23 Bike_ [~Glossina@71-34-76-227.ptld.qwest.net] has joined #sbcl 01:28:38 -!- Bike_ [~Glossina@71-34-76-227.ptld.qwest.net] has quit [Read error: Connection reset by peer] 01:34:40 Bike_ [~Glossina@71-34-77-190.ptld.qwest.net] has joined #sbcl 02:00:26 -!- yacks [~py@180.151.36.168] has quit [Read error: Connection reset by peer] 02:02:17 -!- Bike_ [~Glossina@71-34-77-190.ptld.qwest.net] has quit [Quit: leaving] 02:02:47 Bike [~Glossina@71-34-77-190.ptld.qwest.net] has joined #sbcl 02:02:49 yacks [~py@180.151.36.168] has joined #sbcl 02:07:26 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [Remote host closed the connection] 02:10:23 -!- Bike [~Glossina@71-34-77-190.ptld.qwest.net] has quit [Ping timeout: 255 seconds] 02:10:57 pkhuong [~pkhuong@gravelga.new.xen.prgmr.com] has joined #sbcl 02:12:06 Bike [~Glossina@75-175-73-249.ptld.qwest.net] has joined #sbcl 02:27:52 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 02:36:02 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 02:47:22 -!- Hydan [~hydan@ip-89-103-110-116.net.upcbroadband.cz] has quit [Ping timeout: 272 seconds] 02:52:27 -!- easye [~user@213.33.70.157] has quit [Remote host closed the connection] 02:53:55 easye [~user@213.33.70.157] has joined #sbcl 03:01:10 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 03:01:26 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:02:05 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 03:04:20 -!- Bike [~Glossina@75-175-73-249.ptld.qwest.net] has quit [Ping timeout: 252 seconds] 03:04:26 Bike [~Glossina@67-5-239-36.ptld.qwest.net] has joined #sbcl 03:06:48 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 03:33:26 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:37:17 -!- Fare [fare@nat/google/x-rjlbryrovwowvmbn] has quit [Quit: Leaving] 03:43:33 -!- wbooze [~wbooze@xdsl-78-35-135-176.netcologne.de] has quit [Ping timeout: 248 seconds] 03:55:53 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Remote host closed the connection] 04:21:41 echo-area [~user@182.92.247.2] has joined #sbcl 04:24:48 attila_lendvai [~attila_le@92.46.23.135] has joined #sbcl 04:24:48 -!- attila_lendvai [~attila_le@92.46.23.135] has quit [Changing host] 04:24:48 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:57:41 sdemarre [~serge@91.176.241.189] has joined #sbcl 05:07:34 prxq [~mommer@mnhm-590c01e3.pool.mediaWays.net] has joined #sbcl 05:24:21 Hydan [~hydan@ip-89-103-110-116.net.upcbroadband.cz] has joined #sbcl 05:29:14 -!- easye [~user@213.33.70.157] has quit [Ping timeout: 256 seconds] 05:35:30 -!- sdemarre [~serge@91.176.241.189] has quit [Ping timeout: 264 seconds] 05:36:16 Fare [fare@nat/google/x-iebjwewvhopbqgiq] has joined #sbcl 05:37:41 I think sxhash is called on known symbols every so often in the compiler 05:39:05 pranavrc [~pranavrc@117.193.218.123] has joined #sbcl 05:39:05 -!- pranavrc [~pranavrc@117.193.218.123] has quit [Changing host] 05:39:05 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 05:53:51 tcr1 [~tcr@46-126-110-164.dynamic.hispeed.ch] has joined #sbcl 06:43:05 -!- yacks [~py@180.151.36.168] has quit [Quit: Leaving] 06:50:42 easye [~user@213.33.70.157] has joined #sbcl 06:53:13 -!- easye [~user@213.33.70.157] has quit [Remote host closed the connection] 06:58:31 -!- Munksgaard [~philip@80-71-135-72.u.parknet.dk] has quit [Read error: Connection reset by peer] 06:58:48 easye [~user@213.33.70.157] has joined #sbcl 07:03:03 ASau [~user@p5797F4B2.dip.t-dialin.net] has joined #sbcl 07:12:57 -!- tcr1 [~tcr@46-126-110-164.dynamic.hispeed.ch] has quit [Quit: Leaving.] 07:22:07 -!- Fare [fare@nat/google/x-iebjwewvhopbqgiq] has quit [Ping timeout: 264 seconds] 07:28:21 Munksgaard [~philip@192.38.109.188] has joined #sbcl 07:37:15 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 07:50:18 kanru` [~kanru@201.red-88-12-18.staticip.rima-tde.net] has joined #sbcl 07:53:13 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 240 seconds] 07:54:12 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:59:42 foreignFunction [~niksaak@94.27.88.6] has joined #sbcl 08:00:38 yacks [~py@180.151.36.168] has joined #sbcl 08:11:15 Krystof: but that's just a slot load and a conditional call. 08:17:55 yes, but that's substantially faster than an out-of-line call to sxhash with dispatch 08:18:01 I noticed when I broke it at some point 08:18:12 -!- ASau [~user@p5797F4B2.dip.t-dialin.net] has quit [Read error: Connection reset by peer] 08:18:47 ASau [~user@p5797F4B2.dip.t-dialin.net] has joined #sbcl 08:19:09 right. 08:21:33 -!- easye [~user@213.33.70.157] has quit [Remote host closed the connection] 08:22:38 easye [~user@213.33.70.157] has joined #sbcl 08:28:06 -!- foreignFunction [~niksaak@94.27.88.6] has quit [Ping timeout: 272 seconds] 08:33:48 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] 08:43:40 -!- Bike [~Glossina@67-5-239-36.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 08:44:39 foreignFunction [~niksaak@94.27.88.229] has joined #sbcl 08:46:27 foom: btw, that xor/shift hash you psoted is only 5 times slower than sxhash here ;) 09:24:28 rudi [~rudi@1x-193-157-250-241.uio.no] has joined #sbcl 09:27:07 davazp [~user@31.200.128.121] has joined #sbcl 10:19:29 -!- easye [~user@213.33.70.157] has quit [Remote host closed the connection] 10:21:40 easye [~user@213.33.70.157] has joined #sbcl 10:34:56 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:47:35 this gsoc is already a good idea! two patches on launchpad for "easy" already 10:48:02 I know; it shows somewhat the power of advertising 10:48:05 and branding 10:48:10 gah I will shut up now 10:51:09 synergetic effects from coordinated dissemination efforts ... 10:51:42 (just came back from an EU project final review; sorry about that) 10:57:50 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 10:59:00 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 11:01:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:05:30 -!- scymtym [~user@ip-5-147-116-166.unitymediagroup.de] has quit [Ping timeout: 264 seconds] 11:18:47 foom: ok, forced both the specialised sxhash and xor/shift to be called out of line, and it's ~2x as slow. 11:23:01 also, the power of showing we're open for business. 11:24:48 -!- kanru` [~kanru@201.red-88-12-18.staticip.rima-tde.net] has quit [Ping timeout: 272 seconds] 11:28:00 -!- davazp [~user@31.200.128.121] has quit [Read error: No route to host] 11:31:55 advance warning: I might freeze on Friday morning so that my "spare" time on Friday afternoon can be spent looking at this sourceforge "upgrade" looming disaster 11:32:01 davazp [~user@31.200.128.121] has joined #sbcl 11:32:36 All right. I'll try to fix the build on OS X 10.8.0 before that. 11:33:00 a build fix is probably acceptable post-freeze, though if you have to play "hunt the git repository" that might not be totally straightforward 11:41:43 kanru` [~kanru@201.red-88-12-18.staticip.rima-tde.net] has joined #sbcl 11:42:25 Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has joined #sbcl 11:55:36 -!- Odyessus [~odyessus@chello080109062130.15.14.vie.surfer.at] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 11:59:20 -!- rudi [~rudi@1x-193-157-250-241.uio.no] has quit [Quit: Textual IRC Client: http://www.textualapp.com/] 12:06:47 -!- scymtym__ [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 12:07:29 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:19:54 -!- kanru` [~kanru@201.red-88-12-18.staticip.rima-tde.net] has quit [Ping timeout: 272 seconds] 12:50:12 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 13:06:32 Odyessus [~odyessus@089144192240.atnat0001.highway.a1.net] has joined #sbcl 13:18:07 -!- Odyessus [~odyessus@089144192240.atnat0001.highway.a1.net] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 13:18:55 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 13:20:36 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 13:28:56 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 13:42:42 wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has joined #sbcl 13:49:08 kanru` [~kanru@201.red-88-12-18.staticip.rima-tde.net] has joined #sbcl 13:59:15 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 13:59:30 rudi [~rudi@1x-193-157-250-241.uio.no] has joined #sbcl 14:43:02 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 272 seconds] 14:44:33 pkhuong: did you use it in C++ or in lisp? 14:45:42 foom: lisp. But the disasm is fine. 14:46:53 Last time we looked at it, we actually had it ffi out to C code, cause that was noticeably faster. 14:48:30 nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has joined #sbcl 14:49:33 foom: annotated 14:50:02 the g-l-o-a sucks a bit, but that's it. 14:52:06 ... Dare I ask? 14:52:08 leuler [~user@p548FD0A9.dip.t-dialin.net] has joined #sbcl 14:54:11 nyef: http://paste.lisp.org/display/136751 14:55:06 Ah. 15:05:24 -!- Munksgaard [~philip@192.38.109.188] has quit [Ping timeout: 276 seconds] 15:07:57 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 245 seconds] 15:11:24 pkhuong: you used the 64bit-to-32bit-result variant there, without a final truncation to 32 bits. (which ofcourse is correct for use as a hashtable hash function). 15:11:33 I pasted the asm gcc created for that. 15:11:58 which is noticably shorter. 15:13:26 tsuru` [~charlie@adsl-98-87-25-187.bna.bellsouth.net] has joined #sbcl 15:13:36 drmeister [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 15:19:12 I also annotated it with the best lisp version we had before switching to calling the C one. 15:19:33 (Which is actually quite reasonable, although still not quite as good) 15:21:47 pranavrc [~pranavrc@122.164.107.202] has joined #sbcl 15:21:48 -!- pranavrc [~pranavrc@122.164.107.202] has quit [Changing host] 15:21:48 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl 15:25:40 -!- wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has quit [Remote host closed the connection] 15:26:36 wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has joined #sbcl 15:28:21 -!- wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has quit [Remote host closed the connection] 15:29:48 wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has joined #sbcl 15:37:35 -!- meyersh [~meyersh@198.102.147.253] has quit [Remote host closed the connection] 15:38:33 -!- wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has quit [Remote host closed the connection] 15:42:42 wasao [~matsu@119-47-43-146.ppp.bbiq.jp] has joined #sbcl 15:46:50 Munksgaard [~philip@80-71-135-72.u.parknet.dk] has joined #sbcl 15:52:53 stassats [~stassats@wikipedia/stassats] has joined #sbcl 16:07:47 wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has joined #sbcl 16:10:50 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 16:13:01 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 16:13:07 attila_lendvai1 [~attila_le@92.47.252.144] has joined #sbcl 16:13:07 -!- attila_lendvai1 is now known as attila_lendvai 16:13:07 -!- attila_lendvai [~attila_le@92.47.252.144] has quit [Changing host] 16:13:07 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:13:29 Hello. I'm Japanese Lisper student. I'm interested in "Improving the thread-safety of the object system" of GSoC. This is my first time of application for GSoC. How should I write a application, and apply for GSoC? 16:27:15 Bike [~Glossina@67-5-240-156.ptld.qwest.net] has joined #sbcl 16:30:57 -!- wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has quit [Remote host closed the connection] 16:31:42 Bike_ [~Glossina@67-5-240-156.ptld.qwest.net] has joined #sbcl 16:31:51 wbooze [~wbooze@xdsl-78-35-160-98.netcologne.de] has joined #sbcl 16:34:29 -!- Bike [~Glossina@67-5-240-156.ptld.qwest.net] has quit [Ping timeout: 252 seconds] 16:34:59 -!- rudi [~rudi@1x-193-157-250-241.uio.no] has quit [Quit: Textual IRC Client: http://www.textualapp.com/] 16:38:16 -!- Bike_ is now known as Bike 16:49:40 wasao: the GSoC website should have some guidelines on writing a proposal. If you want, I can send you my proposals from 2005 and 2007 by email. 16:53:30 -!- kanru` [~kanru@201.red-88-12-18.staticip.rima-tde.net] has quit [Ping timeout: 272 seconds] 16:55:16 foom: fwiw, the final stage of murmurhash3 seems stronger than the one you pasted. 16:58:54 luis: Thanks! my email address: walter(a)wasao.org 17:00:18 pkhuong: Do you know of any literature regarding 5-universality of other hash functions besides the polynomial-based and the tabulation hash? 17:01:01 leuler: The others require a lot more storage, iirc. 17:05:52 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 245 seconds] 17:07:12 -!- xymox is now known as list 17:07:23 -!- list is now known as remove 17:07:35 -!- remove is now known as reset 17:08:07 -!- reset is now known as Guest89997 17:08:18 -!- Hydan [~hydan@ip-89-103-110-116.net.upcbroadband.cz] has quit [Ping timeout: 252 seconds] 17:11:45 urgosum [~urgosum@host86-168-219-232.range86-168.btcentralplus.com] has joined #sbcl 17:21:08 Bike_ [~Glossina@67-5-207-229.ptld.qwest.net] has joined #sbcl 17:23:49 -!- Bike [~Glossina@67-5-240-156.ptld.qwest.net] has quit [Ping timeout: 248 seconds] 17:35:25 -!- Guest89997 [lechuck@unaffiliated/contempt] has quit [Quit: leaving] 17:35:43 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Quit: Ping timeout: ] 17:36:10 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 17:42:34 sdemarre [~serge@91.176.241.189] has joined #sbcl 17:43:02 so, anyone for those typo fixes? 17:43:18 *stassats* proposes to fix typos in the docstring for sb-ext:compare-and-swap 17:44:21 -!- Bike_ is now known as Bike 18:12:51 Hydan [~hydan@176.74.140.3] has joined #sbcl 18:49:59 -!- Strigoides [~owen@60-234-213-126.bitstream.orcon.net.nz] has quit [Quit: leaving] 18:51:35 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 19:00:21 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:01:00 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 19:17:30 -!- Bike [~Glossina@67-5-207-229.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 19:19:14 Bike [~Glossina@67-5-207-229.ptld.qwest.net] has joined #sbcl 19:31:20 archonix [~unknown@78.90.30.16] has joined #sbcl 19:31:53 -!- archonix [~unknown@78.90.30.16] has quit [Client Quit] 19:36:41 rpg_ [~rpg@216.243.156.16.real-time.com] has joined #sbcl 19:37:11 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 260 seconds] 19:39:37 -!- Hydan [~hydan@176.74.140.3] has quit [Ping timeout: 245 seconds] 19:40:41 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 255 seconds] 19:41:15 -!- rpg_ [~rpg@216.243.156.16.real-time.com] has quit [Ping timeout: 245 seconds] 19:43:50 tcr1 [~tcr@46-126-110-164.dynamic.hispeed.ch] has joined #sbcl 20:02:18 rpg [~rpg@23-25-144-220-static.hfc.comcastbusiness.net] has joined #sbcl 20:10:07 -!- rpg [~rpg@23-25-144-220-static.hfc.comcastbusiness.net] has quit [Quit: rpg] 20:12:54 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 245 seconds] 20:29:16 scymtym_ [~user@ip-5-147-116-166.unitymediagroup.de] has joined #sbcl 20:29:26 -!- sdemarre [~serge@91.176.241.189] has quit [Ping timeout: 256 seconds] 20:33:11 -!- leuler [~user@p548FD0A9.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 20:43:13 cmm- [~cmm@bzq-79-182-100-51.red.bezeqint.net] has joined #sbcl 20:45:25 -!- cmm [~cmm@bzq-79-176-109-234.red.bezeqint.net] has quit [Ping timeout: 248 seconds] 20:49:18 Just firing up a PPC test machine, hoping to get some baseline information on its current hardware problems, possibly do an SBCL build. "has gone 346 days without being checked, check forced." 20:50:16 nyef: well, at least you probably don't have TBs of free space that ext3 needs to fsck over ;) 20:51:32 I think it might be about a TB. 20:51:53 And it turns out that there's some actual corruption beyond what an automatic fsck will fix. /-: 20:54:24 -!- foreignFunction [~niksaak@94.27.88.229] has quit [Quit: Leaving.] 20:55:48 -!- prxq [~mommer@mnhm-590c01e3.pool.mediaWays.net] has quit [Quit: Leaving] 21:05:43 Hunh. 142 gigs. 21:29:47 Oh, fun. "git pull" "fatal: Unable to look up sbcl.boinkor.net (port 9418) (Name or service not known)" 21:30:14 Guess I'll figure that out later. 21:33:44 minion: memo for leuler: So, AFAICT, the only thing where sxhash performance is really critical is for symbols, and that's basically a cache lookup. Given the overhead of full call + type dispatch (+ actual hash table management), I'm thinking we could just always use a solid block hash function, even on 64-bit blocks. 21:33:45 Remembered. I'll tell leuler when he/she/it next speaks. 21:41:21 loader [~loader@14.139.122.114] has joined #sbcl 21:42:00 hey 21:42:28 is there any mentor here? 21:43:26 loader: ask your question. If someone can help you they will. 21:44:02 hey i m interested in participating GSOC 13 for sbcl 21:46:20 i m interested in prolect called Selecting concrete representations cleverly 21:47:12 i m ver well familiar with all Prerequisites but hav no idea of LISP 21:47:34 *stassats* is trying to measure whether using LEA RDX, [RDX+RDX+2] instead of INC RDX SHL RDX, 1 is worth it 21:47:47 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 21:47:49 requires an additional VOP, saves 1 byte 21:48:04 if only there was a peephole optimizer to do that automatically, or something 21:51:26 stassats: marginal. And INC sucks hard on some uarchs. 21:51:45 so i've heard 21:52:42 So yeah. I'm not sure why we emit an INC in the first place. 21:53:07 it's one byte shorter! 21:53:08 I think inc's only icky if it causes a false flag dependency problem? I guess that depends on the instructions around it though... 21:53:29 Fiora: and on the renaming capabilities of the uarch. 21:53:42 can't one plug-in an external peephole optimizer ? 21:53:47 and now intel's made the 3-argument lea slow -_- it's 3-cycle latency when it has 3 operands, I think 21:53:54 we really should have some uarch-dependent optimizations, for example, logcount is just popcnt on sandy bridge and later 21:54:01 (or sooner too) 21:54:02 is there such a thing ? 21:54:22 stassats: *backend-subfeatures* 21:54:34 (maybe that can be a summer of code project? <.<) 21:54:45 pkhuong: yes, but that's not a really nice interface 21:54:47 fe[nl]ix: and how would it communicate with SBCL's assembler? 21:54:53 -!- loader [~loader@14.139.122.114] has quit [Quit: Leaving] 21:55:03 loader: ok? 21:55:03 something -march=native would be nicer 21:55:24 something like 21:55:48 Fiora: what could be? 21:56:23 pkhuong: and more infrastructure than just :guard on *backend-subfeatures*, something like x86-64/sandy-bridge/arith.lisp 21:56:32 Hrm. I'm suddenly massively not a fan of trying to use my android tablet with a Linux chroot. It seems as though it can't keep a filesystem in usable condition to save its life. /-: 21:56:38 -!- drmeister [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 21:56:50 which would replace the default x86-64/arith.lisp VOPs when it makes sense 21:56:53 pkhuong: in what way communicate ? 21:57:05 Bike: some sort of uarch-specific optimization stuff? 21:57:14 stassats: let's try and get the generic stuff working first ;) 21:57:22 um, probably talk to the people who know about it, not me 21:57:34 fe[nl]ix: where does the external peephole plug in? 21:57:41 Alternately, I might just have horrid luck with sdcards. 21:57:43 I'm just following you around, don't mind me <.< 21:58:28 how does GCC do their -march optimizations? do they have a park of CPUs with different micro-architectures on which they test it? 21:58:38 or does Intel just send them patches? 21:58:42 stassats: and an army of Intel and AMD engineers. 21:58:46 I think it's a combination of all those things? I know intel and AMD contribute a lot 21:58:53 why doesn't intel send patches to SBCL? 21:59:20 stassats: I wonder why. 21:59:31 and like, there's a bunch of good documentation on instruction latency, architectures, and that kind of thing, so people probably use that too. 21:59:36 pkhuong: after SBCL does the final conversion to a code vector, the compiler would call the (immaginary) llvm_peephole(void *src, void *dst) on the result and use that instead 21:59:53 i heard they're have troubles selling their CPUs lately, faster Common Lisp execution should be a killer feature! 22:00:18 fe[nl]ix: llvm works with its IR, not asm. 22:00:24 even less so machine code. 22:01:35 and a peephole would have to know invariants, e.g. if some stuff can't move around, or it can't create interior pointers, or a partitioned register file, ... 22:01:54 aha 22:03:01 also, you'd need to specify indirect jump targets. 22:03:28 I believe it would be possible and likely useful to have an extremely conservative peephole pass that works on machine code. AFAIK, there is no such thing yet, and it wouldn't be quite that DWIMy. 22:03:54 do other compilers like gcc do something like that? 22:04:38 like what? a peephole pass? Pretty sure, yes. 22:04:58 It's a classic way to get obvious improvements with low code complexity 22:05:56 I meant, one on asm (instead of like a peephole on IR?) 22:05:57 Could we tie the peephole pass into the existing code scheduler framework for the assembler? 22:06:22 nyef: pretty sure that's the simplest way to do it. 22:06:44 ... And DOCUMENT that aspect of the assembler, while it happens? 22:06:51 I vaguely remember some code to re-enable a dummy scheduler on x86, just for that, in fact. 22:07:24 Fiora: some work on an IR that's pretty much tokenised assembly language. 22:07:45 drmeister [~drmeister@166.137.104.162] has joined #sbcl 22:08:10 pkhuong: the main thing I was thinking of is that I figure IR->asm has some loss? like, asm has some dependencies between flags and so on that won't exist in an IR, maybe? 22:08:34 so when trying to optimize the asm without changing its behavior, you might feel more tied down if you have to make sure that no flag behavior changes or the like 22:08:50 Fiora: yup. 22:09:10 so the ones that work on that kind of "asm-like IR" basically have extra information to avoid that problem? 22:09:32 You can recover the dependency information by representing the flags as an implicit register, or whatever, but a scheduling assembler has to track that stuff anyway... Although they tend to get used on architectures without such "flags" to worry about... 22:10:08 -!- Posterdati [~antani@host166-213-dynamic.11-87-r.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds] 22:13:26 -!- tcr1 [~tcr@46-126-110-164.dynamic.hispeed.ch] has quit [Quit: Leaving.] 22:21:14 *stassats* came up with a branchless integer-length for unsigned-byte 64, but it's larger and slower :( 22:22:37 and doesn't even work, upon further inspection 22:23:11 what's the integer-length formula? is it just, like, leading-zero count? 22:23:21 it's bsr + 1 22:23:25 ahhhhh 22:23:38 so, the trick is to handle zero and to 1 22:23:42 to add 1 22:23:58 I guess if there was the uarch-specific stuff, you could do 32-lzcnt 22:24:16 is the branchless thingy bsr + add + cmov? 22:24:17 i came up with a trick for fixnums, but yet not for unsigneds 22:24:41 not sure going branchless is much of a win though. 22:24:43 no, it was more clever, but it didn't work 22:24:56 The branch will likely always be predicted correctly. 22:25:02 How are bignums represented, I've never been able to dig into that well. Just a bunch of words? 22:25:37 A bunch of words with a header indicating how many words, probably. 22:25:52 It's been a little while since I've looked at the low-level representation of such things. 22:25:55 yeah. [widetag + length] [words*] 22:26:11 Bike_ [~Glossina@67-5-210-24.ptld.qwest.net] has joined #sbcl 22:26:21 stassats: signed might be easier. 22:29:10 -!- Bike [~Glossina@67-5-207-229.ptld.qwest.net] has quit [Disconnected by services] 22:29:14 -!- Bike_ is now known as Bike 22:29:45 um, I know it doesn't work but could you maybe post the trick you were trying? I'm a bit curious 22:31:42 -!- davazp [~user@31.200.128.121] has quit [Ping timeout: 245 seconds] 22:32:17 Fiora: idea was: SHL RDX, 1 ==> instead of incrementing, OR RDX, 1 ==> so that 0 returns 0 BSR RDX, RAX, ADC RDX, 0 ===> add the carry flag left from SHL RDX, 1. didn't work because OR clears CF 22:32:18 -!- drmeister [~drmeister@166.137.104.162] has quit [Remote host closed the connection] 22:32:27 stassats: I think signed can be something like: mov mask, x / shr mask, 63 / xor mask, x / lea mask, [mask*2+1] / bsr. 22:32:33 davazp [~user@31.200.128.121] has joined #sbcl 22:32:49 *sar mask, 63 22:33:09 I think something like this might work, but it's got to be way slower than cmov... 22:33:32 http://privatepaste.com/6bd1a02210 22:34:49 Fiora: CF is undefined after bsr, not sure what's exactly meant by "undefined" 22:35:02 so I set it with sub a,1 , I think? 22:35:23 couldn't you do like, um. shl rdx, 1 lea rdx, [rdx+1] 22:35:25 lea doesn't set flags 22:35:29 ah 22:35:39 oh.... undefined I think means it's modified, but not defined by the instruction? 22:35:45 so like, bsr should reset CF 22:35:59 I don't think adc will work there because CF gets lost in the meantime 22:36:13 well, yes, OR clears CF 22:36:17 at that point, might I suggest something like: mov temp, -1 / bsr / cmov temp / add ? 22:36:43 yeah, that seems easier than any of the hackiness >_< 22:37:31 I think like in general almost all instructions are expected to set (even if like, undefined) most of the flags? and the ones that don't are weird exceptions like inc/dec and the variable shifts 22:37:58 well, for others it says "unaffected" 22:38:28 erm, better stated "of instructions that set some flags, they usually set them all" I think 22:38:29 stassats: unaffected are left through. Undefined, it depends. Likely because of stuff like an incompatibility between 8088 and 8086. 22:38:50 ok, found the description: "The values of flags listed as undefined may be changed by the instruction in an indeterminate manner." 22:38:50 22:38:55 if I remember right the thing is that even if some flag makes no sense for an instruction, if they left it unaffected it'd create a flag dependency 22:39:01 so it has to be set-but-undefined 22:39:15 and I think that's the whole problem with inc/dec? 22:39:27 Fiora: most of these instructions were specced up before intel had ever heard of superscalar execution. 22:39:58 I guess so... those are the only ones I can think of, of like, the ones people actually use though 22:40:02 Fiora: yup. inc and dec tend to create false dependencies, all that to optimise for cmp/inc/jcc. 22:40:38 I remember reading that on sandy bridge they actually insert extra uops for every variable shift instruction to handle the sometimes-but-not-always flag update thing 22:40:43 and then they throw the uop away if it turns out the flags got overwritten later, I think? 22:40:50 the current unsigned integer-length doesn't seem to be worth improving with cmovs or other things: BSR RDX, RAX JEQ L0 INC RDX L0: XOR EDX, EDX 22:40:53 (since I think variable shift doesn't change flags if the shift is 0?) 22:41:15 and now they're like, introducing "shift that doesn't affect flags" instructions in BMI2 even... probably just because of this.... 22:42:29 stassats: I'm assuming there's a pair of jmp somewhere in these. But yup, that branch is likely very well predicted. I'd probably move the xor to elsewhere in fact. 22:42:57 right, JMP L1 after INC 22:43:43 stassats: you could try to assemble xor / jmp in *elsewhere*. That way non-zero values don't have to jump over a single instruction. 22:44:40 Bike_ [~Glossina@67-5-223-150.ptld.qwest.net] has joined #sbcl 22:45:12 -!- Bike [~Glossina@67-5-210-24.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 22:45:16 -!- Bike_ is now known as Bike 22:45:44 -!- davazp [~user@31.200.128.121] has quit [Ping timeout: 252 seconds] 22:50:07 not sure how to do that 22:50:22 look at the allocation functions. 22:51:03 i don't think it will matter that much anyway 22:51:20 (assemble (*elsewhere*) (emit-label ZERO) (xor) (jmp END)) 22:52:09 well, i'll try it tomorrow just to see how it works 22:52:32 that'll shave like 4 bytes off the usual path. 22:53:25 is a zero super-uncommon in those kinds of cases? 22:53:58 In my code, yes. 22:58:23 Bike_ [~Glossina@67-5-250-200.ptld.qwest.net] has joined #sbcl 23:00:48 -!- Bike [~Glossina@67-5-223-150.ptld.qwest.net] has quit [Ping timeout: 264 seconds] 23:03:31 -!- nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:06:06 davazp [~user@31.200.128.121] has joined #sbcl 23:07:29 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 23:17:38 -!- robgssp [~user@2620:8d:8000:e50:21c:c0ff:fea3:7cc5] has quit [Remote host closed the connection] 23:22:38 Bike [~Glossina@67-5-250-200.ptld.qwest.net] has joined #sbcl 23:24:32 -!- Bike_ [~Glossina@67-5-250-200.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 23:26:51 drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 23:47:37 ASau` [~user@p5797F5CF.dip.t-dialin.net] has joined #sbcl 23:50:50 -!- ASau [~user@p5797F4B2.dip.t-dialin.net] has quit [Ping timeout: 245 seconds] 23:51:38 -!- davazp [~user@31.200.128.121] has quit [Remote host closed the connection]