00:28:36 -!- segv- [~mb@95-91-243-156-dynip.superkabel.de] has quit [Remote host closed the connection] 01:02:30 -!- DataLinkDroid [~DataLinkD@101.171.34.16] has quit [Quit: Disconnecting -- bye] 01:13:40 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #ccl 01:18:04 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Remote host closed the connection] 01:22:10 -!- aspires [~aspires@173.247.205.34] has quit [Quit: aspires] 01:26:59 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 01:28:24 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 01:30:49 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Quit: patrickwonders] 01:31:39 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 01:54:43 -!- Fare [fare@nat/google/x-clitgjkkglzrfudn] has quit [Ping timeout: 260 seconds] 02:58:11 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 02:59:15 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 03:16:19 Blkt_ [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #ccl 03:22:34 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [*.net *.split] 03:53:51 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 04:34:39 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #ccl 04:35:47 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Remote host closed the connection] 04:45:38 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 04:55:50 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 05:59:29 -!- rme [rme@BCE091D5.78A1BA07.699BA7A6.IP] has quit [Connection reset by peer] 09:06:18 ogamita [~t@LNantes-156-76-35-103.w82-127.abo.wanadoo.fr] has joined #ccl 10:54:50 -!- svs_ [~svs@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has quit [Ping timeout: 264 seconds] 12:14:08 segv- [~mb@95-91-243-207-dynip.superkabel.de] has joined #ccl 13:46:25 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 14:05:00 rme_ [~rme@50.43.148.144] has joined #ccl 14:05:00 -!- rme [~rme@50.43.148.144] has quit [Read error: Connection reset by peer] 14:05:00 -!- rme_ is now known as rme 14:40:50 alms__ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 14:40:55 -!- alms_ is now known as alms 14:43:02 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Ping timeout: 268 seconds] 14:43:02 -!- alms__ is now known as alms_ 14:47:45 Fare [fare@nat/google/x-ozsozjsqjvzllsei] has joined #ccl 15:26:19 -!- segv- [~mb@95-91-243-207-dynip.superkabel.de] has quit [Ping timeout: 260 seconds] 15:27:27 segv- [~mb@95-91-243-207-dynip.superkabel.de] has joined #ccl 15:27:40 svs_ [~svs@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has joined #ccl 15:30:18 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #ccl 15:37:52 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 15:52:44 aspires [~aspires@173.247.205.34] has joined #ccl 16:04:43 -!- segv- [~mb@95-91-243-207-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 16:05:56 segv- [~mb@95-91-243-207-dynip.superkabel.de] has joined #ccl 16:21:46 -!- svs_ is now known as Hammertime 16:22:16 -!- Hammertime is now known as Guest13666 16:27:49 alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has joined #ccl 16:30:06 -!- dented42 [~dented42@166.70.24.149] has quit [Ping timeout: 264 seconds] 16:31:33 -!- ogamita [~t@LNantes-156-76-35-103.w82-127.abo.wanadoo.fr] has quit [Ping timeout: 248 seconds] 16:34:28 -!- Guest13666 [~svs@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has quit [Quit: Guest13666] 16:37:46 slarti [~anonymous@104-252-AGAVEBB-NM.abq.nm.agavebb.net] has joined #ccl 16:52:57 -!- aspires [~aspires@173.247.205.34] has quit [Quit: aspires] 16:57:58 aspires [~aspires@173.247.205.34] has joined #ccl 17:53:00 -!- aspires [~aspires@173.247.205.34] has quit [Quit: aspires] 17:55:00 aspires [~aspires@173.247.205.34] has joined #ccl 17:59:07 mc40 [~mc@164.138.80.251] has joined #ccl 18:04:47 photex [~photex@192.241.224.216] has joined #ccl 18:06:06 hello folks. I've been experimenting with the sbcl runtime and ccl kernel. Mostly to statically link certain things that are useful for media heavy applications such as games 18:06:32 doing nothing else but adding -lGL to the linuxx8664 Makefile for clozure causes a bit a surprise 18:06:56 when the kernel starts it allocates a *huge* amount of memory, only to immediately release it 18:07:23 this doesn't appear to happen on darwinx8664 18:08:08 on my laptop the amount of ram allocated is essentially *all* of my available RAM. On a very large desktop it only uses a portion of it 18:08:18 so the allocation would appear to be a fixed size 18:08:55 I attempted to run the kernel with valgrind --tool=callgrind with no luck 18:09:45 does anyone have an idea as to what might be responsible for this? 18:09:49 -!- aspires [~aspires@173.247.205.34] has quit [Quit: aspires] 18:09:57 again, I've modified nothing other than the Makefile 18:10:15 and that edit was to simply add -lGL to OSLIBS 18:11:14 Linking to other libraries doesn't cause this issue. It's somehow unique to linking with OpenGL on Linux. In both cases I have an Nvidia graphics card. 18:11:42 aspires [~aspires@173.247.205.34] has joined #ccl 18:12:07 I'm not sure how linking with -lGL at lisp kernel build time gets you anything more than doing (open-shared-library "libGL.so"). 18:13:04 GL is the curious case, other libraries would require it however and I'm statically linking with several. 18:13:22 or that's the goal anyway. 18:13:33 I'm trying to just understand the issue with GL 18:16:40 The lisp kernel reserves a large amount of contiguous address space at startup time. You can specify (to some degree) how large this should be with the --heap-reserve command-line argument. (e.g. --heap-reserve 100G) 18:19:04 that definitely affects the startup time 18:20:21 ./lx86cl64 --heap-reserve 5G --eval '(quit)' 0.48s user 0.43s system 99% cpu 0.912 total 18:20:27 ./lx86cl64 --eval '(quit)' 1.63s user 1.67s system 99% cpu 3.310 total 18:20:44 that was with GL 18:21:43 not much difference in time without GL 18:21:56 but it just doesn't make that initial grab of memory 18:22:54 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Quit: patrickwonders] 18:23:40 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 18:23:55 hah, excuse me, I edited the wrong Makefile 18:24:01 ./lx86cl64 --heap-reserve 5G --eval '(quit)' 0.01s user 0.01s system 95% cpu 0.013 total 18:24:05 ./lx86cl64 --eval '(quit)' 0.00s user 0.01s system 96% cpu 0.009 total 18:24:11 it's a tremendous difference 18:24:19 just because it's linked with GL 18:26:02 -!- mc40 [~mc@164.138.80.251] has quit [Quit: mc40] 18:27:53 You could try to start up with strace or use oprofile/perf to look for clues as to what's happening. I would guess that something in libGL is doing some unfriendly thing, but I really don't know. 18:28:30 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 252 seconds] 18:28:55 ok I'll try that. I attempted to use valgrind but it said: "valgrind: the 'impossible' happened: Unsupported arch_prtctl option" 18:52:49 well, it's definitely something inside libGL.so.319.37 18:52:54 unfortunately that is a black box 18:53:02 this does not affect the sbcl runtime though 18:53:31 which is a total mystery. I also would never expect something like this from any plain C app that links with OpenGL 18:53:57 and this doesn't happen to clozure on osx 18:56:05 *photex* wonders about clozure on arm linux 18:59:29 -!- aspires [~aspires@173.247.205.34] has quit [Quit: aspires] 18:59:58 When CCL starts up, it ordinarily tries to reserve a large (512gb) chunk of memory at a certain fixed address. If some library is using some of that memory, it has to use some other address, which means that the heap image gets mapped into some address other than that from which it was saved. 19:02:17 That in turn means that the entire image has to be paged in, so that addresses get adjusted, I've never seen that happen in 64-bit CCL, but it's nice to know that the code apparently works. 19:09:24 gbyers: zing! 19:10:24 pbgc [~pbgc@bl20-180-245.dsl.telepac.pt] has joined #ccl 19:13:26 that puts my mind at ease a bit 19:14:52 aspires [~aspires@173.247.205.34] has joined #ccl 19:16:12 It's generally more likely to happen in 32-bit lisps. Lisp code (whether CCL or SBCL or ...) generally isn't position-independent and contains a lot of absolute references. 19:17:42 It used to affect 32-bit SBCL on PPC, and at the time (several years ago) they just gave up and refused to run. I don't know what they do now. 19:53:20 -!- pbgc [~pbgc@bl20-180-245.dsl.telepac.pt] has quit [Quit: Computer has gone to sleep.] 20:20:50 -!- patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has quit [Quit: patrickwonders] 20:38:17 patrickwonders [~patrickwo@user-38q42ns.cable.mindspring.com] has joined #ccl 20:47:41 -!- Fare [fare@nat/google/x-ozsozjsqjvzllsei] has quit [Ping timeout: 245 seconds] 21:17:23 pbgc [~pbgc@bl20-180-245.dsl.telepac.pt] has joined #ccl 21:31:18 Fare [~fare@cpe-69-203-115-132.nyc.res.rr.com] has joined #ccl 21:32:02 -!- aspires [~aspires@173.247.205.34] has quit [Ping timeout: 264 seconds] 21:38:07 -!- pbgc [~pbgc@bl20-180-245.dsl.telepac.pt] has quit [Quit: Computer has gone to sleep.] 21:39:48 pbgc [~pbgc@2.81.180.245] has joined #ccl 21:40:59 DataLinkDroid [~DataLinkD@123.208.60.105] has joined #ccl 21:42:29 aspires [~aspires@173.247.205.34] has joined #ccl 21:59:08 -!- DataLinkDroid [~DataLinkD@123.208.60.105] has quit [Quit: Disconnecting -- bye] 22:46:40 -!- pbgc [~pbgc@2.81.180.245] has quit [Ping timeout: 264 seconds]