<ijp>there are many things about guile-sdl I will hate on, but there is one thing I like: you get fun graphics when you run 'make check' <ijp>figl unhelpfully stores itself under site/2.0 even when I compile using master <ijp>... which naturally triggered a recompilation :/ <ijp>wonderful, my sdl package is missing its pkg config file <ijp>the funny thing is, guile-sdl doesn't complain about it, but guile-2d did :) <handheldCar>libguile/.libs/lt-guile: error while loading shared libraries: libgc,so,1: cannot open shared object file: No such file or directory <ijp>huh, where did those commas come from <ijp>some locale issue maybe? <ijp>handheldCar: you mean you didn't copy-paste that? :) <ijp>well, you do have libgc installed, right? <mark_weaver>how did you install gc 7.2? from source, or from a distro package manager? <mark_weaver>in general, after installing shared libraries, you need to run 'ldconfig' to rebuild the shared library index. distro package managers do this for you, but if you install from source you need to do it yourself. <mark_weaver>(the alternative is to set LD_LIBRARY_PATH to include the relevant directory, but that's slower and generally best to avoid if you have root access) *handheldCar might need to do that with guix. <mark_weaver>or at least I'm fairly sure it does. ask on #guix for a more definitive answer. <ijp>I wonder if there is a particular version of freeimage that guile-2d requires <ijp>ice-9/boot-9.scm:117:22: In procedure dynamic-pointer: Symbol not found: FreeImage_HasPixels *ijp makes clean to be sure <ijp>hmm, if I look in configure.ac it says freeimage >= 3.0 (commented out) <ijp>apparently it's not even declared in the header file of the freeimage I have <mark_weaver>ijp: maybe try doing a web search on that symbol name? <ijp>I assume it is a difference in versions <ijp>it's certainly real, and documented <ijp>it would be helpful if I could find a NEWS for freeimage though *dje42 likes Guile's value history <dje42>Has anyone done much profiling Guile vs Python ? <dje42>Is there some feature I can turn off that might slow Guile down? [In comparing Guile with Python I want to make sure it's a fair comparison.] <dje42>Blech. Two separate sessions, one after the other. The first session Guile can add 1 1M times in 0.04 seconds. Next session, no changes, it takes 3.3 seconds. <ijp>wingo: are you using the same autotools setup for all your non-guile modules? <ijp>dje42: I'm going to be honest, I think cross-language benchmarks are nonsense <dje42>It's not just cross-language though. The implementation needs to be considered. <ijp>it's a pissing contest <dje42>If, for the sake of discussion, Guile was 100x slower than Python (it's not, but if it was) people would be less incllned to use it. <dje42>I think it's useful to at least know what the data is. <ijp>two datapoints PHP and JS <ijp>PHP is slow as balls, semantically ugly, and has portability problems due to various distros compiling in different options <dje42>I should also state that I have a very specific context in mind. I'm not just wondering for academic sake. <dje42>No one, that I know of, is thinking of adding PHP scripting to GDB. <ijp>js, was considered slow as balls, and "couldn't ever be fast" <ijp>now, you can get within an order of magnitude of native <ijp>and people were using it for years before it became fast <ijp>now let's ignore speed issues for the moment <ijp>how do you define that two programs are actually equivalent? <dje42>I see I've hit a hot button. :-) <ijp>this is not an idle question <dje42>I still claim it's useful for the particular case at hand to have the data. <ijp>and I guarantee you that if you can write two programs that are semantically equivalent, you'll be dismissed anyway, since at least one of those programs won't be idiomatic in the language it was written in <ijp>there is no way to win <dje42>I'm not trying to win. I just want some data. <ijp>suit yourself, you've heard my position <dje42>Still trying to figure out how Guile can be 100 times slower one run to the next. A project for another day. <mark_weaver>dje42: I don't agree with ijp entirely on this, but his last point is very important: if you convert a python program into scheme too precisely, that will be a very significant disadvantage to scheme. <taylanub>dje42: Maybe your system got busy with something else; test at least ten times or so, not just two .. <mark_weaver>to acheive fairness here, I think you have to write quite different code for the two languages. each must be written competently, considering both style and efficiency, in a way that is tailored to that language and implementation. <wingo>not sure what the topic is, but i've never seen 100x perf variations <wingo>something strange must be going on <wingo>perhaps gdb and libgc don't work well together? <mark_weaver>dje42: here's a challenge: you write some code to do the job in Python as best you can, and I'll do the same with Guile, and we can compare. <ijp>and make sure you don't do anything that needs to communicate with the OS, you don't want that nondeterminism <youlysses>Besides very low-level stuff, isn't Guile "quick enough" for most needs? I mean it's not trying to be a lispm language or anything... well maybe sort-of, someday... ;^) <youlysses>taylanub: Yeah -- like it's not really trying, nor needs to be operating on high-gears on that level anyway. At a certain point of abstraction and too, just general technological advancement, much of the gains and loses, becomes much-less relevant. :^P <taylanub>I remember benchmarks showing Scheme (I think Racket) being the generally fastest dynlang under the popular ones (Perl, Python, Ruby, PHP) except for JS, but last I tried to find those benchmarks again I failed ... <ijp>well, that's because scheme isn't really a dynamic language <youlysses>I mean, until we end-up rewriting GNU Mach in Guile -- and even then, I think it'll be doable on modern hardware... ;^) <taylanub>In any case it should be unsurprising that Scheme is more optimizable than most dynlangs. <taylanub>Yeah, what ijp said .. "the most static dynlang" or so. :P <taylanub>It's especially funny how much more dynamic Objective-C is than Scheme. <youlysses>Is there anything like Racket's "Scribble", implemented in Guile? <ijp>there is skribilo, which civodul assures me is capable of supporting it (thought it doesn't) <youlysses>Obviously, it wouldn't be as tex-ish in nature* <youlysses>ijp: Oh, very cool! Definetly going into my "look into further list". :^) <ijp>so you'll be wanting me to remind you again in a month, cool <civodul>wingo: we found traces of Keisuke in an unexpected area! :-) <wingo>i knew he was doing opencobol at some point <wingo>but the "gnu" part is "new" to me :) <civodul>yes, see g-p-d; i just replied to you and the maintainer <civodul>the message says their priority is to add --with-guile :-) <wingo>that would be very amusing ;) <ijp>wingo: well, if you remember, there was a guy a year or so back trying to hack guile support into opencobol ***mario-go` is now known as mario-goulart
<add^_>Wow, I wonder why I hadn't noticed that scsh is on github.. <dje42>How accurate is the report of GC time shown by ,time and ,stat ? <wingo>it doesn't measure the cost of allocation that doesn't require gc <wingo>if an allocation does require gc, then the start time is taken accurately, probably with ns precision <wingo>but there is no post-gc callback <wingo>so it just registers an async to run when the next function is called or returns <wingo>and then takes that to be the stop time <wingo>also, that's wall-clock time, not cpu time <wingo>marking is parallelized with recent libgc <wingo>dje42: regarding crazy perf differences <wingo>have you tried with GC_MARKERS=1 <wingo>i have some development build of libgc and occasionally i need to set that <dje42>Here's my testcase btw: (define (time-add n) (let loop ((i 0)) (if (< i n) (loop (+ i 1))))) <wingo>you are on a 32-bit machine i assume? <dje42>Sometimes it's .03 sec, sometimes it's 3sec. Though it never flip flops within one session AFAICT. <wingo>you know, that shouldn't cause gc at all <dje42>In the 0.03 sec case, it doesn't, usually, but if I do it enough (running again and again) eventually it'll cause one gc. <dje42>In the 3 sec case it causes 2 gcs every time. <mark_weaver>so when GC is needed, it takes a long time because there's a lot of stuff to mark. <mark_weaver>oh, 2 GCs? strange. what version of Boehm GC are you using? if you built it yourself, did you run "make check"? <dje42>Perhaps, but in the 0.03 sec case, when it does cause a gc, there's minimal perf difference (0.01 sec). <dje42>I'm using the guile that came with fc19. I haven't built my own yet (will get to that). <dje42>Is heap size what's reported with the "Memory size" output in ,stat ? <wingo>what version of libgc do they have? <dje42>"yum info gc" says version 7.2d, release 2.fc19. fwiw <dje42>In the 0.03 sec case I see "Bytes allocated, diff" in the 300k range (still seems a lot). In the 3sec case it's ~16M. Yikes. <dje42>Hmmm, without touching the file (e.g. to trigger a recompile), reloading the file changed the 3sec case to the 0.03sec case. (load "fooperf.scm") <wingo>the thing is, the loop itself doesn't cause gc <wingo>but somehow the loop runs slower? very strange <wingo>you are running the guile shell or guile in gdb? <dje42>I think I found the trigger. Something in the way gdb loads the file causes it. <dje42>gdb has a "source" command to load scripts. And I've extended it to handle .scm files. <civodul>dje42: 'time-add' is compiled, right? <dje42>If I source the script from gdb -> 3sec case. If I (load ...) it from Guile -> 0.03sec case. <wingo>then perhaps the 16M case is interpreting it? <wingo>"knowing is half the battle" ;) <dje42>the source-from-gdb case uses scm_c_primitive_load <wingo>perhaps scm_c_primitive_load doesn't do auto-compilation <dje42>[btw, it's playing with little perf things like this that build up a data set to understand perf issues later] <dje42>I'm just starting out, but one useful thing is: how many times can I call into gdb from scheme per second? my time-add testcase was reduced down from something that did a simple gdb call, and that was *slow*. at least I have a better understanding of why now <civodul>so you have to use 'load' instead of scm_c_primitive_load <civodul>so if that's from C, you have to use 'load-in-vicinity' <mark_weaver>it occurs to me: it would be possible for us to add a property to macros that are meant to act like procedures (e.g. 'load' and also macros created with 'define-inlinable'), and arrange so that when called from C, it does the right thing. <mark_weaver>not sure if it's worth the added complexity, but it would certainly be doable. <dje42>It's easy enough to have gdb's "source" command call out to Scheme to do the load (if that's easier/better). <dje42>there are also ways scripts can be auto-loaded (e.g., "gdb my-prog" -> auto-load my-prog-gdb.scm), plus paths of scripts can be added to the binary (section .debug_gdb_scripts) and they get auto-loaded as well. <dje42>They all go through the same path -> scm_c_primitive_load. <dje42>Good thing I found this now. <mark_weaver>dje42: regarding the slow calls from Scheme to C: are you using the dynamic FFI? <dje42>Haven't got that far. At the moment it's scm_c_define_gsubr. <mark_weaver>well, in Guile 2.0, 'scm_c_define_gsubr' should be faster than the dynamic FFI. <mark_weaver>when we have native compilation, the dynamic FFI could be made as fast (if not faster), but at present it's somewhat slower. <mark_weaver>it's possible that the slowness is part coming from Scheme<->C data conversions, dunno. I'd have to look at the code. <dje42>Have to redo the timings now that I know not to use scm_c_primitive_load. :-) <dje42>The testcase explicitly avoided all data conversions though. <dje42>[got make sure one is measuring what one wants to measure :-)] <dje42>Yeah, Guile is back on par with Python for #calls-into-gdb / sec. Even a little faster :-) <mark_weaver>actually, I expect that Guile 2 beats Python on most fair tests. <nalaginrut>alright, I guessed FFI is slower, now I confirmed it <mark_weaver>IMO, it only makes sense for isolated cases where it can make a real difference in the performance of your program. <mark_weaver>otherwise it falls into the category of "premature optimization" that makes your code more complex and ugly. <nalaginrut>I try to make my http-service-related projects with fast-as-possible philosophy, so I may be sensitive to all the potential accelerate points. <civodul>dje42 .debug_gdb_scripts is just for file names, or could it hold expressions directly? <dje42>civodul: .debug_gdb_scripts only supports file names at the moment, but I built in extensibility ***dje_ is now known as xdje
***foeniks is now known as foeniks2
<add^_>I mean since you use guile and all, you should join us here :-) *photex doesn't use it all *that* much still. <add^_>#guile is really nice when you need help with something scheme related (should be obvious enough though) <wingo>civodul: try objdump -g foo.go :) <wingo>anyway, i don't have line numbers quite working yet *mark_weaver is going to try it on the YeeLoong :)