Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SBCL: The Assembly Code Breadboard

pvk.ca

Post reply on HN
Print view View original

11–20 of 23 posts

Re: SBCL: The Assembly Code Breadboard

#11

Post by chrsig »

klyrs wrote: post #5
epgui wrote: post #4

Earlier quoted context omitted.

I really don't understand what would make someone say that Julia is lispy. People say that about R as well, but I don't see that either. To me, lisp is many things, but the first thing it is is s-expressions. Most/many languages have macros. Lisp is just particularly good at those...

I didn't interpret OC as calling Julia lispy, as much as saying that Julia is matched to SBCL's interactive machine code generation and inspection. I don't have a dog in that particular fight; I've barely touched either language. Except, macros. I have never seen macro wizardry come anywhere near SBCL without homoiconicity. edit: pre-coffee reading comprehension, apparently. The word lispy is _right there_ in OC.

To clarify, I was trying to say that both

- the julia runtime does a good job competing with sbcl with regard to interactive code generation. I'm not familiar enough with sbcl (or julia, really) to rank one over the other -- but from what I have seen, they're in the same ballpark.

- julia feels like a lisp to me, due to many features of the language and how much it emphasizes repl based development. I can respect that others may not feel the same -- it's a subjective matter.

I'm not heavily invested in either -- I just think they're both nifty.

Re: SBCL: The Assembly Code Breadboard

#12

Post by reikonomusha »

Common Lisp has DISASSEMBLE built-in to the language standard. You can take any function, even standard library functions, and inspect their disassembly.

SBCL goes further with two cool features:

1. It annotates the disassembly with your Lisp code. Sort of like godbolt, you can see how every line/chunk of your Lisp function gets translated to machine code.

2. It annotates the disassembly with profiler results. You can see the exact instructions the CPU is stalled at/hitting the most, directly inline in the disassembly.

This (and more) is all interactive and built-in. No additional installs. No additional tooling. No "re-run in debug mode".

These kinds of things make SBCL a really appealing choice for even extremely low-level programming.

Re: SBCL: The Assembly Code Breadboard

#13

Post by onetimeuse92304 »

reikonomusha wrote: post #8
onetimeuse92304 wrote: post #2

I used SBCL for an algorithmic trading framework for EXACTLY this reason. More precisely, this was SBCL/ANSI C application where most of the application was implemented in Common Lisp, some OS / low level stuff was written in ANSI C and same things were written in Lisp to compile to machine code and inserted into "C world". There would be no Common Lisp virtual machine on the critical, low latency path. Instead, the…

Very cool story; thanks for sharing! I think a major fault in the industry is "find somebody who's good at X". It's not a necessary or even optimal requirement. Common Lisp doesn't have too many particularly odd language features; I'd say learning the Rust borrow checker or Scheme's call/cc is more difficult than anything Lisp has to offer. What organizations need to do is prepare to let smart engineers self-train on…

> Perhaps counterintuitively, the hardest people to teach Common Lisp to in my experience have been "senior software engineers" who transition into the project, who are so dead-set on their preferred languages and tools

That's essentially my experience. There is something about developers... they learn a new language but most people never really learn a new way of thinking.

I worked with one guy who tried to learn Common Lisp and even after a year on the project his code was essentially Java written in Lisp.

But this isn't really a problem with Lisp, specifically. I had the same problem with pretty much every programming language. Just recently I had fun debating the usefulness of Kotlin as a programming language. In my experience, for all the features Kotlin has, every single Kotlin program I have ever seen looks like a Java program translated line by line to Kotlin. Which is to say none of the Kotlin features are actually used to solve any important problems like reducing complexity of the application.

> Common Lisp doesn't have too many particularly odd language features;

I would say for most developers I worked with the biggest challenge was always getting the idea of macros. There is technically no reason to use macros. But if you do not use macros you are not really programming Lisp.

The point of macros is the reversal of the programming process. In a regular programming language, you get a bunch of tools and then you learn the tools and then you figure out how to write program using the tools.

In Lisp, you figure out how you want your program to be written, and then make tools that make it possible. It is quite a big shift in thinking that many people have trouble with.

Once I got this, I am now using similar technique in other programming languages. I am looking at my problem and extracting the core complexity and try to figure out what would be the best way to write that complexity down as code. Then I figure out all the machinery to make it happen. It not as elegant as in lisp but it still leads to way better and more readable code at least where it matters.

Re: SBCL: The Assembly Code Breadboard

