<freeemint>
how can i compare cell usage by function?
<freeemint>
as in which uses more
<Regenaxer>
(size fun) gives the number of cells
<Regenaxer>
of the function, not of the output
<freeemint>
the number cells used during the execution and for the result
<Regenaxer>
What you need for that is the number of 'cons' calls
<freeemint>
(or conc?)
<Regenaxer>
With "used" you mean "taken from the avail list"?
<freeemint>
yes
<Regenaxer>
no, conc uses no new cell
<freeemint>
ok
<Regenaxer>
cons, list, mapcar etc
<freeemint>
free cell count = lenght of avail list
<freeemint>
is there some way to meassure?
<Regenaxer>
yes, but it grows as needed
<Regenaxer>
no way to measure on the Lisp level
<Regenaxer>
Why do you want to measure?
<Regenaxer>
You can count the cons calls
<Regenaxer>
list, link mostly
<freeemint>
hpw can count the cons calls?
<Regenaxer>
mapcar produces exactly the number of cells of the arg list
<Regenaxer>
By looking at the code
<freeemint>
manually?
<Regenaxer>
With logic thinking
<Regenaxer>
mapcar produces exactly the number of cells of the arg list
<freeemint>
that is the problem i want to verify my counting
<freeemint>
yes
<Regenaxer>
cons produces 1
<Regenaxer>
Hmm, you can 'size' the result perhaps
<Regenaxer>
But no, some might be garbage
<Regenaxer>
There is no trivial way
<Regenaxer>
Why are you concerned about that?
<freeemint>
there is one trivial way. but i can not do it,
<Regenaxer>
Patch the cons functions?
<freeemint>
count the lenght of the avail list ... it is not time critical
<Regenaxer>
Not trivial
grp has joined #picolisp
<Regenaxer>
No, the avail list makes no sense
<freeemint>
pathing count would be more elegant
<Regenaxer>
it grows, and many cells used might be garbage collected in between
<freeemint>
*cons
<Regenaxer>
I think this measuring is useless
<freeemint>
ok give me away to stop gc
<Regenaxer>
No need to worry
<freeemint>
and i preallocate enough before hand
<freeemint>
*or i prealloc
<Regenaxer>
Why are you concerned about that?
<Regenaxer>
Why are you concerned about that?
<Regenaxer>
Why are you concerned about that?
<Regenaxer>
Premature optimization?
<freeemint>
1. because i want to verify my counting
<freeemint>
2. because it might make for a good hotspotting tool
<freeemint>
3. because the programm i write (all matrics of nxn filled by symbols from a list) puts lost of stress on the gc for sure and i want to minimize it as an exercise
<freeemint>
4. premature optimization and picolisp beiing my vreative outlet
<freeemint>
does that help
<Regenaxer>
OK. You can always write a program with *no* consing (except for I/O) when you pre-allocate all structures and operate on them destructively
<Regenaxer>
(map set ...
<freeemint>
if i preallocate the structure the universe might die
<Regenaxer>
yeah
<freeemint>
I wantd to turn it in to a job once i got it running
<Regenaxer>
What kind of job?
<freeemint>
'job
<freeemint>
:P
<Regenaxer>
in the sense of project, or 'job' function?
<Regenaxer>
ok
<freeemint>
job function
<freeemint>
sorr to disappoint
<freeemint>
(i am not use to the new keyboard yet)
<Regenaxer>
No problem, I have enough (or too many) jobs currently
<Regenaxer>
Back to the above: To count the 'cons' operations, you can modify all whe functions in src64/gc.l
<freeemint>
Have you thought about getting paid a little to extend picolisp as people wish? (no arrays)
<Regenaxer>
all "cons" funs
<Regenaxer>
haha, good
<Regenaxer>
(no arrays)
<Regenaxer>
No, I do it for free
<Regenaxer>
But only if it is a good idea
<freeemint>
Of course
<Regenaxer>
There are many functions of the form 'consE_C'
<Regenaxer>
Only here consing is done
<Regenaxer>
only in src64/gc.l
<freeemint>
But that way i might stop idle musing when a price is attahed to every hour of wokr a people settle for the minimum necessary change to pil
<Regenaxer>
Even a small change will introduce a lot of trouble in the long range
<Regenaxer>
must be maintained
<Regenaxer>
splits the versions
<freeemint>
*But that way i might stop request of you when a price is attachd to every hour of your work and people in general settle for the minimum necessary change
<Regenaxer>
documented, discussed
<freeemint>
no version split one rolling release
<freeemint>
i would prefer
<Regenaxer>
yes
<Regenaxer>
Best is if you hack it according to your needs
<freeemint>
I do not like that idea. It is very suboptimal from a global perspective and might fracture the community
<freeemint>
Just imagine how many functions will be reinvented because the existing ones are not properly understood. And -icolisp source code will become incompatible when some patches are only implemented in one interpreter
<freeemint>
that is lovecraftian cosmic horror to my ears
karswell_ has joined #picolisp
<Regenaxer>
So the best is to write such extensions outside the core system
<Regenaxer>
eg a shared object file
<Regenaxer>
You could really try
<Regenaxer>
For example, a function counting all *used* cells would be simple
<Regenaxer>
'heap' does something similar
<Regenaxer>
But I think the returned count is not useful
<Regenaxer>
The used cells change all the time rather unpredictably
<freeemint>
Well normally you say implement it and see if it is usefull (fast enough or so) but i understand that the core language is another deal
karswell_ is now known as karswell
<Regenaxer>
I think the possibility to write .so libs in pil is an underused (also by me) feature
<Regenaxer>
only 'ext' and 'ht'
<Regenaxer>
It is not so very simple though
<Regenaxer>
(writing a .so)
<Regenaxer>
needs asm
<Regenaxer>
Easier in arm64 than in x86 iirc
<Regenaxer>
cause the x86 asm version does not fully support pos. independent code
<Regenaxer>
and that is needed in .so libs
<Regenaxer>
(This is the reason the base system was never ported to PIC coding)
<Regenaxer>
(only a subset for the libs)
<Regenaxer>
But on arm64, ppc64 or emu this is not an issue
<freeemint>
I only got x86, my server runs x86 ... so that is a bummer
<Regenaxer>
Well, still possible
<Regenaxer>
as in 'ext' and 'ht'
<freeemint>
The .so idea is maybe under utilized because nobody really knows how to connect asm to
<Regenaxer>
I don't remember, some addressing modes don't work
<Regenaxer>
Yes, right
<freeemint>
ext and ht are quiet limited in terms of parameters if i recall
<Regenaxer>
Not in parameters I think
<freeemint>
Ok, i am not that well versed on the native front