IRC channel logs

<stikonas>oriansj: thanks for merging bootstrap seed PR

<stikonas>now I just need to go up the chain, but hopefully it will be easier and easier

<stikonas>well, hex1 will still need some fidling...

<stikonas>but after that with labels it will be much easier

<GoogulatorMobile>fossy: pushed the final script refactor, ready for review

<GoogulatorMobile>Thanks for the hint about rebase -i btw, it's indeed "git histedit" in all but name

<GoogulatorMobile>(if only there was also a "git evolve"...)

<stikonas>yeah, "git rebase -i" is quite essential when you work on multi-commit features

<stikonas>I usually invoke it as "git rebase -i master" rather than specific commit number, so I don't need to count

<oriansj>wow, one can add garbage collection to C without really changing the language

<oriansj>or breaking any existing programs

<GoogulatorMobile>Garbage-collected implementations of C have been IIRC officially permitted since the first ANSI standard

<GoogulatorMobile>C++ actually lagged behind on that, only in C++11 was garbage collection officially allowed

<oriansj>one only needs to add malloc_stack, malloc_compact and malloc_gc; malloc_stack automatically gets collected when the function returns and malloc_gc pointers are tracked and garbage collected only when malloc_gc or when malloc_compact is called. calling free on malloc_stack or malloc_gc memory should be a nop and the compiler only needs to track the malloc_gc pointers.

<stikonas>GoogulatorMobile: so ekaitz found that mes indeed compiles things twice now...

<stikonas>(though not intentionally)

<stikonas>there isn't any extra optimization

<ekaitz>compiling anything with -vvv shows that it reads the file twice

<ekaitz>and outputs things twice

<stikonas>yeah, that's not good...

<stikonas>mes was already slow

<stikonas>though somehow under qemu it feels far slower than twice

<stikonas>but maybe it's a combination of thigns

<stikonas>e.g. 2x slowdown from doing things twice, then some extra slowdown from loading more scheme libraries

<ekaitz>i think if we make it run things just once it might be faster than before

<ekaitz>but i don't know

<stikonas>I doubt it...

<stikonas>but let's see...

<GoogulatorMobile>ekaitz: so basically it compiles everything, writes a finishing binary, then does it again exactly the same, overwriting the original compiled binary with itself?

<oriansj>it also evaluates lisp code in lisp code before running the evaluation if I remember correctly

<oriansj>a sort of making a more powerful lisp in the lisp subset implemented in mes.c which is a very clever way to keep mes.c much simpler and smaller.

<oriansj>although expanding mes.c and skipping that double implementation would probably really help performance but only janneke knows.

<stikonas>oriansj: well, if you really want performance, probably improving M2-Planet or writing something after M2-Planet would help far more

<stikonas>I guess at this point M2-Planet is not that far behind mescc

<stikonas>but it's always the small remaining bugs that take a lot of time to sort out if you want to bootstrap something new

<ekaitz>GoogulatorMobile: I know where it's coming from i think

<ekaitz>i'll patch it

<ekaitz>it's basically calling main twice

<GoogulatorMobile>Ouch

<GoogulatorMobile>It's weird that "Hello, m2-mes!" isn't printed twice, though

<GoogulatorMobile>Or is it only when loading Scheme code from a file?

<ekaitz>it's calling the mescc module's main twice only

<ekaitz>brb

<oriansj>stikonas: well I guess I could write an optimizing C compiler using only the M2-Planet subset

<oriansj>it'll take me a while but we probably could give mescc an even better assembler and linker

<ekaitz>okay i'm back now

<ekaitz>the problem is in scripts/mescc.scm.in

<ekaitz>it's like now mes it's able to launch the main function of the script automatically

<ekaitz>instead of having to import it and launch it manually

<ekaitz>so now it's doing it twice

<ekaitz>i'm trying to figure out what change produced that

<ekaitz>something made the modules be the default so the code is loaded twice

<ekaitz>and that's probably affecting other things too

<ekaitz>oriansj: we need to improve mescc's performance a little

<ekaitz>i think we could get a way better performance with little effort if we choose wisely what to do

<ekaitz>that would require some measuring

<stikonas>ekaitz: there might also be some (but not huge) gains if we replace some if/elseif chains with switch (especially in eval-apply)

<ekaitz>stikonas: do you think so? aren't both of them generating a very similar code?

<stikonas>in the optimizing compiler yes, but our code might be less optimal..

<stikonas>hmm

<stikonas>not sure about mescc, but new switch in M2-Planet might be better than if/else chains

<stikonas>oriansj might know better as he did that switch work

<oriansj>much more efficient to use the switch than if/else

<oriansj>as it is 2 instructions per case in switch and 6 instructions per case in if/else

<stikonas>yeah, that might make non-trivial difference for the whole program

