freenode/#clasp - IRC Chatlog
Search
11:03:46
selwyn
i built in 1h51 just now - basically no change. i wonder if i did something wrong? asdf did take a while
11:06:30
drmeister
I don't know - timing can be tricky. The flame graphs show improvements in inlining.
11:07:13
drmeister
Do you mean what is the difference between the CST compiler and the AST compiler?
11:08:26
drmeister
A couple of things - (1) the CST compiler tracks source locations for every expression. Source information is propagated all the way from where the source is read down to the object files.
11:09:49
drmeister
(2) The CST compiler fixes a subtle bug in the AST compiler that I still don't really appreciate - I think it's with closed over environments.
11:10:26
drmeister
In fixing that bug it generates code where LET statements are expanded into calls to functions. This slows down the generated code significantly (by a factor of 2 or so).
11:11:07
drmeister
The solution is to do a lot more inlining at the HIR level to improve the generated code performance.
11:11:24
drmeister
That inlining code is what we are dealing with now - it slows the compiler down a lot.
11:12:31
drmeister
So we crawl through this valley of slowness to come out the other side with a better compiler.
11:13:02
drmeister
The next big thing to do is value numbering, type inference and removal of dead code.
11:14:13
selwyn
right. i have to go now, i will read the logs and be back in a couple of hours. thanks for explanation
12:18:51
drmeister
I changed the file that I compile-file for this flame graph - I switched to format.lsp - it has a really long pause at the end when it is compiling the format compiler-macr
12:22:42
drmeister
I have a suggestion: (1) We temporarily add a slot to instructions that stores a 'visited' mark and write a new version of of map-instructions-xxxx that uses the 'visited' mark rather than a hash table to keep track of what instructions have been visited. I believe that this will cut inlining time by quite a lot.
12:23:09
drmeister
(2) We work on value numbering, type inference and removing useless code paths to tighten up the code.
15:53:29
kpoeck
karlosz: Changing to new sicl - with your patches- reduced build time for clasp - after wiping build - from Compilation finished in 5:24:51 to Compilation finished in 4:03:12, quite an improvement
16:56:16
karlosz
hello everyone. I have some more inlining improvements here: https://github.com/robert-strandh/SICL/pull/131
16:56:50
karlosz
i know you guys just did another rebase, but i observed another 2-3 hours improvement with these patches
16:57:12
Bike
the problem i had with set-predecessors is that we could inline a function that doesn't return, and that will cut off whatever the call dominates
16:58:07
karlosz
could you maybe take a look? i did some instrumenting and thought i got rid of most of that
17:00:18
Bike
well it's basically the same issue. we don't know what instructions we have to unhook from predecessors or definers/users
17:30:27
selwyn
drmeister: i'll find out the hard way - building with https://github.com/robert-strandh/SICL/pull/131 now
18:47:44
drmeister
Bike: We have a _SetfFunction slot - do you know if I use eval::funcall(_sym_touched->_SetfFunction,value,object) - will that set the value of the 'touched' slot?
18:49:10
drmeister
I think that's how it's supposed to work if I want to set the value of an objects slot.
18:49:36
kpoeck
karlosz: A flamegraph compiling asdf with your fixes that are already merged to sicl
18:57:26
drmeister
I know the name of the accessor is touched - so the setf function is (setf touched).
18:58:35
drmeister
I've rewritten map-instructions, map-instructions-with-owner and map-instructions-arbitrary-owner in C++ and switched from using a hash-table to using a slot called 'touched' in each instruction.
19:00:06
drmeister
I want to see if my hypothesis that overhead and using hash-tables to keep track of what instructions have been seen is responsible for a lot of the time taken by inlining.
19:20:50
drmeister
Bike: Did you add automatic generation of xxxx-instruction-p predicates? I thought you did but I don't see enclose-instruction-p
19:22:20
Bike
i guess with the dtree interpreter in place there's not as much worry of weird slowdowns, so i may as well
19:25:05
drmeister
selwyn: My new linux machine at home builds AST in about the same amount of time.
19:25:11
Bike
itll take me a bit to figure out since it involves anonymous generic functions and stuff
19:26:02
drmeister
FYI startup is a bit slower now because there are some compilations happening even when it only compiles the 1024th time a gf is called.
19:26:37
drmeister
Also - once you start compiling things there are big slowdowns as all the compilation chickens come home to roast.
19:31:09
Bike
like, i can put the thing to set up the predicate in initialize-instance for class, but that doesn't work for anything built in
19:32:05
drmeister
It's ok - I'm just hacking here - I added an enclose-instruction-p and enter-instruction-p predicate.
19:32:43
Bike
don't push it to the repo or anything, that caused me a lot of rebasing problems before
19:33:39
drmeister
I don't touch sicl - that's beach's and your domain - this is an experiment that I would be perfectly happy to see fail.
19:34:08
selwyn
speaking of chickens: at ELS i found out there is an attempt at chicken scheme <-> c++ integration
20:06:31
drmeister
It's not directly comparable to the other flame graphs I've posted because this is single threaded.
21:01:27
drmeister
Well, I'll be hornswoggled - the C++ version doesn't appear to offer any benefits whatsoever.
21:01:58
drmeister
I'm not sure - because I have to time an entire build - but the flame graphs look exactly the same!
21:02:40
drmeister
Yeah - they are different in the respects where I changed them - that's different.
21:06:17
Bike
it did decrease the reinitialize-data fraction by a percent or two. but yeah, doesn't seem to have helped much