freenode/#clasp - IRC Chatlog
Search
2:11:13
drmeister
Bike: When I speak at Nvidia on Friday - I'm going to lay out a scheme for using Cleavir to generate code for GPU's.
2:12:34
drmeister
Indeedy - We can reuse all of the cleavir machinery with a new system parameter and cleavir methods for generating PTX - https://devblogs.nvidia.com/gpu-computing-julia-programming-language/
2:13:39
drmeister
We can define a new file-local variable like *package* and *readtable* that switches the compiler into cuda mode where the math follows different rules.
2:13:53
Bike
i don't have a super good context of how gpus work, but my impression was that gpu code is pretty different from cpu code
2:15:00
drmeister
Look at the julia example - they reuse the julia compiler and add 1300 LOC and they generate GPU kernels.
2:19:36
drmeister
Yes - of course. Declare local variables, global variables, arithmetic, if and a few other things and you have a language.
2:20:21
drmeister
Modulo integer arithmetic, unboxed single and double precision values, dynamic extent variables.
2:20:39
Bike
so i mean it sounds like a pretty different language from common lisp. so i'm not sure how much we can really reuse.
2:21:43
drmeister
Since we use S-expressions we can use macros and generate kernels on the fly for specific purposes.
2:22:53
drmeister
Like the molecular fragment building code that I want. I can code the structure of the molecule into the kernel. It will only be able to build one kind of molecule - but it will do it really fast and sample lots of conformations and stereoisomers.
2:23:37
drmeister
Run it for a few tens of milliseconds and then build and load a new kernel for a different set of molecules.
2:26:54
Bike
a lter stage would cut out redundant box-unbox sequences, but we don't right now becuase bla bla type inference sucks
2:30:43
drmeister
Once you get inlining to work I say tackle basic value numbering algorithm and type inference again.
2:32:30
Bike
i mean, inlining does work. my optimizations are wrong is all. i could revert a few commits and it would work.
2:34:14
Bike
i guess figuring out the nature of the inlining operation that's resulting in the bad hir
2:34:22
drmeister
How about reverting the changes and applying them back slowly to figure out where things go wrong.
2:35:30
drmeister
https://github.com/clasp-developers/clasp/blob/dev/src/lisp/kernel/cleavir/translate.lisp#L419
2:35:42
Bike
it's two commits. with one commit swank compiles but not my reduced example. so it's both commits that are problematic.
2:56:52
drmeister
Do we need to change how defconstant compiles in Clasp so that we can handle things like...
3:52:54
ringer1_
drmeister, don't want to take up any of your time (tonight) but I do want to use clasp and help in some way
3:53:43
ringer1_
Was starting to fear the project was stalled -- had trouble finding your irc even (my client didn't have the channel)
3:57:59
ringer1_
drmeister, yes it is HUGE, I watched your old talk at Google and you amazed me (I am not that easily impressed either)
4:01:13
ringer1
sorry, got kicked by server issue -- having multiple irc client difficulties getting to you folks
4:01:58
ringer1
beach, I thought that would be enough -- limited Lisp experience and he first got it working and then brought it up to decent performance
4:02:44
ringer1
There isn't detail of that effort in the talk, but I'll bet there are a lot of specifics I don't know about
4:03:30
ringer1
but I can imagine trying to hack through these several code bases, just getting the builds to work can be tedious as soon as you leave the main line
4:03:56
drmeister
beach: I plan to propose at Nvidia that we use cleavir to compile a small subset of Common Lisp to PTX for Nvidia GPU's.
4:04:02
ringer1
I run into this because although I'm willing to do Linux, I typically want to see Windows work also
4:05:56
ringer1
I knew a tiny amount about LLVM since I've been looking into Julia and Haskell to LLVM
4:22:06
drmeister
beach: I'm not sure if I asked this before - we don't have a way of serializing HIR do we?
4:24:25
drmeister
::notify kpoeck Did you see this problem building mcclim? [package iterate]...............Condition of type: SIMPLE-ERRORNo applicable method for UPDATE-INSTANCE-FOR-REDEFINED-CLASS with arguments of types CLAUSE-INFO NULL NULL NULL. ? If so - how did you get past it?
4:38:16
beach
We would need to add methods on that generic function (SAVE-INFO is it?) for every HIR class. But that can be done.
5:42:17
ringer1
good night, any particular thing best to read or do to get up to speed? Found the cleavir.pdf
5:43:13
beach
Depends on what you want to accomplish. As a user of Clasp, you don't need any of that.
5:43:47
beach
If you want to attack the compiler, you need to be an experienced Common Lisp programmer with lots of CLOS experience, and you need to know about compiler design.
11:24:22
drmeister
beach: I'm thinking of serializing HIR so that we can get optcl (sp?) running and render HIR from clasp.
11:25:01
drmeister
Bike has got a nasty inlining bug and I'm thinking about tools that could help debug the problem.
11:46:21
drmeister
Because I'm having trouble getting McClim to build on Clasp and it takes a long time to get it to build.
11:47:14
drmeister
So - what if we serialize out HIR graphs as we generate them and then flip through them with opticl running on McClim in sbcl.
11:48:05
drmeister
Like we currently use Chrome to visualize HIR graphs serialized out as PDF or PNG files.
11:48:07
beach
But if you are going to run it from SBCL, why not run the visualizer. SBCL loads McCLIM quite easily.
11:50:38
drmeister
When kpoeck told me about it I assumed it was your HIR viewer. In retrospect it seems a bit odd that kpoeck would point me to the HIR visualizer.
11:51:54
beach
Well, if you run cleavir-ir-visualizer from SBCL, you don't need to care about opticl.
11:56:12
drmeister
Here's what I'm imagining - if we were to set up a breakpoint in the inlining code and step through it from break-point to break-point while generating HIR output in sequential files - could the cleavir-ir-visualizer rapidly render the HIR so we can see each change to the HIR as it happens?
11:57:37
beach
Hard to say. I imagine it depends on the size of the HIR. When I have used it, it was instantaneous.
11:58:20
drmeister
Bike has spent months debugging inlining and I have a lot of ideas for things to do with HIR.
11:59:27
beach
I would set up a SICL first-class global environment inside SBCL that contains Clasp macros and other essential definitions.
12:02:07
drmeister
We need a better tool to debug this stuff. The "sea of nodes" is bewildering to navigate.
12:03:32
beach
A basic block would have tons of data input to it and output from it that would not be obvious to understand.
12:04:41
drmeister
We don't have a basic block compiler - we need more powerful debugging tools for our compiler.
12:05:01
beach
Looking at your Graphviz renderings, I can already say that the visualizer does a much better job.
12:05:26
drmeister
But using graphviz from one graph to another, things jump around a lot and we can't collapse and expand subgraphs.
12:06:48
drmeister
I'd like to add annotations to the HIR and have the visualizer use those annotations to decide what to render.
12:07:56
drmeister
Sounds dreamy - I'll encourage Bike to get sicl and the visualizer up and running.
12:08:37
beach
I carefully compute the longest simple path in each function so that the main control flow is downwards.
12:10:46
beach
Now, the visualizer is CLIM and Common Lisp code, so it would be fairly easy to add a CLIM command, say, "inline step".
12:11:16
beach
... since CLIM automatically recomputes the output records after each command invocation.
12:12:53
beach
And it could be driven by "presentations". Click on a node to transform it in some way.
12:13:30
beach
These commands don't all exist of course, but this is CLIM and Common Lisp, so they make it easy to do things like that.
12:17:38
drmeister
Sounds good. What do you think about a "comment" instruction - it would do nothing but let you embed some info in the HIR and it would get carried along with the transformations.
12:23:31
scymtym
beach: i hope i'm reducing the confusion instead of adding to it but i also thought that opticl was a non-optional dependency of mcclim nowadays. are you sure it is not?
12:26:25
scymtym
i guess the important question is whether loading mcclim automatically loads opticl and if so, if there is a way to avoid that
12:27:11
jackdaniel
it is on asdf dependency chain (so yes, it is loaded by default), but changing that would be easy
12:28:21
stassats
you were not happy with it using ffi, but if you don't actually run the code that uses ffi, that won't be a problem
12:29:25
jackdaniel
I think that clisp was locked out due to indirect dependency on static vectors by opticl
12:31:03
jackdaniel
yes, I believe it is based on ffi and on unsupported implementations it simply errors in asd file
12:33:42
jackdaniel
excerpt from its readme: "Can optionally write to foreign memory using static-vectors. This is useful when needing to
12:33:45
jackdaniel
efficiently pass a pointer to the image data with a foreign library, such as OpenGL."
12:34:41
jackdaniel
and pngload is opticl's fast backend for png loading (there was slower implementation used beforehand and that's what clisp resolves to)
12:37:54
beach
I think if opticl is the only problem for loading McCLIM into Clasp, and McCLIM doesn't really need it, at least not in order to run the visualizer, then the most efficient solution is to comment out the dependency on opticl.
12:40:22
scymtym
the high performance claim of pngload doesn't seem super-convincing given they do (with-slots (data palette transparency) *png-object* …) and then access the slots in inner loops
12:41:25
Shinmera
scymtym: It's faster than the previous library for sure and currently bounded by chipz deflation.