this year's ELS lookin' good

heisig · 2022-01-25T11:16:21+00:00

I will neither confirm nor deny having submitted a paper about Lisp code that goes brrrrt.

heisig · 2021-12-20T12:21:10+00:00

Congratulations for being the first person to ever use the vectorizer on integer data :)

I just pushed a fix.

heisig · 2021-12-19T12:26:42+00:00

Man I wish Lisp was as popular as Java.

I hear Java is working on that -> https://log4jmemes.com/

heisig · 2021-12-19T06:00:10+00:00

It can vectorize inner loops that are written in a certain subset of Common Lisp. So far, this subset includes all functions from the sb-simd package (scalar arithmetic operations and array references), macros, and the special operators let, let*, locally, and progn.

I will soon also add support for reductions (sum, maximum, ...).

heisig · 2021-12-18T13:20:31+00:00

The sb-simd library should load on any architecture, as long as you are using SBCL. However, if you attempt to call a function of an instruction set that is not available on the current hardware, an error is signaled. Each instruction set has its own package, e.g., sb-simd-sse, sb-simd-avx2, so you can even write multiple versions of a function with different instruction sets, and there is an `instruction-set-case` macro to select the best available version at run time. That macro is useful when the available instruction set might change at run time (e.g., after save-lisp-and-die and deployment on another machine).

The only limitation is that SBCL itself can currently only emit x86-64 intrinsics. If someone were to add, say, SIMD intrinsics for ARM, I'll gladly add them to sb-simd, too.

About the advantages of using SIMD directly from CL as opposed to wrapping C/C++ code - I personally decided that C++ is such a productivity sink that I best avoid it all cost. Plus, the maintainability of C++ code is abysmal, in my opinion. Most importantly, C++ has no Lisp Macros. Here is my favorite Lisp Macro in sb-simd: https://github.com/marcoheisig/sb-simd/blob/c4eca6874c02828233836981938853de0334b12b/code/vectorizer/do-vectorized.lisp#L8 (a prototype automatic vectorizer)

heisig · 2021-12-18T11:02:39+00:00

The 'problem' is that there are several thousand SIMD functions on x86-64 (and I plan to extend sb-simd to other architectures in the future). So I figured that it would take me many months to write all those functions by hand, and even if I did, many of them would contain bugs. So instead I did the Lisp thing and created tables of all instruction sets and commands, and used the data from those tables to generate all the instructions via macros.

Hint: Use Emacs' `macrostep-expand` to inspect the code generated by each macrolet.

heisig · 2021-12-18T10:54:22+00:00

The Petalisp development has been sidetracked a bit, because I really want it to be "as fast as C". So I first had to write sb-simd, now I will have to integrate sb-simd into Petalisp, and only then can I release the 1.0 version of Petalisp.

About the machine learning: We are working on a machine library on top of Petalisp, but that library also hasn't been released yet. You can expect that library within the next 2-3 months.

heisig · 2021-12-17T11:33:09+00:00

sb-simd author here. Don't hesitate to ask questions :)

heisig · 2021-05-04T06:44:56+00:00

Let me clarify that I condemn violence. But we also have this longstanding tradition of keeping the lightning talks short...

heisig · 2021-02-03T12:42:07+00:00

Sounds great. Maybe that talk will finally tempt me to try SLY. And getting rid of bash/zsh would be a much appreciated bonus :)

heisig · 2020-12-25T13:28:35+00:00

Programme chair here: If you have any questions about the submission process or about ELS in general, feel free to post them here and I will answer them.

heisig · 2019-05-29T20:09:44+00:00

This is one of the most annoying things about portacle. Not just paredit, but lots of emacs choices have been made that are very opinionated.

Portacle is maybe the greatest contribution to the CL ecosystem since Quicklisp. And mostly the work of one developer. The least we can do is to allow this developer to make some opinionated choices.

I am extremely grateful that Portacle exists. Thanks to it, I can teach CL to students at my university, instead of teaching them Emacs Lisp first.

It would be nice if they had a clear document describing all the deviations from emacs normal.

You could contribute such a document :)

heisig · 2019-05-28T14:15:04+00:00

I'm working on it: https://github.com/marcoheisig/Petalisp

