beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
Guest35 has joined #picolisp
<Guest35> hello! i'm looking at the penti source code and can't figure out the "candidates" system
<Guest35> except that ctrl-space toggles it
avocadoist has quit [Ping timeout: 255 seconds]
<Guest35> nevermind, the solution was reading the instructions
Guest84 has joined #picolisp
Guest35 has quit [Ping timeout: 250 seconds]
fbytez_ has quit [Quit: byte byte]
fbytez has joined #picolisp
Guest84 has quit [Ping timeout: 250 seconds]
beneroth has quit [Read error: Connection reset by peer]
beneroth has joined #picolisp
<tankf33der> aw- ask maintanee
isaneran has joined #picolisp
<aw-> that's why I asked the other day who is the maintaner? I know "Celeste" but.. who is that?
<aw-> there's nobody named Celeste in this chat
<aw-> i didn't find that person in the Mailing List emails either..
<tankf33der> Top lines
<aw-> thanks!
<abu[7]> Wow, big coroutine speedup!
<abu[7]> When experimenting with the hundred thousand coroutines, the long startup was a pain
<abu[7]> Took almost half an hour
<abu[7]> Now it is six seconds! :)
<tankf33der> :)
<abu[7]> I test a little more, then release. I hope tankf33der's test don't crash then :D
<abu[7]> Done
<tankf33der> doing
<abu[7]> :)
<tankf33der> all passed.
<abu[7]> Superb! Thanks!
<abu[7]> Now let's hope that this is the final version of coroutines ;)
<abu[7]> Today's change should not make a difference for up to a few hundred coroutines, but for large numbers it is significantly faster
z4k4ri4_ has quit [Ping timeout: 264 seconds]
z4k4ri4_ has joined #picolisp
seninha has quit [Quit: Leaving]
isaneran has quit [Ping timeout: 268 seconds]
avocadoist has joined #picolisp
avocadoist has quit [Remote host closed the connection]
seninha has joined #picolisp
<beneroth> abu[7], tankf33der awesome!
<beneroth> congratulations to the hefty speed-up, that's really great! what was the cause, all "just" the better memory allocation?
<abu[7]> It was because the coroutine stack frames are searched linearly
<abu[7]> (co 'a ...)
<abu[7]> Causes a full search (100000 stack frames), then allocates a new one
<abu[7]> (yield <val> 'a) I changed already earlier this year. It caches a pointer to the stack frame.
<abu[7]> Now (co 'a ...) also uses this
<abu[7]> New is now a free list of unused stack frames
<abu[7]> So new coroutines start also very fast
<abu[7]> What still needs to be done is clean up after stoppeng. I'll look into it.
<abu[7]> This is not so critical, (co 'a) to stop a coroutine is seldom used
<abu[7]> Most important was in (yield .. 'a), this is called most of the time in a simulation
<abu[7]> i
<abu[7]> i.e. jumping from coroutine to coroutine
<tankf33der> i found co code which crash
<tankf33der> doing bisect in git repo
<abu[7]> oh
<abu[7]> It did not crash in the previous version?
<tankf33der> nope
<tankf33der> something new
<tankf33der> coroutine ring
<tankf33der> this is not in test suite
<tankf33der> yet
<abu[7]> I see
<tankf33der> 3 month ago version crash
<tankf33der> hm
<abu[7]> ok
<tankf33der> 10 month ago version crash
<abu[7]> Can it be a bug in the implementation?
<tankf33der> your turn
<abu[7]> Ah, this is from the old pil64 version. Alioth right?
<abu[7]> hmm, it prints '1'
<tankf33der> pil co.l 12345
<tankf33der> i you like this
<tankf33der> if i change 503 to 5 in two places all works
<tankf33der> let me check again
<tankf33der> i am on latest now
<abu[7]> It does not crash here
<abu[7]> Latest on Termux
<tankf33der> i know
<tankf33der> my stack size
<abu[7]> I have ulimit -s unlimited
<tankf33der> thats why this is not in pil21-tests
<tankf33der> ah
<tankf33der> all ok now
<abu[7]> I think stack is not the problem
<tankf33der> with unlimited all works
<abu[7]> I see
<abu[7]> hmm, yeah, it creates many coroutines
<abu[7]> Perhaps it would also work with (stack 8)
<tankf33der> nope
<abu[7]> For the 100000 test I use (stack 8)
<abu[7]> so each coroutine is smaller
<abu[7]> 64 KiB -> 8 KiB
<tankf33der> why it crash then ?
<abu[7]> it creates 503 coroutines
<abu[7]> hmm, just 32 KiB stack
<abu[7]> with default (stack 64)
<abu[7]> What is your ulimit -s ?
<tankf33der> 8 everywhere
<abu[7]> Thats 8 MiB, right?
<abu[7]> 8192 ?
<tankf33der> [mpech@lambda coredump]$ ulimit -s
<tankf33der> 8192
<tankf33der> [mpech@lambda coredump]$
<tankf33der> right
<abu[7]> ok, but 503 times 64 KiB is 32 MiB
<abu[7]> This explains it
<tankf33der> aaaaa, ok now
<abu[7]> Good we discussed it :)
<abu[7]> In fact, I also don't use unlimited usually
<abu[7]> I have: ulimit -s 1048576 # 1 GiB
<abu[7]> This was also enough for my test with 110000 coroutines and (stack 8), being around 800 MiB
<abu[7]> But in general "unlimited" is safest
<tankf33der> now i find how to run 2000 co's
<tankf33der> on default stack size
<abu[7]> (stack 3) is a little dangerous perhaps :)
<tankf33der> works
<abu[7]> Yeah
<abu[7]> You can see with (stack) how much is not used
<abu[7]> E.g. (ring81 . 2) means 2 are unused
<abu[7]> so (stack 3) is indeed safe here :)
<abu[7]> Setting a breakpoint probably quickly gives a stack overflow, because not enough space is left in the frame
<abu[7]> ! ring1 -- Stack overflow
<abu[7]> ?
<abu[7]> (! for (I (yield) (gt0 ...
<tankf33der> i run 1M co ring in unlimited stack
<tankf33der> very fast
<tankf33der> i want add (gc) somewhere to stress it
<abu[7]> Wow!
<abu[7]> (gc) also traverses the stack frames
<abu[7]> (bench (gc)) would be interesting
<tankf33der> 1M co is 3.4GB of ram
<abu[7]> yep
<abu[7]> I tried with 200000
<tankf33der> bench returns 0.368 sec
<abu[7]> cool, so not so bad
<abu[7]> Depends on the use case
<abu[7]> In a GUI this may be noticeable
<abu[7]> But (gc) cannot be sped up here, it must collect all frames
<abu[7]> In such use cases, a (gc <n>) is useful
<abu[7]> Avoids a gc run in critical phases
<tankf33der> i wanr to run to stress test
<abu[7]> good
<abu[7]> very interesting
<tankf33der> what is better place to insert?
<abu[7]> Insert (gc)?
<abu[7]> Inserting in the first 'for' will take too long perhaps
<tankf33der> i want to run in 10% of calls
<abu[7]> (at (0 . 10) (gc))
<tankf33der> here ok ?
<abu[7]> Perhaps better before the last line "N ) ) )"
<tankf33der> ok
<abu[7]> because then there are more data to cullecbn in each frame
<abu[7]> *collect
<tankf33der> Doing
<abu[7]> or, what if you call it in "(for (I (yield)"?
<abu[7]> At the moment this 'for' has no 'prg' body
<abu[7]> Could be (at ...)
<abu[7]> Then gc gets called much more often though
<tankf33der> this version hang
<tankf33der> maybe my wrong insert
<abu[7]> No, it looks good
<abu[7]> Probably just takes very long
<abu[7]> What if you interrupt with ^C ?
<tankf33der> just exits
<abu[7]> You must start from the REPL, not a script
<abu[7]> Remove the last 6 lines
<abu[7]> and start with (load "x.l")
<tankf33der> ok
<abu[7]> Then it stops in a breakpoint
<abu[7]> Not really necessary to remove the last lines
<abu[7]> But if started from a ':' prompt the signal handler for ^C ij set up
<abu[7]> *is
<abu[7]> afp
<tankf33der> afk
<tankf33der> all passed. enough.
theruran has joined #picolisp
inara has quit [Quit: Leaving]
inara has joined #picolisp