freenode/#sicl - IRC Chatlog
Search
10:00:07
lonjil
Essentially, it must not be too difficult for someone else to replicate the environment in which you obtained your results.
10:00:25
frodef
lonjil: in order to qualify as "research", shouldn't it also relate in some sense to "eternal truths", as opposed to .. you know, "development"?
10:00:28
beach
frodef: Because I am scared of the complexity required in order to monitor the quality of the decisions made and to design a system for undoing those decisions, and make different ones.
10:01:30
beach
frodef: People like heisig and myself try (often in vain) to enforces some similar requirements.
10:02:42
lonjil
frodef: scientific research, certainly. But what about, let's say, novel new optimisation techniques? The author may provide benchmarks showing how it improves things. It should be simple for other people to replicate those benchmarks.
10:14:16
beach
So, I think we need to divide up the work here. I'll take care of inventing new techniques such as fast generic dispatch, call-site optimization, path replication, etc. And y'all can do processor-specific optimizations. OK? :)
10:38:35
beach
This discussion has convinced me that I should delete the directory containing timing experiments for the particular x86 processor I had at the time. The results are almost certainly outdated now, and I think I even changed some decisions about SICL object representation since I created those experiments.
10:39:51
frodef
shka_: it's a dilemma. you pretty much need to have decent performance now. And prospects of decent performance also in the future. While knowing that the tomorrow's performance model springs out of what is performant today.
10:41:21
lonjil
Perhaps a separate repo for benches. Something of the form "SICL commit XYZ on CPU ABC".
10:43:12
frodef
(erc just lost connection and made a lot of fuss about reconnecting... this technology is such a throwback to the 90s.)
14:53:43
beach
Before I started working on the paper about call-site optimization, I was able to load Alexandria into Ersatz (E5). Today, I continued that progress and I am able to also load Acclimation, Clostrum, and Trucler.
14:54:59
beach
Alexandria generates lots of warnings, mostly because we are not using file-compilation semantics, so there is a warning whenever a function is called before being defined.
14:56:02
beach
Clostrum generates two warnings that should be fixed by importing two functions from the host. Acclimation and Trucler generate no warnings.
15:31:55
beach
I think this latest progress is very encouraging. There is no profound reason why it shouldn't be possible to load CST, Cleavir, etc. The same way. The only potential problem I see is Eclector, because of the I/O involved.
15:33:46
beach
But for Incless, I actually go all the way to buffered binary output. I then fake the write() system call, but that's all the faking I do.
15:35:55
beach
So in fact, if I can come up with a nice way of writing system calls, I could produce an executable that writes something and then exits.