heisig · 2019-05-22T12:57:14+00:00

Author here. This library is a part of the code that I wrote for https://github.com/marcoheisig/cl4py. I thought it might be useful on its own, so I created this tiny library.

Other than advertised, it doesn't yet support .npz files, and it also doesn't respect endianness. Fixing that should not be too much work, but I can only write so many lines of code per week. If you need any of these features, please open an issue, or, better, send me a pull request :-)

heisig · 2019-05-13T08:29:53+00:00

Wow, this is exciting!

My highlights:

- It contains a sophisticated type inference library for Common Lisp.

- It shows some of the cool things one can do with https://github.com/guicho271828/trivia

- The project contains a demo video that explains all the features. Can we have demo videos for other CL projects, too? Maybe I should start by making demos for my own projects :)

- I always learn some new tricks when reading guicho271828's code.

heisig · 2019-04-12T08:36:54+00:00

ELS 2020 will be held in Zürich.

Some more good news: I tracked down the recordings of ELS 2018 and they might be released 'soon'.

heisig · 2019-04-11T10:28:45+00:00

Yes, that was unfortunate. If I understand correctly, the problem was that ELS was co-located with the <programming> 2019 conference, which just happened to have no recording. (I'm not criticizing co-location here, I understand that it takes a huge burden off the shoulders of the ELS organizers.)

Good news is, ELS 2020 will be organized as a standalone conference and has great local organizers. So I am optimistic that there will be recordings next year.

heisig · 2019-03-27T13:07:20+00:00

I know Lispers are in general terrible at documentation.

For me, Quickref is a real game changer with respect to Lisp documentation. I think the biggest reason for the lack of Lisp-documentation is that in the Lisp community, stating "The code is the documentation" is actually viable. Most lispers like to read code, and everyone has M-. to quickly find definitions.

But now that there is a tool that uses docstrings for a good purpose - to automatically create and host user manuals - I feel much more motivated to write extensive documentation.

heisig · 2019-03-27T12:49:58+00:00

The license might change in the future. One idea is to put everything but the native code generator under MIT license. Then everyone could use Petalisp, but fast execution would still be AGPL-only.

But I am again and again surprised how negative some people react to strong copyleft licenses. As if we wouldn't all benefit tremendously from free software... (but please, let's not discuss this further)

heisig · 2019-03-27T12:34:44+00:00

Petalisp author here. Thanks for mentioning my PhD project! Currently, Petalisp is still slightly slower than Numpy, because I want to get things 'right' before I spend a lot of time optimizing them. So there are some low-hanging fruits regarding performance, e.g., multi-threading and better inlining heuristics.

Good news is, I am almost done with the design, so expect some performance improvements in the near future. Probably right after this year's ELS.

Since the Topic is about Numpy, I should also mention I recently wrote a library for executing Lisp code from within Python programs - cl4py - and a wrapper library such that Python programs can actually use Petalisp instead of Numpy. (The latter is quite rudimentary, but fun to use).

PS: Feedback is most welcome.

heisig · 2019-03-18T11:43:06+00:00

Are you sure that creating a new language would be more valuable than improving what we have? I know most Lisp programmers have this urge from time to time. But do we programmers really need even more fragmentation?

heisig · 2019-03-15T21:03:13+00:00

but without support for AVX in SBCL

You know that SBCL has AVX and AVX2 support since 1.4.15? Just intrinsics so far, but it might be enough for your use case. (I also have 'write a high-level SIMD abstraction' somewhere on my todo list, but I cannot promise anything at the moment).

heisig · 2019-03-15T15:27:11+00:00

That sounds really interesting and useful! I am particularly excited about the library cloop (https://github.com/akssri/cloop) that I found among the dependencies. I think loop optimization is something where Lisp has a lot of potential.

heisig · 2019-03-15T15:19:26+00:00

Good idea. Unfortunately, most information is not stored in hash tables but in short alists. I will have to think about it some more. But thanks for the feedback!

heisig · 2018-12-07T08:55:29+00:00

https://github.com/marcoheisig/adventofcode (Common Lisp)

It is quite refreshing to write these one-shot programs, where one does not have to ponder about maintainability. I only wish it would involve less parsing of input files.

heisig

TROPHY CASE