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

Steel Bank Common Lisp version 2.6.7

sbcl.org

Post reply on HN
Print view View original

101–110 of 172 posts

Re: Steel Bank Common Lisp version 2.6.7

#101

Post by peri-cl »

wk_end wrote: post #3

* the SB-SIMD contrib now supports ARM64. (Thanks to Sylvia Harrington) * AVX512 instructions are now supported on X86-64. (Thanks to Robert Smith and Arthur Miller) * additional support for SIMD instructions on ARM64 and X86-64. (Thanks to Arthur Miller) These seem like pretty awesome additions. Does anyone know how SIMD works in SBCL? Is this at the codegen layer? i.e. can it auto-vectorize or anything like that? O…

> "AVX512 instructions are now supported on X86-64"

This is the first news I've seen on HN in weeks that I am genuinely excited about! I have several AVX-2 hobby projects in Common Lisp, and an AVX-512 machine. It's an unexpected surprise to read this morning that this very useful ISA is suddenly unlocked. I'll be trying it out right away.

(edit: Looks like they mean *compiler* support for AVX-512, but not SB-SIMD definitions (yet). So I believe the only way for end-users to call AVX-512 instructions right now is to write custom VOP's).

> "Or are these intrinsics you have to explicitly ask for?"

There are language SIMD types and you explicitly use SIMD functions that operate on them. I believe it's essentially the same idea as C intrinsics. You can for example write (interactively)

    (u32.8+ (make-u32.8 0 1 2 3 4 5 6 7)
            (u32.8 10))

    ;; => #
And that's VPADDD under the hood. Or reading an array

    (loop with sum = (f32.8 0.0f0)
          for index below (* 8 (floor length 8)) by 8
          do (setq sum (f32.8+ (f32.8-aref array index)
                               sum))
          finally (return sum))
which compiles down to a small loop around the vector insts

    VMOVUPS YMM1, [RDX+RCX*2+1]
    VADDPS YMM0, YMM1, YMM0
I much prefer it to writing intrinsics in C (and the results are just as good). It's an interactive, exploratory, coding: I write small modular functions, SBCL compiles them on the fly, I glue them together with high-level language constructs.

Re: Steel Bank Common Lisp version 2.6.7

#102

Post by sph »

baq wrote: post #12

I wonder sometimes how the world would look like if lisp won and the unit of deployment was a lisp machine image, if that makes sense. How would a kubernetes optimized for lisp look like? How would AWS EC2 look like? etc.

> How would a kubernetes optimized for lisp look like

I imagine it would look a bit like Erlang's BEAM. No need to stop and start the application, but write a script to do hot updates of a live image.

Re: Steel Bank Common Lisp version 2.6.7

#103

Post by Jach »

HexDecOctBin wrote: post #88
stackghost wrote: post #20

Earlier quoted context omitted.

Yeah I'm not sure why it's not in the manual, as it's had arena allocation support since at least 2.4.x, but basically: - use SB-VM:NEW-ARENA to make a new arena - use SB-VM:WITH-ARENA to redirect ordinary allocation into an existing arena like you would use WITH-OPEN-FILE or similar macros The only real doc is this internals note, and it doesn't even cover NEW-ARENA which I guess is left as an exercise to the reader…

Yeah, but I am guessing one needs a bit more info on how this works together with GC. For example, once an arena goes out of scope, what happens to allocations made inside it that have been returned and thus are referred to from outside that scope? Are they copied out or do we have a dangling pointer? Stuff like this needs some decent documentation in order to be able to use a low level feature like this properly.

Indeed. The behavior of arenas shared by multiple threads is important as well, and the proper use of destroy-arena vs. rewind-arena. Without care it's easy to create a leak in the unmanaged memory and the OOM Killer will come for your process eventually.

Re: Steel Bank Common Lisp version 2.6.7

#104

Post by epolanski »

iLemming wrote: post #65
epolanski wrote: post #41

Earlier quoted context omitted.

Further confirming my point on why it is the only lisp with some genuine traction out there.

I think you have very little insight to what you're talking about. The modern Lisp landscape is nothing like what it was in the 90s or even 2000s. The amount of practical shit Lispers been quietly building these days is genuinely impressive. Have you ever seen GitHub language stats? Elisp there in the list a few points behind Lua, Elixir, OCaml and Haskell. The amount of Emacs Lisp on GitHub alone should be at least…

It's mostly hobbyism.

My point stands.

Re: Steel Bank Common Lisp version 2.6.7

#105

Post by johnlorentzson »

Scarblac wrote: post #97
pfdietz wrote: post #31

Earlier quoted context omitted.

Image saving isn't something that's done very often, in practice.

What is done in practice, for daily development use? Building the image in memory from source files at startup?

Typically, for development, one will start a clean image in the morning and load it up with a combination of newly compiled code and automatically cached previously compiled code. This is mostly invisible to the user unless something goes wrong with the cache and it has to be cleared. The unaware user could think they're recompiling everything every time.

Re: Steel Bank Common Lisp version 2.6.7

#106

Post by p_l »

guenthert wrote: post #98
p_l wrote: post #52

Earlier quoted context omitted.

There's another wordplay in the name. Namely, that "SB" stands for "Sanely Bootstrappable" - something that the CMU Common Lisp was unable to do

It is my understanding that easing bootstrap was the original motivation of the fork of CMU CL. I'm a bit confused about that, since CMU CL supports compilation to byte-code (which should make a port to a new architecture comparatively easy), a feature which was dropped in SBCL.

The sane bootstrap is not about porting to new architecture, but about building the compiler from source in the first place. CMU CL effectively requires that you use the same version of CMU CL to build it, IIRC, which in practice meant you had to first load the changes into older CMU CL image - overwriting core components, and then use that image to compile new version.

The difference with SBCL is that it can compile so long as you have any CL implementation that handles certain broad, but not complete, subset of ANSI CL.

It does it by being able to compile itself in sort-of sandboxed state hosted within another CL image, and then using that compiler to build itself, without requiring to modify the host compiler like CMU

As for the bytecode, as far as I recall CMU CL did not have bytecode compiler at all - it had evaluator option, which was indeed dropped for a long time from SBCL but was recently reintroduced, partially to support efforts such as porting Kandria [1] to Nintendo Switch

[1] https://kandria.com/

Re: Steel Bank Common Lisp version 2.6.7

#107

Post by p_l »

srparish wrote: post #76
NeutralForest wrote: post #5

Great to see the project is still going strong, I kinda want to try CL but I always feel like I don't have a great use-case.

An extensible LLM agent (such as https://pi.dev/ or maybe hermes) written in common lisp could be interesting. Conditions and restarts and general debugging and repair of the live system, fast startup, native execution speeds, ability to add or replace or modify core functionality on the fly, solid multi-threading support, dynamic introspection including documentation, CLOS and multiple dispatch, saved images.

Behold! https://www.lambda-symbolics.com/autolith

Not mine, but interesting.

Re: Steel Bank Common Lisp version 2.6.7

#108

Post by SeanLuke »

OuterVale wrote: post #83

Steel Bank Common Lisp is what Hacker News uses. https://news.ycombinator.com/item?id=44099006 I discovered this while doing some research for a post the other day: https://vale.rocks/posts/hacker-news

I recall HN originally using Arc. Is there a history available regarding its development and redevelopment?

Re: Steel Bank Common Lisp version 2.6.7

#109

Post by mfru »

nesarkvechnep wrote: post #91
GeorgeTirebiter wrote: post #89

Earlier quoted context omitted.

I bet you do, or you will. In my case, I had been getting movie recommendations from friends and also randomly. I'd look up the flick on IMDB, metacritic, and rotten tomatoes and I'd guess whether I would like it. I wanted something more 'algorithmic' - and more accurate. So me and Claude build an sbcl-based Film Recommendation system. Type in a new film name, it goes to open film database OMDB, grabs the scores, and…

But then again, why would I use CL for this when I can use Elixir? I’m not the original commenter but I too can’t find a use case for CL.

Well, why use Elixir if I can use Clojure/Python/Ruby/Go?

Re: Steel Bank Common Lisp version 2.6.7

#110

Post by maleldil »

SeanLuke wrote: post #108
OuterVale wrote: post #83

Steel Bank Common Lisp is what Hacker News uses. https://news.ycombinator.com/item?id=44099006 I discovered this while doing some research for a post the other day: https://vale.rocks/posts/hacker-news

I recall HN originally using Arc. Is there a history available regarding its development and redevelopment?

It still uses Arc. The original implementation was written in Racket, then rewritten in Common Lisp and run on SBCL.
Post reply on HN