freenode/#sicl - IRC Chatlog
Search
9:18:30
no-defun-allowed
There was one album Gnuxie and I enjoyed which is in French, but the musicians were from Quebec, so I don't think it counts.
9:23:18
beach
ralt: It was thanks to "Jack Allgood" who made a rule that radio must have 50% French music, that we finally got to get French quality music.
9:26:43
beach
ralt: I wish he would come back. I am working on a short story in French that contains almost 50% of English words that we hear daily on TV.
9:28:18
lonjil
frodef: Agner is probably one of the most knowledgable people in the world when it comes to what modern CPUs like or don't like.
9:28:54
ralt
language is spoken, for me, so whatever is deemed popular ends up being the language, by definition
9:29:46
beach
ralt: It is just that anglicisms in French sound very stupid, especially when they are pronounced the way they are.
9:32:36
beach
Il a monté un start-up pour acheter un cottage très cozy dans Center Parcs et c'est un véritable success-story.
9:36:09
frodef
https://www.agner.org/forum/viewtopic.php?f=1&t=41&sid=65636ac8be2a1901fcab6adb3bd0d08b stuff like this might have serious impact on run-time (and compiler) design.
9:46:52
beach
The problems with that kind of stuff are: 1. Since it is not documented, it may disappear in future processors. 2. It is specific to AMD and even to a particular processor family.
9:47:58
beach
So exploiting it in the compiler would mean some complex configuration scripts and/or run-time measures.
9:48:57
ralt
OTOH, as soon as you want to dive into assembly optimization, having per-processor branches is kind of a requirement
9:49:25
frodef
beach: he's elsewhere talking about how intel/amd compilers emit code that check for not only instruction-sets, but specific CPU models...
9:49:37
ralt
you can rely on features as much as you can, but at some point, you have buggy processors, some undocumented features on specific CPUs that are really worth it, etc etc.
9:50:41
frodef
ralt: ...and complaints that intel compilers intentionally run bad on AMD cpus, and so on and on.
9:52:53
heisig
One of my life goals is to get rid of the Intel compiler (or have it turned into an open source tool).
9:53:17
beach
I think I need to leave most of those detailed optimizations of SICL to people more competent than myself.
9:53:53
heisig
I don't grow tired of publicly shaming people in academia for using Intel's compiler. Everyone is talking about reproducible research, but then they use an obscure compiler that requires a revocable license from Intel to use it.
9:57:15
heisig
frodef: Not under my watch. But such papers are getting accepted at otherwise reputable conferences. And beach is right, I shouldn't get started.
9:58:09
beach
I suppose I could accept a kind of JIT that depends on intrinsic characteristics of the processor being used. What makes me queasy is to use JIT based on past executions of the application.
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.