#14

Post by jlarocco »

A "real life" example of this can be found in the Ironclad cryptography library [0]. It uses this to add support for AES instructions and some other niche assembly instructions to generate fast (at least a lot faster than it would have been) cryptography code.

https://github.com/sharplispers/ironclad/blob/master/src/opt...

Re: SBCL: The Assembly Code Breadboard

#15

Post by [deleted] »

onetimeuse92304 wrote: post #13
reikonomusha wrote: post #8

Earlier quoted context omitted.

Very cool story; thanks for sharing! I think a major fault in the industry is "find somebody who's good at X". It's not a necessary or even optimal requirement. Common Lisp doesn't have too many particularly odd language features; I'd say learning the Rust borrow checker or Scheme's call/cc is more difficult than anything Lisp has to offer. What organizations need to do is prepare to let smart engineers self-train on…

> Perhaps counterintuitively, the hardest people to teach Common Lisp to in my experience have been "senior software engineers" who transition into the project, who are so dead-set on their preferred languages and tools That's essentially my experience. There is something about developers... they learn a new language but most people never really learn a new way of thinking. I worked with one guy who tried to learn Co…

[deleted]

Re: SBCL: The Assembly Code Breadboard

#16

Post by onetimeuse92304 »

reikonomusha wrote: post #9
guenthert wrote: post #7

Earlier quoted context omitted.

> The sad part is that it was impossible to get anybody else working on it and I had to rewrite it in Java (and destroy performance in the process). Java has a CFFI and while it ain't pretty, I don't see where the performance impact would come from, when machine code is to be injected and the critical path is in machine code / C. > extremely low level (like understand what the CPU does when it gets an instruction) as…

I can't speak for onetimeuse92304, but it's probably because the program which generates machine code was in Common Lisp and SBCL using the techniques FTA, and it would basically be impossible to port in any reasonable way. Experimenting with and deploying assembly code generation in SBCL is very organized and flexible—much better in Lisp than in C even.

Technically, you can write a compiler in any programming language. So yeah, you can do it in Java, too. But why if Lisp already has a compiler built in that you can use for the advantage. That's pretty much the idea.

I also happen to know Java (almost 20 years of experience with it).

The point of rewriting it to Java wasn't just the Common Lisp. Compiling and injecting code into high throughput, live, mission critical application proved to be too much of a challenge for developers we tried to hire. Even if I rewrote this for Java (which I absolutely had no intention of doing) the problem would still persist. Most Java devs have even worse understanding of the low level operations than Common Lisp.

Re: SBCL: The Assembly Code Breadboard

#17

Post by dan-robertson »

onetimeuse92304 wrote: post #2

I used SBCL for an algorithmic trading framework for EXACTLY this reason. More precisely, this was SBCL/ANSI C application where most of the application was implemented in Common Lisp, some OS / low level stuff was written in ANSI C and same things were written in Lisp to compile to machine code and inserted into "C world". There would be no Common Lisp virtual machine on the critical, low latency path. Instead, the…

What does “destroy performance in the process” mean? Was the performance being destroyed the performance of something that needed to be fast?

Re: SBCL: The Assembly Code Breadboard

#19

Post by Archit3ch »

epgui wrote: post #4
chrsig wrote: post #3

> SBCL has definitely proven itself to be a good companion to explore the generation of domain-specific machine code. I don’t know of any other language implementation with that kind of support for interactive programming and machine code generation (and inspection). FWIW, I believe LuaJIT + dynasm will soon be comparable. Julia! It's very lispy, actually, but it does a very good job of exposing different layers of p…

I really don't understand what would make someone say that Julia is lispy. People say that about R as well, but I don't see that either. To me, lisp is many things, but the first thing it is is s-expressions. Most/many languages have macros. Lisp is just particularly good at those...

From the Julia side, Common Lisp [0] feels like writing Julia. Both the code itself and the development experience.

[0] https://youtu.be/y5Rn41fPIuQ

Re: SBCL: The Assembly Code Breadboard

#20

Post by duudhwbwka »

onetimeuse92304 wrote: post #2

I used SBCL for an algorithmic trading framework for EXACTLY this reason. More precisely, this was SBCL/ANSI C application where most of the application was implemented in Common Lisp, some OS / low level stuff was written in ANSI C and same things were written in Lisp to compile to machine code and inserted into "C world". There would be no Common Lisp virtual machine on the critical, low latency path. Instead, the…

Bravo
Post reply on HN