libera/#lisp - IRC Chatlog
Search
12:07:34
ak-coram
Managed to work around that ECL threading issue from the weekend: https://github.com/ak-coram/cl-duckdb/pull/10
12:08:12
ak-coram
but seem to have stumbled on one of my benchmarks doing a lot of consing on ECL compared to SBCL
12:14:01
ak-coram
here's the code, append-row is just a loop on params with one large dispatch to a bunch of C functions via ecase: https://termbin.com/9mui
12:25:01
ak-coram
also weird, I seem to be getting a major difference between running roswell vs ECL that comes with my distro (it's the same ECL-version)
13:43:26
jackdaniel
it would be more grokkable if you had narrowed the reproducible test case without relying on 3rd party libraries
13:48:30
ak-coram
I'm not sure what library is causing this, but using ultralisp seems to kill most of the allocations (down to about ~250MB) with ECL. Still way more compared to SBCL & CCL
13:56:28
pkal
Bung: perhaps they are thinking of something like this: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
14:36:07
jackdaniel
I think that some people who invested a little time in lisp and got discouraged tend to say bad things about the language; but that's probably applicable to all other languages
15:08:54
White_Flame
Bunggg: lisp used to be a slow, high memory usage language on older (eg pre-90s) machines, and even though memories are huge now and compilers have gotten smart enough to run lisp fast, those impressions remain with some.
15:09:31
White_Flame
and people aren't used to s-expression nesting of forms, so they stick to languages wiht a more familiar syntax, even though sexprs are more regular and are easy to programmatically generate & transform
15:10:42
White_Flame
there's the few most popular languages in industry, then people say that nobody uses the other languages
15:52:05
ak-coram
jackdaniel: I managed to greatly reduce the scope of the issue, it's now just repeatedly calling a single C function via cffi: https://termbin.com/tqwg
16:23:45
ak-coram
yeah, it's much better after updating everything to the latest ultralisp: "only" 111MB consed
16:26:51
ak-coram
I can shave some more off if I pretend the function has a :void return type (71MB consed)
16:55:55
ak-coram
I see, what's the best practice for setting this up? are users supposed do it and I shouldn't worry about it as a library maintainer?
16:56:16
jackdaniel
it is not the default universally, because ecl may be built w/o c compiler, and specifically because cpilers complain on casting pointers to void* in declarations (ecl does that - this is fixable)
17:00:34
jackdaniel
i.e ecl may include stdlib.h and it may have a declaration "extern foo * bar()", ecl will declare "extern void * bar" - on abi level it is 100% fine
17:01:53
ak-coram
I'm still a bit stumped: I can't really tell how people will use my library either, but it would be nice to have this set automatically if a C compiler is available
17:01:55
jackdaniel
we could teach cffi/ecl to handle these declarations conformingly (from c perspective) but that's some extra woerk I don't have time for currently
17:03:07
ak-coram
I mean it took me long enough to find out about this, users probably won't look into this stuff and just think ECL is slow
17:07:02
ak-coram
no worries, I'll definitely add it to my benchmark run at least and refer to it in the README
17:10:50
ak-coram
so I imagine this needs to be set after cffi is loaded, but before my code is compiled
18:10:15
ak-coram
hmm, how do I make sure CFFI can include the header files of the library I'm calling when I set *cffi-ecl-method* to :c/c++? I imagine it needs them.