00:42:27 hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has joined #sbcl 01:20:42 -!- slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Ping timeout: 276 seconds] 02:23:05 -!- hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has quit [Quit: Linkinus - http://linkinus.com] 02:26:38 so, on two-level card tables again. If we're going to use two writes, seems to me there are better ways than with a two-level scheme. 02:28:08 e.g. if we randomize the topmost bits a bit during memory range allocation, I think that considering the top and middle 21 bits in an address as independent hash values doesn't seem too bad. 02:29:54 with a bloom filter of 2^21 bits, and ~400 written pages (what I observe with 4k pages, between GCs) that's a false positive rate of ~1.5e-7 02:37:39 (and, actually, if we observe locality, as I'd expect, the odds are even better...) 03:14:17 I wonder if it's faster to LEA/jmp or jmp [ea]. 04:14:52 also wonder why we don't bother converting sub to neg/add when the dst and arguments don't fit. 05:05:48 slyrus_ [~chatzilla@99-27-204-74.lightspeed.irvnca.sbcglobal.net] has joined #sbcl 05:35:56 meh, not worth it, anyway. 05:45:00 -!- cmm [~cmm@109.65.214.78] has quit [Quit: leaving] 05:46:28 tcr1 [~tcr@84-72-20-159.dclient.hispeed.ch] has joined #sbcl 06:15:55 ok, so we upgraded sbcl to latest and are lookign at the gc log file 06:16:16 in this test run, the dynamic size is 2GB and bytes-consed-between-gcs is 1GB 06:16:30 smaller to provoke out-of-memory errors faster 06:16:42 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 06:17:11 we're getting GC starts when the total bytes allocated is ~75MB, though occassionally it starts when it's up to 1GB 06:17:18 I really don't know how to read the rest of the numbers yet 06:17:54 especially as to figuring out why GC is happening at all, and how to reduce the number of GCs to reduce the count o mass thread interruptions 06:18:28 I presume the table after 'GC Start' is the pre-GC figures, and the one after 'GC End' is post-GC figures 06:45:21 cmm [~cmm@bzq-109-64-210-38.red.bezeqint.net] has joined #sbcl 06:50:28 -!- cmm [~cmm@bzq-109-64-210-38.red.bezeqint.net] has quit [Read error: Operation timed out] 06:57:22 -!- tcr1 [~tcr@84-72-20-159.dclient.hispeed.ch] has quit [Quit: Leaving.] 07:06:59 Phoodus: perhaps the opposite way would be better - make gc more often, then it might be (much) faster and not be that bad? 07:08:49 flip214: no. GC is single threaded. 07:08:56 You lose a lot on throughput. 07:12:52 pkhuong: but maybe it's faster if called more often, so that (* N time) gets smaller? 07:13:09 I've seen (gc :full t) take about 1 minute one time ... 07:21:00 cmm [~cmm@bzq-79-180-208-163.red.bezeqint.net] has joined #sbcl 07:24:03 unlikely, given Phoodus's usage profile. 07:59:30 tcr1 [~tcr@217-162-207-189.dynamic.hispeed.ch] has joined #sbcl 08:00:02 re 08:00:43 yeah, stopping all the threads seems to be a huge latency for doing it often with just short processing in the GC state 08:01:27 we do have some known bugs that are having indeterminate effects on memory usage atm, but I'm also trying to get a handle on tuning the GC, trying to make it not run as often 08:02:21 that's the thing that puzzles me, GC taking fair portions of time when the allocation over a 30 second run is much smaller than the nursery 08:38:54 -!- ASau [~user@176.14.113.149] has quit [Ping timeout: 255 seconds] 08:50:23 hlavaty [~user@91-65-223-81-dynip.superkabel.de] has joined #sbcl 09:43:11 -!- Phoodus [~foo@wsip-24-234-75-217.lv.lv.cox.net] has quit [Ping timeout: 246 seconds] 11:40:05 Phoodus [~foo@wsip-24-234-75-217.lv.lv.cox.net] has joined #sbcl 11:47:49 -!- loke [~elias@bb220-255-249-12.singnet.com.sg] has quit [Read error: Connection reset by peer] 11:48:10 loke [~elias@bb116-14-205-237.singnet.com.sg] has joined #sbcl 13:26:36 workthrick [~mathrick@emp.nat.sdu.dk] has joined #sbcl 13:41:09 -!- loke [~elias@bb116-14-205-237.singnet.com.sg] has quit [Read error: Connection reset by peer] 13:42:00 loke [~elias@bb119-74-190-224.singnet.com.sg] has joined #sbcl 13:43:54 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 13:51:04 hargettp [~phil@dhcp-161.mirrorimage.net] has joined #sbcl 14:17:28 homie [~levgue@xdsl-78-35-135-153.netcologne.de] has joined #sbcl 14:53:53 -!- hargettp [~phil@dhcp-161.mirrorimage.net] has quit [Quit: leaving] 14:54:24 hargettp [~phil@dhcp-161.mirrorimage.net] has joined #sbcl 15:32:43 -!- slyrus_ [~chatzilla@99-27-204-74.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 240 seconds] 15:39:41 -!- antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 15:40:16 antgreen [~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com] has joined #sbcl 15:55:51 -!- tcr1 [~tcr@217-162-207-189.dynamic.hispeed.ch] has quit [Quit: Leaving.] 16:35:57 rpg [~rpg@mpls.sift.info] has joined #sbcl 16:44:38 -!- hlavaty [~user@91-65-223-81-dynip.superkabel.de] has quit [Read error: Operation timed out] 17:55:09 -!- hargettp [~phil@dhcp-161.mirrorimage.net] has quit [Quit: leaving] 18:07:16 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 260 seconds] 18:28:56 -!- rpg [~rpg@mpls.sift.info] has quit [Ping timeout: 252 seconds] 18:35:18 -!- mtd [~martin@chop.xades.com] has quit [Ping timeout: 276 seconds] 18:35:29 mtd [~martin@chop.xades.com] has joined #sbcl 18:50:04 tcr1 [~tcr@77-58-246-74.dclient.hispeed.ch] has joined #sbcl 19:07:28 flip214 [~marek@h081217084238.dyn.cm.kabsi.at] has joined #sbcl 19:07:28 -!- flip214 [~marek@h081217084238.dyn.cm.kabsi.at] has quit [Changing host] 19:07:28 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 19:30:11 ASau [~user@95-26-236-243.broadband.corbina.ru] has joined #sbcl 19:49:51 -!- Phoodus [~foo@wsip-24-234-75-217.lv.lv.cox.net] has quit [Read error: Connection reset by peer] 20:07:08 -!- flip214 [~marek@unaffiliated/flip214] has quit [Quit: Leaving] 20:14:34 -!- homie [~levgue@xdsl-78-35-135-153.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:51:39 pkhuong: ping 20:56:30 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 20:57:02 fe[nl]ix: pong 20:58:22 would it be too difficult to build both GCs, and select the one to use at startup ? 20:58:29 like the sun jvm 20:58:38 yes 20:58:40 that way people could very easily test them 20:58:49 pretty hard. 20:58:51 it changes codegen. 20:58:53 It's a build-time option. 20:59:07 you'd need to recompile everything, unless you want the overhead of both. :) 20:59:08 Until someone sponsors a JIT for SBCL, anyway. 21:01:55 it's a hard change to benchmark though 21:02:28 You can't just look at a couple hot spots, you have to do enough work to trigger GCs... 21:53:08 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 21:59:29 slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has joined #sbcl 22:22:37 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 22:31:18 -!- cmm [~cmm@bzq-79-180-208-163.red.bezeqint.net] has quit [Ping timeout: 252 seconds] 22:33:27 cmm [~cmm@bzq-79-176-200-19.red.bezeqint.net] has joined #sbcl 22:41:20 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 22:46:06 hargettp [~hargettp@pool-71-184-183-245.bstnma.east.verizon.net] has joined #sbcl 23:16:59 -!- tcr1 [~tcr@77-58-246-74.dclient.hispeed.ch] has quit [Quit: Leaving.] 23:35:28 loke_ [~elias@bb121-6-225-2.singnet.com.sg] has joined #sbcl 23:35:52 -!- slyrus_ [~chatzilla@173-228-44-88.dsl.static.sonic.net] has quit [Ping timeout: 258 seconds] 23:38:51 -!- loke [~elias@bb119-74-190-224.singnet.com.sg] has quit [Ping timeout: 240 seconds]