lisp123 has quit [Remote host closed the connection]
Bike has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #commonlisp
<Bike>
phantomics: it will have to be a constant, which is why i suggested the compile thing for a case like libdivide's, where it's not a compile time constant but you're using it for the same division a lot where you want to amortize
<Bike>
converting to shifts and multiplications and all is probably slower than using hardware division for cases where the dividend varies each time, of course
<phantomics>
I see, the savings may not be there in that case
<Bike>
"probably" shoudl be definitely actually, because generating new machine instructions and running them is absolutely going to be slower than one ALU operation
<phantomics>
I'm dividing by dimensional factors, so I may consistently have a need for numbers 0-10 but the factors for high dimensions could be anything
<phantomics>
I guess I could make a set of functions for low numbers and reference them from a LUT but I couldn't create a function in memory for just any number
<Bike>
you should also profile to see if this is actually a problem, of course. i just did a quick test to compare truncate with a constant dividend versus variable where in either case they're declared fixnum and there's optimize speed. with a million iterations the constant version is 3 ms or ~22% faster, which given that it only took 16 ms in the variable version isn't too amazing
<Bike>
with a hundred milion iterations it's ~48%. that's the kind of size you're gonna need for this to matter at all
ttree has joined #commonlisp
<Bike>
on the bright side, compiling a truncator only takes like 3 ms
<phantomics>
My use cases could get pretty big, I'm converting row-major indices between arrays
<phantomics>
So that means that I have to do a number of integer divisions equal to the rank of the array to convert its row-major index to integer coordinates, and then usually some kind of multiplication of each of those
<phantomics>
So for large arrays with many steps of index conversion, millions of iterations are not unlikely
<Bike>
oh, and in my example there's function call overhead in both cases, but in reality you wouldn't need it for the variable truncate
<phantomics>
The benefit of doing row-major index conversion for array processing is that it allows the transformations to be multithreaded with nothing shared, so that can give a significant speedup
surabax has quit [Ping timeout: 255 seconds]
<phantomics>
Appreciate the examples Bike, I'll try running something like that and see how it profiles
<Bike>
make sure your examples are actually compiling down to shifts by using disassemble
<Bike>
oh, and also i think sbcl can use range information about the dividend in its optimization, so if you can provide that information for your indices it could help
<Bike>
(assuming 0 is your minimum, given these are array indices)
<phantomics>
Right, the CPU will make a difference here, M1s apparently have very fast integer division, so I may want to try with Stas's SBCL port
<phantomics>
But the M1 has few cores, so the threading advantage will be less
<Bike>
you could even try to do something fancy where your thing tests which implementation is faster on the actual machine and then uses that
<Bike>
can get pretty dicey tho
<phantomics>
That's something I've been considering, an autotuning system, it would be helpful to determine the cutoff point for when to add a new thread to a given transformation on an array of a given size
<Bike>
"this" being the autotuning. i have no idea what the actual math it's doing is
<phantomics>
So the optimization data is stored in that *quantize-optimization* variable
<Bike>
yeah, which is just a boolean. then the quantize-block macro decides what to expand into based on that variable.
irc_user has quit [Quit: Connection closed for inactivity]
lisp123 has joined #commonlisp
<phantomics>
Pretty simple, I was envisioning a big table of values for each operation. Though with my loop-fusion system such a technique may only matter for single-stage transformations of big arrays
lisp123 has quit [Ping timeout: 255 seconds]
orestarod has quit [Ping timeout: 268 seconds]
<lagash>
I'm looking into coding some sort of parsing / generating library for LDraw (standard file format for LEGO designs) and I'm not entirely sure where to start. I've done stuff with PEGs and other parsing grammars before, but in other languages. What would be something I should look into for bidirectional LDraw<->Sexp?
karlosz_ has joined #commonlisp
karlosz has quit [Ping timeout: 255 seconds]
karlosz_ is now known as karlosz
<phantomics>
lagash: You could take a look at https://github.com/eugeneia/maxpc for building parsers, be advised it's AGPL-licensed though
<lagash>
phantomics: so a parser combinator library?
<lagash>
but is it bidirectional?
<phantomics>
Afaik you would need to write a separate module to write back to LDraw
<lagash>
Is there more sophisticated libraries that have more of that functionality?
<lagash>
I'm not too enthused about it not implementing packrat parsing as well as being AGPL'd
<phantomics>
As far as writing back to LDraw it looks like any option would involve significant work, I see the format is unique and not based on XML or anything like that
<phantomics>
I see there's https://github.com/JoshTheDerf/LDRParser that can convert LSD -to- JSON, but converting from JSON to LDR is still a todo, if it was implemented you could generate JSON from CL to give to it
<lagash>
Yeah I was thinking esrap
<lagash>
And I was meaning more, that the parser and the writer were integrated together, versus having two libraries, one for parsing, the other writing / generating
Bike has quit [Quit: Lost terminal]
atgreen has quit [Ping timeout: 246 seconds]
atgreen has joined #commonlisp
lisp123 has joined #commonlisp
irc_user has joined #commonlisp
lisp123 has quit [Ping timeout: 268 seconds]
<phantomics>
That would be a good design choice for your library, making it integrated like that, but I don't know of any tool that makes that particularly easy, I expect you'd need to built it from scratch with a bunch of (format) calls
akoana has quit [Quit: leaving]
thuna` has quit [Ping timeout: 246 seconds]
atgreen has quit [Ping timeout: 268 seconds]
atgreen has joined #commonlisp
wilfred has quit [Quit: Connection closed for inactivity]
tyson2 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
atgreen has quit [Ping timeout: 272 seconds]
contrapunctus has joined #commonlisp
yauhsien has joined #commonlisp
yauhsien has quit [Read error: Connection reset by peer]
yauhsien has joined #commonlisp
yauhsien has quit [Ping timeout: 246 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
hineios8 has joined #commonlisp
hineios has quit [Ping timeout: 268 seconds]
hineios8 is now known as hineios
causal has quit [Quit: WeeChat 3.5]
pranavats has joined #commonlisp
yauhsien has joined #commonlisp
yauhsien has quit [Ping timeout: 268 seconds]
azimut has joined #commonlisp
aartaka has quit [Ping timeout: 255 seconds]
mixotricha has quit [Quit: Ping timeout (120 seconds)]
leeb has quit [Ping timeout: 246 seconds]
leeb has joined #commonlisp
mon_aaraj has quit [Ping timeout: 268 seconds]
mon_aaraj has joined #commonlisp
akoana has joined #commonlisp
notzmv has quit [Ping timeout: 248 seconds]
dBc has joined #commonlisp
yauhsien has joined #commonlisp
irc_user has quit [Quit: Connection closed for inactivity]
asarch has joined #commonlisp
yauhsien has quit [Ping timeout: 255 seconds]
lisp123 has quit [Remote host closed the connection]
dBc has quit [Quit: Quit]
saura has joined #commonlisp
saura has quit [Ping timeout: 268 seconds]
<contrapunctus>
Who here was working on reproducing the spec in a modern format from some permissively-licensed source?
saura has joined #commonlisp
<contrapunctus>
I wonder if it was ph oe
<pranavats>
It was. With Ultralisp.
<contrapunctus>
pranavats: ah, UltraSpec
<pranavats>
Ah, yes
<contrapunctus>
thanks, looking into it
akoana has quit [Quit: leaving]
yauhsien has joined #commonlisp
saura has quit [Ping timeout: 255 seconds]
<beach>
contrapunctus: scymtym worked on a parser for the dpANS TeX source, and he is able to produce nice HTML and also a format for a CLIM-based browswer.
<beach>
*browser
<contrapunctus>
oh, good to hear
<beach>
I think phoe declared that the UltraSpec way was not feasible.
saura has joined #commonlisp
saura has quit [Ping timeout: 255 seconds]
yauhsien has quit [Ping timeout: 246 seconds]
pve has joined #commonlisp
lisp123 has joined #commonlisp
asarch has quit [Quit: Leaving]
notzmv has joined #commonlisp
surabax has joined #commonlisp
<jmes>
I have an unorthodox directory where I need CFFI to look for .so files, how do I tell CL to look there?
MajorBiscuit has joined #commonlisp
yauhsien has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
<jmes>
I found out cffi:load-foreign-library has a :search-path keyword for this. But it's called from elsewhere, so never mind me.
yauhsien has quit [Ping timeout: 268 seconds]
rotateq has quit [Ping timeout: 255 seconds]
makomo has joined #commonlisp
MajorBiscuit has quit [Ping timeout: 272 seconds]
lisp123 has joined #commonlisp
kpoeck has joined #commonlisp
kpoeck has quit [Client Quit]
kpoeck has joined #commonlisp
mon_aaraj has quit [Ping timeout: 246 seconds]
lisp123 has quit [Remote host closed the connection]
lisp123 has quit [Remote host closed the connection]
hisacro has quit [Remote host closed the connection]
<contrapunctus>
I'm trying to install cl-inotify, and I get this condition - https://paste.rs/Jkh I've tried installing libinotifytools0-dev, and restarting the Lisp process.
lisp123 has joined #commonlisp
hisacro has joined #commonlisp
mon_aaraj has quit [Ping timeout: 246 seconds]
lisp123 has quit [Read error: Connection reset by peer]
lisp123 has joined #commonlisp
rodicm has joined #commonlisp
tyson2 has joined #commonlisp
atgreen has joined #commonlisp
Oddity has quit [Ping timeout: 255 seconds]
McParen has joined #commonlisp
pranavats has left #commonlisp [#commonlisp]
pranavats has joined #commonlisp
kpoeck has joined #commonlisp
<jackdaniel>
contrapunctus: do you have c compiler?
<jackdaniel>
try gcc -v
<jackdaniel>
groveller depends on c toolchain present on the system