00:31:17 blackwol` [~blackwolf@ool-4575fc51.dyn.optonline.net] has joined #sbcl 00:32:56 -!- blackwolf [~blackwolf@ool-4575fc51.dyn.optonline.net] has quit [Ping timeout: 246 seconds] 01:01:39 -!- cmm [~cmm@bzq-79-182-209-72.red.bezeqint.net] has quit [Ping timeout: 252 seconds] 01:02:38 cmm [~cmm@bzq-79-182-209-72.red.bezeqint.net] has joined #sbcl 01:27:50 echo-area [~user@182.92.247.2] has joined #sbcl 01:29:02 LiamH [~healy@pool-74-96-18-66.washdc.east.verizon.net] has joined #sbcl 01:44:12 -!- echo-area [~user@182.92.247.2] has quit [Read error: Connection reset by peer] 01:44:54 echo-area [~user@182.92.247.2] has joined #sbcl 02:33:58 homie` [~levgue@xdsl-78-35-128-221.netcologne.de] has joined #sbcl 02:34:03 -!- homie [~levgue@xdsl-78-35-170-195.netcologne.de] has quit [Read error: Operation timed out] 02:46:21 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 02:46:27 -!- specbot [~specbot@pppoe.178-66-47-87.dynamic.avangarddsl.ru] has quit [Disconnected by services] 02:46:29 specbot [~specbot@pppoe.178-66-2-170.dynamic.avangarddsl.ru] has joined #sbcl 02:48:28 huangjs [~huangjs@190.8.100.83] has joined #sbcl 02:50:04 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 03:03:24 -!- CampinSam [~Sam@24-176-98-217.dhcp.jcsn.tn.charter.com] has quit [Quit: leaving] 03:08:17 slyrus_ [~chatzilla@99-28-161-110.lightspeed.miamfl.sbcglobal.net] has joined #sbcl 03:22:10 -!- ASau [~user@176.14.176.32] has quit [Remote host closed the connection] 03:25:37 ASau [~user@176.14.176.32] has joined #sbcl 04:24:38 -!- LiamH [~healy@pool-74-96-18-66.washdc.east.verizon.net] has quit [Ping timeout: 246 seconds] 04:40:32 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 05:28:29 sdemarre [~serge@91.176.154.85] has joined #sbcl 06:40:26 -!- sdemarre [~serge@91.176.154.85] has quit [Ping timeout: 246 seconds] 06:44:02 -!- homie` [~levgue@xdsl-78-35-128-221.netcologne.de] has quit [Read error: Connection reset by peer] 06:44:38 homie` [~levgue@xdsl-78-35-128-221.netcologne.de] has joined #sbcl 06:48:26 nikodemus [~nikodemus@188-67-13-181.bb.dnainternet.fi] has joined #sbcl 06:48:26 -!- ChanServ has set mode +o nikodemus 06:56:19 good morning 07:20:47 -!- nikodemus [~nikodemus@188-67-13-181.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 07:57:01 joshee [~joshe@opal.elsasser.org] has joined #sbcl 07:57:27 -!- lichtblau [~user@port-92-195-61-68.dynamic.qsc.de] has quit [Ping timeout: 248 seconds] 07:57:27 -!- joshe [~joshe@opal.elsasser.org] has quit [Ping timeout: 248 seconds] 07:58:13 -!- Neronus [christian@heraklit.ayous.org] has quit [Ping timeout: 248 seconds] 07:58:18 Neronus [christian@heraklit.ayous.org] has joined #sbcl 08:01:57 nikodemus [~nikodemus@188-67-13-181.bb.dnainternet.fi] has joined #sbcl 08:01:58 -!- ChanServ has set mode +o nikodemus 08:06:09 -!- ASau [~user@176.14.176.32] has quit [Remote host closed the connection] 08:06:33 Kryztof [~user@81.174.155.115] has joined #sbcl 08:06:33 -!- ChanServ has set mode +o Kryztof 08:08:00 ASau [~user@176.14.176.32] has joined #sbcl 08:13:59 borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 08:15:00 lacedaemon [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 08:15:51 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Disconnected by services] 08:15:57 -!- lacedaemon is now known as fe[nl]ix 08:16:50 brown`` [user@nat/google/x-zszmkognyzqmdybw] has joined #sbcl 08:16:53 -!- nikodemus [~nikodemus@188-67-13-181.bb.dnainternet.fi] has quit [Ping timeout: 248 seconds] 08:17:24 antoszka_ [~antoszka@cl-113.waw-01.pl.sixxs.net] has joined #sbcl 08:18:40 kanru [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has joined #sbcl 08:19:56 snafuchs [foobar@care.boinkor.net] has joined #sbcl 08:21:32 -!- brown` [user@nat/google/x-trsxsswrbjkzxtcd] has quit [*.net *.split] 08:21:33 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [*.net *.split] 08:21:33 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [*.net *.split] 08:21:33 -!- kanru_ [~kanru@kanru-1-pt.tunnel.tserv15.lax1.ipv6.he.net] has quit [*.net *.split] 08:21:33 -!- antifuchs [foobar@care.boinkor.net] has quit [*.net *.split] 08:21:35 -!- snafuchs is now known as antifuchs 08:31:01 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 08:37:46 morning 08:38:07 hi pkhuong 08:38:11 barriers don't even break the build. Now to see if they catch all writes (: 08:39:20 also, I never realized how cheap RAM is getting. 6x8GB for 400 CAD?! Just when 24 GB starts feeling a bit cramped ;) 09:10:55 -!- antoszka_ is now known as antoszka 09:11:10 -!- antoszka [~antoszka@cl-113.waw-01.pl.sixxs.net] has quit [Changing host] 09:11:10 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 09:14:21 what desktop cpus work with 48GB? 09:17:06 intel's "extreme" cpus seems to 09:17:31 I have dual X5660 for research. 09:18:09 I almost went for quads (it's not like CPUs are getting much faster these days, and sockets are pretty stable), but I was afraid of power supply issues. 09:19:19 yeah, with xeons your wallet will be much thinner until you hit the memory limit 09:19:46 the additional cost for ECC registered isn't that bad now. 09:19:47 although i7 extreme supports 64GB, which should be enough for common desktop tasks 09:20:27 also, I'm never again working with non-ECC RAM. 09:20:27 hmm, the dell website says max. 12GB for desktop systems 09:20:53 pkhuong: ahh, ECC is overrated ... buy cheap RAM, you'll never see an error ;) 09:20:57 pkhuong: did you encounter too many issues? 09:21:02 stassats`: yes. 09:21:08 flip214: beg to disagree. 09:21:49 that was meant as a joke ... yes, I've had crashing machines too. ECC at least tells you what's wrong. 09:22:00 ECC fixes it. 09:22:29 ECC can fix one bit per word, but can detect more. (or so I read just now.) 09:22:34 i prefer "quick and dirty" 09:23:12 borkman`: right. fixes single error, detects double errors. I've never had the latter (or it went undetected). 09:23:48 do you get more errors when flying in an airliner? 09:23:50 stassats`: and one day you try and figure out why trivial changes to SBCL breaks the build, finally try it out on a different box, and realise you've got bad ram. 09:24:33 I try to time my flights so I can sleep to minimise jetlag ;) 09:24:42 I did a debian dist-upgrade with bad ram in my laptop once. Recovering from that was ... tedious 09:25:13 well, ecc ram can go bad too, can't it? 09:25:24 stassats`: it'll be detected and logged. 09:27:01 ... *cache* is ECCed (or at least parity-checked) nowadays! 09:27:20 on what cpus? 09:27:32 yours, for instance. 09:27:53 second gen iX? 09:27:54 I$ steals ECC bits for branch prediction. D$ use them. 09:28:02 K8 had ECC cache. 09:32:40 lichtblau [~user@port-92-195-61-68.dynamic.qsc.de] has joined #sbcl 09:41:10 nikodemus [~nikodemus@cs27100107.pp.htv.fi] has joined #sbcl 09:41:10 -!- ChanServ has set mode +o nikodemus 09:50:04 yeah, but there are no ECC notebooks 09:50:21 fe[nl]ix: 'sok, notebooks are for SSH ;) 09:52:14 anyone interested in shaving off ~1% of sbcl core size and making it a small bit faster? 09:52:48 flip214: always. 09:52:49 flip214: you should tell what you did without asking 09:53:00 stassats`: that wouldn't be fun 09:53:04 and the work is not finished 09:53:17 I just have a script that estimates a bit of savings 09:53:37 flip214: come back when it's ready. 09:53:47 or at least tell what are you doing 09:57:57 stassats`: http://paste.lisp.org/display/129279 09:58:13 finding common opcode sequences at the end of functions 09:58:39 so, when assembling new functions, the end of many can be replaced by a "JMP some-fixed-location" with the shared bytes. 09:59:00 so, how will it make sbcl faster? 10:03:51 by decreasing icache use? 10:04:16 shaving a cacheline off on many functions should help a bit, I guess 10:05:24 i don't follow 10:06:12 you still execute the instructions, don't you? 10:06:25 flip214: jumping isn't free either 10:06:25 it really depends. I think everyone agrees that threaded code uses less space, but I'm not convinced it'll result in perf gains. 10:06:39 flip214: neither is loading an additional I$ line. 10:06:43 stassats`: yes, but icache is reduced. 10:06:51 flip214: is it? 10:06:57 nikodemus: of course not, but absolute jumps get resolved fairly early. 10:11:35 I've implemented that sharing for the gcc => assembler chain, and it reduced (normal) binary size by ~1.2% 10:11:35 so I'm fairly sure that icache use is decreased 10:11:35 -!- flip214 [~marek@unaffiliated/flip214] has quit [Excess Flood] 10:11:53 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 10:12:40 shrinking core is good. improving performance is even better -- benchmarks will tell 10:13:17 flip214: all of our code must be PIC. We'd have to either share within the same code object, or pre-assemble fragments in static space. 10:13:39 http://paste.lisp.org/display/129280 # sb-ext or sb-int? 10:13:47 I'd think the latter approach, for some common sequences, is easier 10:13:58 i think user code could use that too, but writing it isn't exactly rocket science... 10:14:16 nikodemus: why not deadlines? 10:15:02 the user can just specify the same absolute deadline... which is pretty useful if the body doesn't execute near-instantaneously. 10:16:54 true 10:20:28 it's just that my current use-case has a timeout in the API, and it's callees also use timeouts -- so maybe sb-int for now 10:20:53 i still intend to add :deadline arguments to our interfaces 10:28:04 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 245 seconds] 10:50:26 tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has joined #sbcl 10:54:50 attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has joined #sbcl 10:54:51 -!- attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has quit [Changing host] 10:54:51 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:12:52 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:31:17 attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has joined #sbcl 11:31:17 -!- attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has quit [Changing host] 11:31:17 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:41:11 -!- cow-orker [~foobar@pogostick.net] has quit [Remote host closed the connection] 12:25:01 tsuru`` [~charlie@adsl-74-240-217-131.bna.bellsouth.net] has joined #sbcl 12:27:00 -!- tsuru` [~charlie@adsl-98-87-43-139.bna.bellsouth.net] has quit [Ping timeout: 265 seconds] 12:37:30 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 12:39:14 attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has joined #sbcl 12:39:14 -!- attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has quit [Changing host] 12:39:14 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:39:45 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 12:41:19 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:55:43 -!- borkman` is now known as borkman 13:30:47 leuler [~user@p549042D9.dip.t-dialin.net] has joined #sbcl 13:48:03 attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has joined #sbcl 13:48:16 -!- attila_lendvai [~attila_le@catv-89-135-133-215.catv.broadband.hu] has quit [Changing host] 13:48:16 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:49:59 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 13:53:33 -!- tsuru`` is now known as tsuru` 13:53:52 Kryztof [~user@81.174.155.115] has joined #sbcl 13:53:52 -!- ChanServ has set mode +o Kryztof 14:04:17 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 14:06:59 -!- ASau [~user@176.14.176.32] has quit [Remote host closed the connection] 14:09:20 ASau [~user@176.14.176.32] has joined #sbcl 14:26:32 re: random floats. After the two references prxq gave did not provide a convincing motivation for me that random floats should be resolved finer near zero, I searched for other sources and found: "Gaussian Random Number Generators", David B. Thomas et al., ACM Computing Surveys, Vol. 39, No. 4, Article 11, 2007. 14:26:32 14:28:22 *stassats`* made slime to use sb-ext:exit when possible 14:28:59 i think i want TRACE to be more thread friendly 14:29:07 On pages 11:18 - 11:20 they explain that this is needed to generate high quality normally distributed values: Every (?) method for that depends on a logaritm for the tails of the distribution and the finer resolution is needed to reach out to 10 sigma. 14:29:22 (1) making it easy to separate outputs for threads into different streams / logfiles 14:29:25 i want to make a slime interface to trace, with bells and whistles 14:29:58 (2) adding a bit of locking and thread-name annotation when tracing to a single stream from multiple threads 14:30:42 something like sb-sprof, when you can collapse trees and jump around 14:30:48 s/sb-sprof/slime-sprof/ 14:31:00 stassats`: There's some first steps there already 14:31:20 making *trace-output* go to a special buffer 14:31:23 tcr: it's possible to redirect output of trace, but it's broken 14:31:29 yes 14:32:00 leuler: not all, but ones based on Box-Mueller certainly 14:32:06 and not all that cool, implementation should provide some machine readable trace format 14:39:34 Kryztof: thanks. 14:41:31 stassats`: (defmethod trace-entry (level call (tracer my-tracer)) ...) ? 14:41:45 and trace-return, correspondingly 14:42:04 something like that 14:42:34 just make a sax or klacks producer or consumer or whatever it is, and let the xml library take care of the rest 14:43:14 leuler: another option is to approximate the inverse CDF with a polynomial (: 14:50:14 -!- nikodemus [~nikodemus@cs27100107.pp.htv.fi] has quit [Quit: Ex-Chat] 14:50:16 pkhuong: thanks, too. The paper I cited seems not to like that method? See page 11:21. 14:51:19 pkhuong: What would be your method of choice for high-quality fast normally distributed floats? 14:52:13 depends on the other requirements. if it's pure speed, either box mueller or a piece-wise approximation. 14:52:45 if I wanted to be able to work fancy tricks, a chebyshev polynomial (piecewise if needed). 14:53:31 Would these gain in quality in the tails from "better" random floats near zero? 14:55:32 I suspect so, actually 14:56:14 for anything with a tail, you need some way of probing it, so by having a change of resolution 14:56:22 floats near zero are awfully convenient for that 14:56:58 Kryztof: but you don't have the same resolution near 1, so meh. 14:57:27 plus, we run into issues with the output precision anyway. 14:58:19 oh, nifty, I have 60 bits around 0, but it's just going to map to the same old 53 bits for the return values (which'll approach -infty) 15:00:15 well, but doesn't our current scheme have many fewer than 53 bits around 0? 15:01:40 pkhuong: I don't understand. The log compresses things such that one would have to say "approach -1000" or something, except for exactly 0, where its -infinity. 15:04:05 Kryztof: no, it's like a fixed point 53 bit. 15:04:26 We work in [1,2), where IEEE FP is like fixed point, and subtract 1. 15:04:56 but yes, leuler's point is that the mapping is not one-to-one 15:05:00 so we have 2^53 distinct, equiprobable, values in [0, 1) 15:05:05 Currently, the smallest positive random floats (from (random 1.0f)) would be (expt 2 -24) and (expt 2 -23) or such, the log of which (base 2 for simplicity) would be -24 and -23. With finer resolved random floats we are able to get a lot of values between -24 and -23, too. Each of which then has precision of 53 bits minus (ld 24) or such. 15:06:06 And lots of values smaller than -24, too, obviously. Even much smaller. 15:08:16 again, there's the same problem around 1, in any case. 15:10:01 for a normal distribution and doing Box-Muller, I'd expect far fewer problems with not having an accurate centre than not having an accurate tail 15:10:28 the centre problem will central-limit-theorem itself away; if an experiment is sensitive to the tails, you need the resolution there 15:11:48 if it's sensitive to the tails, FP might not be the best representation, though. I was thinking of a CDF-based generator, actually. 15:14:04 ah, right 15:15:39 -!- blackwol` is now known as blackwolf 15:20:30 homie`` [~levgue@xdsl-84-44-179-183.netcologne.de] has joined #sbcl 15:22:09 Kryztof: Wikipedia ("Inverse Transform Sampling") says that R uses inversion sampling with polynomials for the normal distribution. As you are R expert: Do they get both the center and the tails right? 15:23:11 I am not an R expert! (Nor really a random number expert) 15:23:23 -!- homie` [~levgue@xdsl-78-35-128-221.netcologne.de] has quit [Ping timeout: 245 seconds] 15:29:51 -!- tcr [~tcr@178-83-229-138.dynamic.hispeed.ch] has quit [Quit: Leaving.] 15:33:18 on a different topic: let's say you had 30 minutes to present your current work. Would you try and give an overview of the general ideas and how they fit together, or drill down on one specific aspect? 15:35:39 depends on the audience 15:36:50 no clue, seems to include a lot of first year masters :\ 15:39:34 overview, then 15:40:07 the most boring talks I attended as a PhD student were from other PhD students who dived all the way down in the extreme technical detail of their topic 15:40:17 normally without stopping to explain any concepts 15:42:27 thanks. Plus, this way I get to not explain this stuff that I thought everyone knew but is actually mostly a local interest. 16:21:07 -!- leuler [~user@p549042D9.dip.t-dialin.net] has quit [Quit: Lisp Stammtisch] 16:28:56 -!- slyrus_ [~chatzilla@99-28-161-110.lightspeed.miamfl.sbcglobal.net] has quit [Ping timeout: 272 seconds] 16:35:29 -!- huangjs [~huangjs@190.8.100.83] has quit [Read error: Connection reset by peer] 16:41:18 -!- foom [jknight@nat/google/x-nqnhusehgqcnrkjd] has quit [Ping timeout: 245 seconds] 16:57:05 foom [jknight@nat/google/x-xkqmsgkleqczfrxd] has joined #sbcl 17:11:44 wtf, we trigger write protection during GCs? 17:13:16 You mean, we write to write-protected pages? 17:13:29 yes 17:14:45 That seems odd, since we don't (shouldn't?) scan WP pages. 17:16:42 -!- tsuru` [~charlie@adsl-74-240-217-131.bna.bellsouth.net] has quit [Remote host closed the connection] 17:21:06 no, but something is writing in the buffers that track wp violations. 17:21:20 oh wait, never mind. 17:22:28 phew, bad assert (: 17:27:41 drl [~lat@110.139.229.172] has joined #sbcl 17:29:36 What is causing this: debugger invoked on a ASDF:COMPILE-ERROR in thread #: Error while invoking # on # 17:29:58 drl: look in the output 17:30:07 and it's not an #sbcl question 17:30:29 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 17:31:55 all right. All the writes are logged. 17:32:43 tsuru` [~charlie@adsl-74-240-217-131.bna.bellsouth.net] has joined #sbcl 17:37:21 stassats`, I see what it says, but don't understand why it happened. All I did was start slime. 17:37:52 ask in #lisp 17:38:59 OK, I'll ask tomorrow. It's very late here now. 17:55:51 -!- homie`` [~levgue@xdsl-84-44-179-183.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 18:02:13 homie [~levgue@xdsl-84-44-179-183.netcologne.de] has joined #sbcl 18:05:54 sdemarre [~serge@91.176.154.85] has joined #sbcl 18:42:50 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 246 seconds] 18:43:04 -!- whoops [whoops@2600:3c01::f03c:91ff:fe93:da36] has quit [Quit: Farewell] 18:43:27 stassats [~stassats@wikipedia/stassats] has joined #sbcl 18:43:37 whoops [whoops@2600:3c01::f03c:91ff:fe93:da36] has joined #sbcl 18:59:09 CampinSam [~Sam@24-176-98-217.dhcp.jcsn.tn.charter.com] has joined #sbcl 19:00:01 does the "exit from normal thread" test in threads.test.sh fail for everyone else? 19:00:06 It sure doesn't work on my linux box. 19:02:54 make-thread is b0rked :'( 19:51:12 pkhuong: I just ran threads.test.sh (latest head, linux x86) and it was all ok. 20:02:36 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 20:07:22 prxq [~mommer@mnhm-590c24c8.pool.mediaWays.net] has joined #sbcl 20:16:14 you're at 760de025ce5437902c8a289bc831c6f6dc92fd16 ? 20:16:39 pkhuong: I am. 20:17:23 just to conform, you ran sh run-tests.sh threads.test.sh? 20:17:49 No, actually. I ran sh threads.test.sh. 20:18:07 Use run-tests.sh, just in case? 20:18:13 Sure. 20:19:33 It's giving me a file not found about sb-posix/constants.lisp 20:20:00 borkman: running threads.test.sh won't fail. 20:21:18 It'll simply output "test exit from normal thread failed: 0" instead of "test exit from normal thread ok ok" 20:21:44 It says "ok ok" on all three lines. 20:22:18 With the test names, of course. 20:22:42 linux? 20:22:53 Yep. Ubuntu 10.04. 20:23:31 oh, wait. Might be a race condition. 20:28:34 neat. When I pin the process to a single core, the test fails, but not when I let have use all 12 cores. 20:30:01 It so happens that I'm running on a single core proc. 20:34:12 nice. :input is /dev/null, so the REPL gets an EOF as soon as it stops processing the options. 20:34:38 It's a race between reading EOF from stdin and the child thread executing sb-ext:quit. 20:36:49 a race to the exit! 20:42:03 http://paste.lisp.org/display/129294 <- less racy (: 20:47:14 no, this is broken. 20:47:39 I don't see how make-thread can work. 20:47:54 It just silently catches %end-of-the-world 20:52:40 -!- sdemarre [~serge@91.176.154.85] has quit [Ping timeout: 276 seconds] 21:31:44 -!- prxq [~mommer@mnhm-590c24c8.pool.mediaWays.net] has quit [Quit: Leaving] 21:47:34 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 21:49:22 leuler [~user@p549032B6.dip.t-dialin.net] has joined #sbcl 21:59:15 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 22:14:25 first build without write barriers. 22:14:31 (mprotect-based, that is) 22:44:31 Does it build? work? pass all the tests? How is the performance? 22:44:57 build, passing tests right now. 22:45:02 Perf is probably very bad. 22:45:14 It's full of byte-sized reads in the GC. 22:46:47 To build means already much achieved. Congrats! 22:47:54 well, fourth time's the charm 22:48:12 how many years since the first try? 22:49:03 almost exactly one year 22:49:35 Needs less staying power than a phd ;-) 22:50:26 What do you think is bad about byte-sized reads? 22:51:04 nothing, just that I can speed that up a lot by scanning for non-zero bytes 64 or 128 bits at a time. 22:51:53 Using SSE even? 22:51:58 right. 22:52:39 iirc, I can get the overhead during self-builds down to about what we save by exploiting huge pages. 22:52:55 The performance limiter is that you need to scan a large bit-array expected to contain mostly zeroes for ones? 22:53:13 well, wrt the additional codepaths in the GC. 22:53:26 that, and the obvious issues with the write barrier sequence. 22:54:48 in most cases, it's compiled into mov scratch, base-address / shr scratch, [constant] / and scratch, mask / mov byte [vector+scratch], 1 22:55:00 erh, [vector + scratch + constant_offset] 22:55:58 (there's a 1-card fudge factor, so we can truncate the base address and offset separately) 22:56:49 for runtime indexed accesses, it's lea scratch, [ea] / mov scratch2, scratch / shr / add / mov / work with [scratch] 22:57:18 passes tests (: 22:58:02 I'm liking the idea of using a read barrier more and more the more I think about it... Although I'll easily believe that Linux isn't set up with the memory management semantics required to support one properly. 22:58:21 pkhuong: good again! 22:59:20 nyef: that's why azul people wrote a kernel module with the required functionality 22:59:42 Yeah, exactly. 22:59:50 nyef: the azul people just PROT_NONE... 22:59:57 The kernel is a performance hack, iiuc. 23:01:39 *nyef* sighs. 23:01:49 Oh, for enough time to actually play about with such ideas. 23:02:44 https://github.com/pkhuong/sbcl/tree/card-2012-1 <- pushed. It's a dev branch. I'll rewrite history when it's more solid 23:02:50 Have you thought of using a bit instead of a byte, making the write barrier more complicated and finishing with either "or byte ptr [mem], bit", or "bts"? That would make the scan 8 times faster? Or is the added code and the read-modify-write too expensive? 23:03:06 problems with threads. 23:03:32 and the barrier sequence would be even slower to compute a bit index. 23:05:39 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:08:30 With bts the bit index is trivial, that is, no more complicated than the byte index for mov. 23:09:36 But if the problems with threads are unsurmountable ... 23:09:59 leuler: eh? it's at least one more instruction 23:16:21 It seems I don't understand what bts does. I have actually never used it so far. 23:16:22 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 23:17:03 rstill [~rstill@12.104.148.2] has joined #sbcl 23:22:55 The way I understand bts I put a bit index into a register, pass a memory address as the other operand and it accesses the index-mod-8th bit in the index-div-8th byte above that memory address. 23:35:45 bts has 2 operands: one r/m source/dest and one r or imm to choose the bit 23:39:42 yes. instead of your "mov byte [vector+scratch], 1" above one would do "bts [vector], scratch". 23:42:21 scratch can be a pretty large value."The range of the bit position that can be referenced by the offset operand depends on the operand size." 23:42:33 I forgot your constant offset. If that is not a multiple of 8, then the bts way needs an additional add to the scratch value. 23:52:10 Operand size can be 32 bits. 23:52:21 that's only 32 bits. 23:52:47 That means I have to split the index into its low 5 bits and the rest. 23:55:34 I read the description differently. With a register (instead of an immediate value) as the second operand the value in the register is taken as a bit address and can span (expt 2 32) bits with 32-bit operand size, meaning the machine does the split itself to find the byte address and the bit inside that byte. 23:55:48 -!- drl [~lat@110.139.229.172] has quit [Remote host closed the connection] 23:56:16 nope. "Some assemblers support immediate bit offsets larger than 31 by using the imme- diate bit offset field in combination with the displacement field of the memory operand." 23:57:07 -!- edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Read error: Connection reset by peer] 23:58:55 Yes. Immediates are much more restricted. With an immediate, for operand size 32-bit, only values of 0 to 31 are allowed. Presumably, because one can address bits farther away by using another memory base address (adding a constant there means just to use the displacement or add to an existing one). 23:59:08 Or so I think.