IRC channel logs
2017-11-30.log
back to list of logs
<wingo>i have another little compiler speedup; cse on big files was taking quadratic time <ArneBab>that's a *little* speedup? Did you already check the impact? <wingo>yes, it can be large, depends on the file size <ArneBab>Nice! I assume that this might strongly reduce the long compilation times some people reported here when using lots of macros with large inline code. <mistnim>I set the LD_LIBRARY_PATH to the dir where I have the .so file but I still can't dynamic-link to it. Why could it be? <wingo>with 2.2.2, -O2 compile time on that file is 147.2s (!!!). with stable-2.2, it's 32.1s <wingo>naturally the cse changes don't affect -O1 compile time; i assume a bit of the difference is the change to slot-allocation yesterday, and a bit is the weak table stuff from earlier this month <wingo>i think we could improve -O1 time further by somehow disabling the lazy vars optimization for -O1 compiles. if i simply replace compute-lazy-vars by a shortcut that returns empty-intset, that goes down to 14.9s <wingo>i guess we need to make a 2.2.3 nowish :) <civodul>cool, right in time for core-updates! <civodul>IIUC, disabling lazy vars means that some variables would be live longer than necessary <wingo>no -- the issue is that there would be more shuffling around calls <wingo>the lazy vars optimization attempts to make it so that a variable gets allocated right into the place where a call will need it as an argument <wingo>without the optimization, the var will have to be copied up or possibly shuffled into place for a call <wingo>not so bad in the end of course :P <civodul>well i suppose this could always be turned off at -O0 <wingo>no, optimization levels don't affect slot allocation strategy currently <wingo>so the optimization is always on. currently the only diff between -O0 and -O1 is that O1 runs peval <civodul>so the question is whether to remove lazy vars in the "dumb" allocator that you added <wingo>i didn't really add a new allocator <wingo>just a different implementation of one piece of it for functions without back-edges (loops) <wingo>no need to compute SCCs in that case <civodul>i just did a 'git pull' so i can understand better now :-) <wingo>numbers on master for compiling that file are slightly higher (19.2s at -O1 / 34.9s at -O2) but otherwise in line; i think i am ok with that right now <civodul>in an ideal world it could take a couple of seconds at -O0, but i understand that's easier said than done <civodul>did you check whether this affects heap usage? <wingo>mmm, the cse change should not affect heap usage. <wingo>the scc change may improve things but i don't have solid numbers <wingo>civodul: pushed something to 2.2 and master to allow the lazy vars optimization to be disabled under -O1 / -O0 <wingo>compile time for that test file down to 14.4s fwiw <wingo>rekado: when you ran your compressability tests on .go files, were those files compiled with optimizations or no? <rekado>wingo: they were built with something equivalent to -O0, but with partial evaluation, according to guix/build/compile.scm <wingo>sneek: later tell rekado: sounds like equiv of -O1. anyway yes there is a lot of duplication there, am working on avoiding producing some of the more egregious bits <civodul>maybe we need a THUMB mode for the Guile VM ;-) <wingo>ah, got it down to 11.7s... getting somewhere <sneek>daviid, lloda says: the code I pasted doesn't allocate anything on the C side. It's also shorter overall. Still, your choice! <daviid>mistnim: if all thesesteps you reported in the email about dynamic-link "libvigra_c" are correct, it is highly probably that the cause is another unavailable lib upon which libvigra_c depends ... this, by the way, is a 'guile' related problem (in this case it probably is a lack of otherlib problem), not a guile-cv problem <daviid>then to track that you should try 'ldd libvigra_c.so' and look if everything is 'found' <ftknox>does anybody know of a good simple example on how to make a HTTPS request using guile? I know that I have to use GnuTLS-guile to bridge between a TLS socket and a Scheme I/O socket, but I cannot seem to figure out how to piece the parts all together <mistnim>daviid, you are right, it says it doesn't libjpeg although libjpeg-dev is installed on my debian <daviid>mistnim: try 'aptitude purge libjpeg-dev', the 'apt-get install libjpeg-dev ' again (just to eliminate the low propabiblity that something went wrong in the preceding install) <daviid>hum, weird, anyone has an idea what could cause this? <daviid>mistnim: could you try to make clean and make libvigra_c again <daviid>and carefully read the output, you probably missed some in the first place <mistnim>daviid, I can say that ldd says it is looking for a libjpeg.so.9, but I don't have that file named exactly that way in /usr/lib <mistnim>just libjpeg.so, not sure if it matters <daviid>after the above reinstall steps on debian <daviid>here ldd report it found libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f0eeb0e5000) <daviid>I am surprised yur lok for libjpeg.so.9, since you are on strech and I am on buster <mistnim>recompiling didn't help, make install says this though, not sure if it matters: Set runtime path of "/usr/local/lib/libvigra_c.so" to "" <mistnim>I have libjpeg.so.62 too in /usr/lib <daviid>in /usr/lib ? that does not sound a proper location <mistnim>sorry, I mean somewhere in /usr/lib not precisely there <daviid>don't know about th runtime path question you asked, maybe someoneo ere knows ... help welcome <daviid>mistnim: ah ok, let's be precise :), the it should find it, <daviid>run ldd on the newly installed to check <mistnim>yes I also have it in /usr/lib/x86_64-linux-gnu/libjpeg.so.62 <daviid>you see, it tries to look for another libjpeg lib <daviid>and I don't know why, anyone here has an idea? dsmith-work maybe? <mistnim>could having guix installed be an issue? <daviid>mistnim: could you try to ask on #debian <daviid>mistnim: also, try 'dpkg -l | grep libjpeg' and see if there are any suspicious libjpeg there, how come you have a .9 version is a mistery ... <daviid>mistnim: I'm on #debian thanks (just connected to see if someone aswers ..) <daviid>mistnim: hum, would it be you miss one <daviid>here, in addition to the one you list, I also have <daviid>see the #debian answer as well... <daviid>mistnim: try 'apt-get install libjpeg8', clean and make libvigra_c again (see the option you need to pass in guile-cv INSTALL recommendations and let's see if that slves the problem <daviid>your cmake does not report any error, right? <daviid>error/warnings, it fins Vigra and all other things it needs <daviid>ah, run aptitude and search for libjpeg ... <daviid>yur version is prob ineriror to the buster one <mistnim>daviid, I don't know how to use strace <mistnim>strace libvigra_c.so reports permission denied of something <daviid>mistnim: no, let me find an example <mistnim>otherwise I'll just try to upgrade to buster <daviid>strace -o strace.out guile -c "(dynamic-link \\"libvigra_c\\")" <daviid>i don't think you should upgrade to buster because of that <daviid>you have a weird installation, no package should try to refer to ibjpeg9, that version does not exists... <mistnim>format and install buster from zero then <daviid>the error you just paste is a guile error <mistnim>it's quite an old installation anyway, I installed it when stretch was still testing <daviid>also, guile fails to install your locale <daviid>mistnim: you should try to solve this first <daviid>your strace report reports another error, <mistnim>that is given when I run guile from guix, but even if I run the original guile2.0 from debian I get the file missing of libvigra_c <daviid>ok, not sure what causes the system to look for .9 libjpeg version, which is worth trying to solve <daviid>it could be the guix version does not have libjpeg? don't know <daviid>no forget about that, the problem is ldd reports it looks for a lib that does not exists <daviid>you should insist on #debian maybe? <daviid>if you have guix installed, could you find the guix libjpeg and run ldd there <mistnim>the libjpeg version inside guix is .9 <daviid>i was almost sure of something like that <daviid>you should talk on #guix and ask how to maintain compile lib on debian when guix is installed ... now you have 2 guile as well ... and your PATH are incorrect (all related PATH var...) I think <daviid>yu could 'purge' guix and try again, to save time ... <mistnim>I'll try something else tomorrow, now I have to go, bye <daviid>lloda: I kept a copy of your example locally, for later use if I need... the thing is that I don't know (next to nothing) libguile, hence I can read it but I could not write any, without studying ... where as pure C code, for these snipsets, are so 'clean', and I can ask for help on ##c ... sincerely, I really don't see any advanytages of using libguile here, but again, many thanks for your help and this example.