IRC channel logs


back to list of logs

***Server sets mode: +nt
***catonano_ is now known as catonano
***apteryx_ is now known as apteryx
<lloda> why does bytevector-copy! take start & len args but bytevector-fill! doesn't :-(
<lloda>are these standard or is it something we can fix?
<lloda>that's too bad
<lloda>perhaps it can be extended
<lloda>(bytevector-fill! bytevector fill start k)
<wingo>lloda: it can certainly be extended. fwiw i have had "subbytevectors" on my list for a long time also
<wingo>we have all the machinery, just need to add the constructor
<lloda>I only think it's necessary as a low level mechanism
<lloda>because it ends in a memset, etc
<lloda>I think if you need 'view' objects, arrays is what should be used
<lloda>they just need to be better
<lloda>also bytevector-/vector- have very different interfaces, even though vectors and bytevectors are more or less the same thing, even the implementation
<lloda>I don't know if some merging could be done there
<lloda>so imo bytevector/vector-copy/fill should offer start/length and even stride, like s/d/c/zcopy in BLAS, but I don't like the idea of a subbytevector object tbh
<lloda>there are already too many of these things :-/
<lloda>just my opinion ofc
<wingo>well my issue is that sometimes you have a big piece of memory and you want to give it to a subroutine
<wingo>right now you have to pass the whole thing, or use arrays which are somewhat less efficient than straight-up bytevectors
<wingo>if i could pass a subbytevector then i get bounds-checking in the subroutine
<wingo>s/give it to/give a piece of it to/
<lloda>I do see the use case
<lloda>you think it's too much of a burden to pass start/len explicitly in those cases?
<lloda>ideally arrays wouldn't be less efficient
<lloda>I'm concerned that introducing this middle layer will make arrays even less efficient
<lloda>because of the redundant ranges
<lloda>also would all the operations that now take bytevectors, be able to handle subbytevectors?
<lloda>how does that work
<wingo>yes i think passing start/len is too much of a burden because it's not reliable.
<wingo>fwiw subbytevectors don't add any conceptual complexity
<wingo>they are just bytevectors.
<wingo>the compiler already assumes that any bytevector can alias any other bytevector
<wingo>and bytevectors already have a "parent" field if their memory is "owned" by some other object
<wingo>so a subbytevector is just a bytevector that has another as a parent, and which aliases a part of its memory
<wingo>it's not a new type of object
<lloda>ok that sounds a lot better than what I thought
<lloda>handling aliasing will be up to the user?
<lloda>like it is for arrays now I guess
<wingo>you mean managing the fact that one bytevector can mutate another? yes that's right
<wingo>note that it is possible to flag some bytevectors as immutable but given that they can alias mutable memory it doesn't give you much
<lloda>shouldn't the flag be only on the memory and not on the bytevector then
<lloda>'memory' as w/e object that is
<lloda>also (sub)bytevectors will still be contiguous memory I assume
<weinholt>if you have shared subbytevectors then -ref/-set! can't assume alignment
<wingo>weinholt: that's already the case fwiw in guile, because you can make a bytevector out of a foreign pointer
<weinholt>ah. carry on :)
<wingo>i think we will just emit unaligned load/set ops and pretend it's the cpu's job :)
<wingo>lloda: memory isn't an object; it has no flags that we can easily access
<wingo>sometimes you can rely on os-level protections but guile doesn't do that right now as you'd need to catch sigsegv in weird places
<lloda>ok I was thinking you'd get some kind of metadata on the allocated pieces or something
<wingo>some of the memory is static in the .go files
<wingo>or from const static C memory, etc
<lloda>I see. Not a big problem I don't think
<lloda>yes to contiguous memory?
<wingo>it's still a bytevector
<lloda>that's fine I think
<lloda>bytevector-copy! is massively faster than some of the other copy!s in Guile so I think those should be rebased as far as possible
<lloda>it's a special case, but a very common one
<wingo>it's faster than vector-copy! ?
<lloda>they don't work on the same types so I dunno
<lloda>I was thinking about array-copy! which is super slow
<lloda>I know vector-copy in core uses memmove or memcpy same as the unrollable case of array-copy! #t
<lloda>but array-copy! has to handle all the type conversions so it just does the dumb loop when the types are srfi4
<lloda>just benched these
<lloda>bytevector-copy! on s64 x 50000 and vector-copy! x 50000 are about the same
<lloda>array-copy! is about the same with vectors (special case of #t -> #t copy) but it's horrible with 's64 as expected
<lloda>so the question is, if you have subbytevectors, will you also have subvectors, and will it be the same re: not a new type, etc.
<wingo>lloda: i don't think we will have subvectors.
<wingo>reason being, vectors deal in gc-managed memory and don't have this behavior of needing to be able to adopt memory from elsewhere
<wingo>i can see a consistency argument but the mechanics are too different
<zig>hello #guile!
<roelj>hello zig
<wingo>civodul: fixed that closed-stdin bug and cutting a 2.9.7
<civodul>wingo: neat!
*civodul can't keep up!
<wingo>lol :)
<wingo>i probably won't get to do any guile things over the next 3 weeks fwiw
<civodul>ah ha! so that's when i should start playing with it :-)
<civodul>i'll also be partly offline in fact
<wingo>oh yay distcheck worked the first time :)
<zig>roelj: As you might have figured, I cycled back to my rdf work. I read the documentation of sparqling-genomics. It is interesting. Like you told me previously, I need to support sparql 1.1 to be able to interop with your project.
*wingo finished release, just waiting on mailman to post the release announcement
<roelj>zig: Well, if your store can do RDF then I want to look at it already. Maybe I can help implementing SPARQL 1.1 stuff!
<zig>I am not sure how to tell the thing I am thinking about.
<spk121>looks like I didn't make the cut for minlang room in FOSDEM, but, the schedule looks fun
<jcowan>roelj: Yes, and it generalized from triples to arbitrary tuples, so you can handle common RDF extensions like provenance.
<roelj>jcowan: That's interesting
***apteryx_ is now known as apteryx
***ng0_ is now known as ng0
<civodul>unscientific benchmark: "time guix build guile3.0-minikanren --check --no-grafts -v1"
<civodul>guile2.0-minikanren -> 8s
<civodul>guile-minikanren -> 27s
<civodul>guile3.0-minikanren -> 28s
<civodul>(with 2.9.6)
<zig>on my side, query times were good with babelia. I did not compare with guile 2.2 tho. I might have time to do that during the holydays maybe.
<jcowan>I'm testing Guile 2.9.7 on Cygwin now
<zig>I also benchmark nomunofu against blazegraph (jvm)
<zig>but later.
<jcowan>I had to build libunistring, which Cygwin doesn't package, and ./configure is dog-slow on Cygwin; the Guile one is especially large and it's still running.
<jcowan>Pig fucker crashed with "libunistring not compiled with iconv support". I do wish Guile would check dependencies *first*.
<davexunit>guile checks tons of stuff during configure. sounds like a simple omission.
<jcowan>I'm assuming that libunistring couldn't find Cygwin's iconv, so I'm rebuilding it
<jcowan>But the ordering consideration has been the case since at least 2.0, when I spent most of a day configuring, aborting, installing a dependency, rinse repeat.
<jcowan>At least now I know what the dependencies are up front, and hopefully it won't have to recompile *everything*, as Guile 2.0 did.
<jcowan>Okay, it's libiconv-devel that I needed to install (Cygwin uses Fedora package names, unsurprisingly)
<jcowan>and also libffi-devel, configuring for the 3rd time
<daviid>wingo: congrat for the release! i hope the next one includes lloda's wip-truncate-exception 2 patches - if you're going to be a bit 'away from guile' for 3 weeks, please don't forget to look at it ... tx!