freenode/#sicl - IRC Chatlog
Search
0:04:04
no-defun-allowed
Okay, a working Pi 4 finally arrived; it's consistently about 4× faster than the old Pi 2 on SICL bootstrapping, Netfarm and whatever else I could think of to test with.
3:40:04
no-defun-allowed
I didn't pull after my test on the old Pi, which would be more fair. But I'll pull and try again...
3:58:51
no-defun-allowed
It is taking a lot longer, and it's been loading Conditions/Portable-condition-system/condition-hierarchy.fasl for a few minutes now.
3:59:54
jcowan
no-defun-allowed: However, ST has an image which is not bootstrapped; there are bits in this image that were set before 1980, and for which there is no corresponding source code.
4:01:20
beach
no-defun-allowed: You can see why I want heisig to come back from vacation, so that he can speed up HIR execution. :)
4:02:13
no-defun-allowed
I would make an analogy between the image and virtual machine in Smalltalk, and the graph of objects and the HIR interpreter in a similarly implemented Common Lisp implementation.
4:03:21
no-defun-allowed
Oh, but a bootstrap process should probably produce that graph for Common Lisp. Never mind then.
4:19:21
no-defun-allowed
I would not advise throwing out any computers, especially not for that then :)
4:20:48
beach
Yeah. I have other reasons for wanting to throw it out, but not strong enough to actually act upon them.
4:21:38
no-defun-allowed
But I guess I haven't paid too much attention to the stuff that works and can be loaded into a SICL environment now.
6:03:59
beach
So, again, I think the current bootstrapping speed will quickly become unacceptable, when I start loading big chunks like the compiler, Eclector, FORMAT, LOOP, etc. We'll see what heisig's HIR evaluator will do. If that is not enough, I could put off loading some stuff until the executable exists. Then the code will execute natively, so it will be faster. Other possibilities include turning ASTs into host code rather than
6:06:40
beach
Another option is to optimize the HIR before it is evaluated. Yet another is to inline global functions such as CAR, CDR, etc. which is not done now.
6:25:45
beach
Optimizing HIR and inlining global functions are both things that we must do at some point anyway, so those things do not represent "wasted" effort, whereas some of the other suggests do.
6:27:20
beach
I ran sb-sprof at some point, and the HIR interpreter takes almost all the time. It also showed timing per method/instruction, and as I recall, multiple-value-call was a large chunk.
6:28:20
beach
The reason for that is that multiple-value-bind expands to multiple-value-call, and multiple-value-call is particularly complex. So one simple optimization would be to figure out a better expansion for multiple-value-bind.
9:24:11
beach
So I ran sb-sprof again, and if I understand the output, the HIR interpreter takes almost all the execution time (99.6%), and interpreting the FUNCALL-INSTRUCTION represents more than 92% of the total time.
9:25:35
beach
This result suggests to me that more inlining could make a big difference. We already inline nested functions when that is determined possible, but we do not inline global functions.
9:33:00
beach
So now I don't think any particular instruction dominates the execution time, and that makes heisig's idea the right one, i.e., optimize the interpretation itself.
9:34:55
beach
Accessing the lexical environment is around 15% of the execution time, and that fraction will likely increase as the instruction execution is made faster.
9:35:46
beach
So turning the hash table into a vector will likely make a big difference, at least later on.
9:39:54
beach
Actually, it looks like accessing the lexical environment represents some 25% of the total time.
9:41:38
beach
I don't know whether version 1 of heisig's HIR evaluator changes the representation of lexical environments. If not, we should see a significant increase in that percentage when his evaluator is used.
9:56:40
jackdaniel
in ttf renderer written by Andy Hefner there was a very specialized "hash table" based on a vector, because gethash was the bottleneck when rendering glyphs. I've extended it to account for pairs of characters to account for kerning.
10:01:10
beach
jackdaniel: Sounds good. But in the case of HIR, it is straightforward to scan the program first, and assign an index to each variable.
10:01:23
jackdaniel
since characters have an index with the upper bound, it is possible to construct hashes directly from the index (or a pair of indexes if we take pairs of glyphs)
10:01:43
jackdaniel
moreover there are no conflicts, so it is just a bit fiddling operation to compute the hash and address of the value
10:33:46
heisig
I made some progress with the HIR evaluator, but haven't solved the issue in boot phase 3, yet.
10:35:03
heisig
The evaluator dies when attempting to throw to sicl-run-time:frame-pointer tag that doesn't exist.
10:36:34
beach
heisig: Before I forget, I wanted to ask you when you plan to graduate. And whether in Germany, it is a good idea to then do a post-doc. If so, if I were you, I would apply to EPITA.