IRC channel logs

2020-06-26.log

back to list of logs

***sputny1 is now known as sputny
<mwette>mrkotfw: I ran into a dynamic-link issue like that (on Fedora?). The problem is the way libtool works. I think it is fixed in 3.0.2. Ref is https://bugs.gnu.org/21076.
<mwette>sneek: later tell mrkotfw to check https://bugs.gnu.org/21076
<sneek>Okay.
***jonsger1 is now known as jonsger
***wxie1 is now known as wxie
***catonano_ is now known as catonano
***wxie1 is now known as wxie
***wxie1 is now known as wxie
***wxie1 is now known as wxie
<daviid>I pushed a series of patches to g-golf, related to a 'protect' syntax name to be used as generic function names 'mechanism', with three user (re)definable/customizable variables to alter the defaults with that respect. I also documented this as well as I could... those interested, please pull, make, read the doc and try ...
<daviid>leoprikler: I have taken your suggestion into consideration, so you may prefix those (syntax names to be protected) using '@ if you wish, and set the postfix to #f ... and for those who wish an even more sophisticated and 'personal' way of protecting syntax names, they may define a renamer
<leoprikler>Hmm, could the Guix recipe be outdated w.r.t. packages?
<leoprikler>I'm trying to build inside "guix environment g-golf", but that results in: dynamic-link: file: "libgirepository-1.0", message: "file not found"
<roelj>Can I get the return value of a command when run using ‘open-input-pipe’?
<roelj>Ah nevermind, that's done using close-pipe.
<leoprikler>daviid`: syntax-name->method-name is missing the case for begin != #f, but suffix = #f
<leoprikler>Either require both to be symbols always or do (or [prefix|postfix] '#{}#)
<daviid>leoprikler: tx, I pushed a fix
<roelj>I'm running a Guile program in a container (made with Guix), and it cannot seem to resolve addresses, backtracing with: (getaddrinfo "some.address" "https" 0 #<undefined> #<u?> ?).
<roelj>What does Guile need to resolve addresses?
<leoprikler>I'm not sure whether Guix containers are allowed to use networking
<roelj>leoprikler: Well, curl works fine :)
<leoprikler>So, you do both -C -N and getaddrinfo fails?
<roelj>Perhaps I omitted the most important error message poart: In procedure getaddrinfo: Servname not supported for ai_socktype
<roelj>leoprikler: I make a "pack" with guix pack, and imported that in Docker, and then run it in Docker.. :/
<leoprikler>okay, (getaddrinfo "gnu.org" "https") works from environment -C -N
<roelj>I don't know how this works, but should "https" be translated to a port number?
<leoprikler>well, it expects a string, so no
<roelj>hehe
<leoprikler>name service hint_flags hint_family hint_socktype hint_protocol
<leoprikler>not sure how docker handles this tho
<leoprikler>I'm pretty certain you can get getaddrinfo to work as intended in `guix pack` tarballs
<roelj>Hm, so I reduced it to the following: scheme@(guile-user)> (http-get "http://gnu.org") => In procedure getaddrinfo: Servname not supported for ai_socktype
<roelj>And the same error for (getaddrinfo "gnu.org" "https")
<leoprikler>Well, I get gnutls-not-available :)
<roelj>haha :)
<leoprikler>and some certificate error if I add it
<leoprikler>Have you tried using guix pack tarballs?
<leoprikler>I believe, this might be a docker-specific issue
<roelj>Ha! https://stackoverflow.com/questions/56430294/bash-script-that-uses-whois-command-gets-servname-not-supported-error-on-do this solution adds "ntp".
<roelj>Let's see if that works
<roelj>leoprikler: It being a docker-specific issue was a very helpful suggestion :)
<roelj>Just running "ntpd" doesn't have any effect.
<roelj>strace it is
<weinholt>roelj, symbolic service names like "https" are defined in /etc/services, you might be missing that file
<roelj>weinholt: Yeah, I found that in the strace output as well, so I'm trying by including the "net-base" package in the container.
<roelj>That was it -- missing /etc/services. Thanks weinholt and leoprikler!
<mwette>o/
<ArneBab>ecraven just updated the r7rs benchmarks with data for Guile 3.0.4! https://ecraven.github.io/r7rs-benchmarks/
<ArneBab>Guile 3.0.4 is seriously closing in on racket, and in the gcbench even on gerbil und chez!
<ArneBab>wingo: ^ I thought the results might interest you :-)
<civodul>nice!
<ArneBab>I also did a check of the standard deviation of the data (using 4 runs provided by ecraven), and the ranking looks mostly robust. From what I saw I would expect the rank to change by at most 1 between different runs.
<ArneBab>In many tests Guile 3 already bridged the gap between the slower and the seriously fast schemes and is typically less than factor 2 slower than racket — and in some cases faster.
<ArneBab>I also just compared the Guile results to the fastest implementation for each test: using the raw CSV data, the geometric mean slowdown compared to the respective fastest implementation went down from 16x slower to 6x slower.
<ArneBab>well, 7x
<ArneBab>(rounded correctly)
<civodul>neat
<civodul>did you try comparing 2.2 and 3.0?
<civodul>i mean the figures are there, just not easy to look at
<ArneBab>yes
<ArneBab>3.0 is faster on every test than 2.2
<ArneBab>and the geometric mean shows that 3.0 is twice as fast as 2.2 when you compare against the limits that can be reached on any test.
<ArneBab>the slowdown above (7x): For racket it’s 5x and for chez it’s 2.6x.
<ArneBab>So Guile is now only 40% slower than Racket (factor 1.4); getting closer to the goal of catching up on racket.
<ArneBab>Chez shows how much is possible …
<dsmith-work>Happy Friday, Guilers!!
<civodul>yay, Happy Friday!
<ArneBab>Happy Friday dsmith-work!
<civodul>ArneBab: yeah, interesting
<civodul>i have the uneducated intuition that there are low-hanging fruits in our run-time
<civodul>for "real" applications
<civodul>we should investigate the benchmarks where Guile doesn't perform so well to see what the reason is
<civodul>code quality or something else
<ArneBab>that sounds like a good idea, yes.
<ArneBab>There are two main pain points: ctak (doesn’t actually complete on time) and equal (fails on circular datastructures)
<ArneBab>the biggest slowdown is on fibc (103), ack (30), and string(29)
***dddddd__ is now known as dddddd
<ArneBab>then there are some between 13 and 6, worst first: cat wc browse tail deriv cpstak mbrot graph read1 sumfp puzzsle pnpoly
<ArneBab>(I ignore two outliers where the fastest scheme is ridiculously fast (0.1 or 0.)
<ArneBab>)
<ArneBab>sources of the wirst three:
<ArneBab> https://github.com/ecraven/r7rs-benchmarks/blob/master/src/fibc.scm
<ArneBab> https://github.com/ecraven/r7rs-benchmarks/blob/master/src/ack.scm
<ArneBab> https://github.com/ecraven/r7rs-benchmarks/blob/master/src/string.scm
<ArneBab>s/wirst/worst/
<civodul>fibc is call/cc, doesn't matter IMO
<civodul>ack shouldn't be slow
<ArneBab>I now checked the data on the page for ack again: it’s because cyclone is crazy fast on this. Guile 3 is as fast as racket and factor 2 slower than chez.
<ArneBab>so, ack is also an outlier
<ArneBab>thank you for checking!
<ArneBab>so from the worst three, only string is a serious worry.
<ArneBab>it’s string-length, string-append and substring.
<ArneBab>Just the part for which avoiding it made string-replace-substring much faster.
<ArneBab>so this is a real pain-point
<ArneBab>looks like it’s in libguile/strings.c
<dsmith-work>There was some recent string improvements by moving C to Schme (string-for-each I think)
<ArneBab>… hm, no, the fast string-replace-substring still contains substring
<dsmith-work>I wonder if there are other opportunities there.
<ArneBab>running this with ,profile, I see 94.62% of the runtime in %after-gc-thunk
<ArneBab>5% are string-append
<ArneBab>my most plausible guess is that it’s string-append
<ArneBab>depending on memory pressure, time shifts between %after-gc-hunk and string-append
<ArneBab>I tried switching to an implementation of string-append in pure scheme, but that’s much slower. Maybe one of you knows of an efficient way to do this. I used plain string->list and then (append ...) on char lists.
<civodul>there's something fishy going on with %after-gc-hunk
<ArneBab>did you find something concrete?
<ArneBab>the code does lots of appending of short strings
<civodul>not really, i posted something to guile-user, but no solid explanation
<dsmith-work>Heh. after_gc_async_thunk has a Fun comment
<dsmith-work>(calls scm_c_hook_run AND scm_c_run_hook)
<civodul>yeah :-)
<ArneBab>do you know why?
<civodul>why what?
<civodul>for string-append in Scheme, you should mimick what the C code does, accessing the stringbufs directly
<civodul>(system base types) has code for that, though it's not meant to be used in this way
<ArneBab>why it calls both
<civodul>one is for hooks written in C, the other is a C function to call hooks
<civodul>so there are two naming conventions very similar
<ArneBab>ah, makes sense, but looks pretty strange :-)
<civodul>yeah
<civodul>besides, string-append benchmarks are mostly measuring GC efficiency
<civodul>so it could be that we lose just because libgc doesn't do as well as the others
<civodul>however, Bigloo also uses libgc, so it's a good point of comparison
<civodul>i'm not sure whether Racket still does
<dsmith-work>That C code for string-append doesn't look that bad. Total up the lengths, alloc the new string, memcopy the pieces (or loop for wide chars).
<civodul>my impression is that calling subrs is quite expensive
<civodul>because we have to leave and then reenter the VM
<civodul>though i think wingo was skeptical about this hypothesis
<civodul> https://lists.gnu.org/archive/html/guile-user/2020-06/msg00038.html
<dsmith-work>So it's not that string-append is slow, it's calling it in a Scheme loop that'
<dsmith-work>s slow?
<civodul>yes
<civodul>which is "expected" in a way, because there's little more than overhead when you do that
<civodul>+ gc
<civodul>so dunno
<ArneBab>why does the gc take so much time? in the gcbench Guile does really well
<ArneBab>So I don’t understand why it’s so expensive here
<dsmith-work>Benchmarks. Who can say?
<ArneBab>I also got problems with using string-append for the string-replace-substring proc
<ArneBab>IIRC removing that gave quite some speedbump