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.