freenode/#clasp - IRC Chatlog
Search
13:20:47
Bike
i guess not that weird since uaets are done at that point so the switch is faster, but still
15:36:50
beach
And we need to determine whether to have data with associated types or have the types implied by the instructions.
15:37:19
Bike
https://eli.thegreenplace.net/2014/sfinae-and-enable_if/ how is C++ this absurd. i want an ifdef, i get... this
15:37:41
beach
drmeister: I am open to suggestions. I mean not just "I vote for X", but that come with some analysis of pros and cons.
15:38:21
Bike
the particular reason for the types is so that LLVM knows what sizes to use for stack allocations.
15:39:21
beach
I see. But that's a biased argument in my opinion. Though it is entirely possible that it is the best solution anyway, of course.
15:40:19
beach
There is also the question of how much to cater to similarity of existing processor, possibly closing the door to more unusual ones.
15:41:00
beach
That sounds very reasonable. I just want to hear some more arguments before making a decision.
15:42:12
Bike
sizes also matter with whatever aref-instruction would lower toin mir. i believe the "memref" instruction says it works with word addressing, the reasonable assumption being that an object pointer will be word sized
15:43:24
beach
I guess it is safe to make instructions that assume that, and then have client code use a different set of instructions for other architectures.
15:43:57
beach
We can just label certain instructions as being usable only on byte-addressed processors. I don't have a problem with that.
15:50:40
beach
We just supply a MIR instruction set for byte-addressed architectures, and we can create a different set the day we need something else.
15:51:49
beach
Maybe Bike, drmeister, karlosz, and Shinmera can get together and write down a suggested initial set of instructions and data.
15:54:47
karlosz
an alternative representation of SSA (like SFA or some other variant) that avoids indices on inputs would help
15:54:50
beach
I would go one step further. SSA, as formulated in the literature, is not well suted.
15:55:52
karlosz
any variant of ssa that avoids the phi representation (the mlton people use something closer to cps)
15:56:06
beach
I find the idea of an "alternative representation for SSA" that is not S.S.A an interesting idea so to speak.
15:57:12
karlosz
i found ot thjat lots of compilers that use SSA dont represent phi nodes like in the literature
15:58:29
Bike
in llvm the phi nodes have a map from predecessor blocks to values. still would be trouble if you want to break up a predecessor block, though.
15:59:04
beach
karlosz: that is exactly my point. It is called SSA because it is S.S.A, and it turns out that nobody needs or wants that particular property of SSA.
15:59:59
Bike
with cleavir the obvious analog would be mapping predecessor /instructions/ to values, but then you have to be careful whenever you throw in new instructions.
16:01:29
beach
And then we can write an article about how none of these techniques actually need the S.S.A property of SSA.
16:04:37
karlosz
beach: i was just trying to point out that SFA might not be as novel as you think it is
16:05:10
karlosz
its a bit long but they essentially describe that their ssa notation is a bit lacking in the assignment department
16:06:12
karlosz
but whatever alternative way of expression the join points we decide to do as long as it satisfies the basic requirements of what makes SSA and CPS great then we can use it
16:07:33
karlosz
one could evaluate whether assignment instructions or a special instruction or even adding some kind of parameter like they do in MLton would be easier for Cleavir
16:19:34
beach
karlosz: Sorry this is one of the days of the week and the time of that day, where I make food for me and my (admittedly small) family.
16:24:51
beach
So am I the only one that thinks it is ironic that we have "alternative representations of SSA" that do not have the S.S.A property?
16:24:56
beach
I mean, the inventors of SSA went to great lengths to get the S.S.A property. They even invented a new instruction and made the order of the predecessors of that instruction significant, just so that they could call it SSA.
16:24:58
beach
And we still think we have the right to call it SSA when we totally destroy that property that they worked so hard to achieve.
19:39:42
drmeister
shiho: the code that merges the force fields must be resetting a counter for the atom types.
19:53:59
Bike
is there a reason that we define templates for array classes and then define manual subclasses of those, other than that template metaprogramming is a huge pain
0:13:12
drmeister
Bike, cracauer: What do you think of this idea.... Currently to build aclasp, bclasp and cclasp we pass a list of partial pathnames to functions in clasp-builder.lisp.
0:14:38
drmeister
I will rewrite compile-aclasp so that it loads the files in a particular order and then compile-file's the source files in another order and links them in whatever order we want.
0:15:35
drmeister
The reason is to prepare for the coming GC of code and image building/dumping/loading we need more precise control over the compilation order.
0:16:33
drmeister
Currently we load all of the source files for aclasp in the order that we pass them in the command line.
0:17:12
drmeister
If I were to move the compile-file of setf.lisp to the end - then I could probably shave up to 10 minutes off of the build time.
0:18:08
drmeister
Why? Because then setf.lisp will be compiled by mostly compiled functions. As it is now, setf.lisp is compiled using mostly interpreted functions - and with MPS that takes 23 minutes!
0:18:51
drmeister
compile-file of setf.lisp --> Compile-file time seconds real(1412.0) run(1412.0) llvm(14.8) link(0)
0:20:26
drmeister
I haven't tried it yet, but if I moved setf.lisp compilation to the last files I think it will take a lot less time.
0:21:28
drmeister
The downside is that we will have separate lists of files that need to be maintained in clasp-builder.lisp and build_file_lists.py
0:23:08
Bike
i don't know about how it would affect speed, but separate load and compile sequences sounds like a good idea provisionally.
0:23:50
drmeister
In the future when we have GC managed code and image saving and loading I think aclasp, bclasp and cclasp will go away.
0:24:54
drmeister
All there will be is an explicit build script that will load files into the interpreter, then install the interpreted compiler, then load source code again, this time compiling it into JITted code, then loading what are now all of the bclasp files, then cleavir and then saving the image.
0:25:34
drmeister
There will be no incremental building - unless we decide to save an image at some intermediate stage and pick up from there.
0:26:23
drmeister
Is sbcl-ish a good thing in this case? Because you know how I revere everything sbcl.
0:28:15
drmeister
cracauer: Could you elaborate on your question "wouldn't we have enough debug info around to not even need to load a second time?" --- The purpose of loading things more than once in my mind is to first load code as interpreted s-exps and the second time to have the toplevel forms compiled and JITed.
0:30:29
drmeister
From what I read they look very similar but the reporters said the feel is different.
0:31:26
drmeister
Not as loud, smoother feel. I haven't heard any reports about how they behave six months in when a nanoparticle enters the butterfly mechanism.
0:32:34
cracauer
cases seem to be the same, aka of you want 4 ports then you have to take the touchbar.
0:42:36
cracauer
I have a first-generation 12" macbook, which is the worst of the butterfly keyboards. The main problem isn't even that keys go out. The main problem for me is that the key feedback is just leading to errors.
0:46:26
drmeister
But I need one that has no extra keypad on the side - so it can fit in a backpack.
0:51:18
cracauer
I ordered one each of the reduced keycount layouts. I think one of them will be small enough to drag around in my camera bag.
0:54:58
drmeister
(1) The static analyzer can tell us what classes have extra C++ information (on the C++ heap) that needs to be saved/loaded. Those that have extra info we can handle specially with obj_save/obj_load or eliminate from memory before saving the image.
0:56:00
drmeister
(2) I added code to generate backtraces whenever classes with a certain stamp are used to make an instance - this will let us track down where objects are being created and eliminate the problematic ones.
0:57:12
drmeister
(3) it will cut the build time in half - currently we load/compile/jit all of the code and then we compile-file it again and link it. Once we do image save/load we will only need to load/compile/jit and then dump the code.