<oriansj>but both benefit greatly from being careful in the ordering of the most common case to least common case

<stikonas>I think that eval-apply can be up to 25% of mescc runtime

<stikonas>but we need to release new M2-Planet first...

<oriansj>although fallthrough cases might also benefit scheme more

<ekaitz>hmmmm

<oriansj>and performance optimizations like lambda lifting require would require a mjor rewrite of M2-Planet

<ekaitz>do we have switch/case in m2 already?

<oriansj>yep

<ekaitz>let's try this then aiight?

<oriansj>as of commit 5566930976d23f0c6efeb03cf6cc19cf04cb61c1 on 2023-NOV-10

<ekaitz>oh it's a new thing then

<oriansj>yeah, it just missed the Release_1.11.0

<ekaitz>wow there are many if blocks

<ekaitz>can M2 do x || y || z ?

<oriansj>for switch statements or in general?

<ekaitz>in general

<oriansj>oh yeah

<oriansj>even cc_* supports that

<ekaitz>there are some if(x == a) {this} else if (x == b){ this }

<ekaitz>which doesn't have a lot of sense to me

<oriansj>and if((x==a)||(x==b)) {this} will work

<oriansj>but if a/b/x are integers, you can just do switch(x) {case a: caseb: this}

<ekaitz>yes

<ekaitz>I just changed the eval_apply block

<ekaitz>only that

<ekaitz>i can try to use that and see if there's any performance improvement

<stikonas>on mes->mescc?

<stikonas>hopefully it's also faster, but might not be the same factor as mes-m2 -> mescc (but mes-m2 will need newer M2-Planet)

<ekaitz>in general, if this is better, we should go for this

<ekaitz>also the code is way easier to read

<stikonas>yeah, I understand that. I was wondering how you test?

<stikonas>ekaitz: another observation, mes 0.26 seems not that as slow on tcc.c as was with those small libc files

<stikonas>after 1h it is already showing some warnings

<ekaitz>hm

<stikonas>so there is probably a lot of overhead for each invocation of mes

<ekaitz>it's probably improved the performance on longer runs

<ekaitz>yeah

<stikonas>(that's qemu)

<stikonas>might be worse performance on short runs though

<stikonas>well, but let's see what happens once double build is fixed

<stikonas>anyway, I'll probaby know tomorrow whether tcc-mes works on riscv

<ekaitz>good

<ekaitz>i think it's going to explode with the addend error we talked about

<ekaitz>please help me understand, if is slower than switch-case because it has to load the variables and all that?

<ekaitz>i'm trying to walk the assembly in my head...

<stikonas>ekaitz: maybe worth generating small test program...

<ekaitz>(i did the switch/case implementation of mes and here we are)

<stikonas>maybe mes is good there

<stikonas>but M2-Planet's code, so mes-m2 would be faster

<ekaitz>what I see is there's a lot of indirection too

<ekaitz>that makes sense

<stikonas>let me try to write something small

<ekaitz>and for slow memories... it would break our performance

<stikonas>oriansj: default is required in M2-Planet?

<stikonas>in switch statement?

<stikonas>ekaitz: 2 sample programs and assembly: https://paste.debian.net/1301897/

<ekaitz>ugh i'm not very comfortable with x86

<stikonas>riscv?

<ekaitz>better yeah

<ekaitz>(thanks)

<stikonas>though it will be that inverse order riscv

<stikonas>(that M1 can process...)

<stikonas>ekaitz: https://paste.debian.net/1301898/

<stikonas>first block is switch/case, second is if/elseif

<ekaitz>yeah its way longer the if case

<stikonas>so for if/elseif M2-Planet does a lot of comparison statements

<stikonas>whereas switch/case is basically done during compilation

<stikonas>we just jump directly into required case

<stikonas>hmm, no maybe I'm lying

<ekaitz>it's not as simple as jumping to the case

<stikonas>yeah, we jump to the table

<ekaitz>but yeah

<ekaitz>it's better the case

<ekaitz>it's way better for such a simple program

<ekaitz>a 20% or so

<ekaitz>but that's on code size

<ekaitz>of course the exit is way better in the switch-case than in the if

<ekaitz>on is just exiting

<ekaitz>and the other has to recheck all

<ekaitz>does it make sense to put the hotest case on the top?

<stikonas>well, yes

<stikonas>then the hotest will be done in the first cmp statement

<stikonas>oriansj: said that too a few minutes ago

<ekaitz>oh i may have missed that

<ekaitz>hmm also in the if/elses we are exiting fast

<ekaitz>so it's not that bad anyway

<ekaitz>smaller code, but not that big performance hit, right?

<ekaitz>let me try

<ekaitz>maybe just putting the same code of the examples you gave me in a loop 1000 times can show if there's some benefit

IRC channel logs

2023-12-22.log