hayley-patton

Sledgehammering a little TV was done in the video for Gary Numan - We Are Glass which predates the 1984 ad, which supposedly led to the video being banned from Top of the Pops: https://www.youtube.com/watch?v=KWR8vitO6wQ&t=67

The typical consumer isn't empowered to modify or write a program, so why would they entertain the idea?

> It can be optimized away by a compiler to just fixed integers, sometimes

Yep, SBCL does range analysis and can do inline fixnum or unboxed arithmetic.

SBCL eval interprets until you hit a lambda form, at which point it will compile (last I checked). But you are much more correct than who you replied to :)

RISC more accurately stands for "load-store architecture", which is very odd because RISC has four letters and there are only three words in load-store architecture.

There's work on porting MMTk to Julia, which will provide some well written GCs: https://github.com/mmtk/mmtk-julia

Smalltalk was named such as Alan Kay (https://wiki.squeak.org/squeak/50)

> had mentioned to someone that the "prose" of then current programming languages was lower than a cocktail party conversation, and that great progress would have been made if we could even get to the level of making "smalltalk".

> but I find it hard to understand how Common Lisp compilers work – what with their readtables and read macros and normal macros

Read tables and reader macros are used in the reader, which is separate from the compiler. The compiler macroexpands normal macros though.

> what subsets are implemented before the rest

There are no obvious subsets in Common Lisp - see Baker on the matter <https://www.plover.com/~mjd/misc/hbaker-archive/MetaCircular...>.

SBCL is mostly written without CLOS and then brings in a CLOS implementation late into bootstrapping; that of course prevents you from using CLOS in some places, so you may not want to do that though.

> is there any implementation guide on how a Common Lisp is/should be implemented?

You could do a lot better than the existing Common Lisp implementations, especially in compilers and GC, but the issues there are not specific to Common Lisp.

The compiler deals with code in S-expression form, represented as lists and atoms. Reader macros produce Common Lisp objects.

> To optimize this further, you need implementation dependent code and replace abstractions of S-expressions with native machine code

This can be done by a program called a compiler. There are many compilers for Lisp.

(In other words, the same argument applies to every language ever which doesn't exactly correspond to machine code.)

One is parallel, using multiple cores to make collection happen faster, which increases GC throughput and shortens GC pauses. The other is concurrent and avoids pauses entirely, though it requires more bookkeeping from the application and might reduce throughput.

I joke that the parallel GC is bringing SBCL to 2000s Java. It seems comparable enough to Java's Parallel, though SBCL aims for less space overhead by default, so you need to adjust either GC to have a fair comparison. The concurrent one is based off a collector for SML#, Haskell has a similar low latency "Alligator" collector too.

(Disclaimer: I wrote the parallel collector, and I want to be clear that latency and throughput differ here, because someone didn't before.)

> One of them is a parallel collector written by a university student (!!) which blows my mind.

I didn't let schooling interfere with my education.

> So some languages/VMs apparently are more amenable than others.

I thought Self was supposed to be harder to optimise due to using prototypes, accessor methods rather than distinguishing instance variable access, and generally fewer other tricks. Frankly I don't know what the problem is here, but if it was a language issue, then Self should be slower than Smalltalk - you are suggesting that it'd be the other way around, and I don't see why that'd be the case.

Mario Wolczko implemented Smalltalk in Self, yielding a faster Smalltalk than the commercial offerings <http://www.merlintec.com/download/mario.pdf>. The are-we-fast-yet repo has benchmarks for SOMns (SOM modified to run Newspeak, using Truffle for compilation) which outperforms Node <https://github.com/smarr/are-we-fast-yet/blob/master/docs/pe...>.

> Otherwise it's very difficult because a block is just an object and executing it is just a method call on this object via dynamic dispatch; it's not trivial to find out what to inline

We have an object which we know everything about, because we construct it in the method. We know it's a block, and we know what #value will do, which seems like a pretty strong signal to inline. Even without knowing what blocks are, inlining #ifTrue:, #whileTrue: and such is a good move as those methods are very small.

I'm not very good at maths so I let Z3 work out some convenient seeds for me, leading to

    import java.util.Random;
    public class Hayley {
         public static void main(String... args) {
             byte[] b1 = new byte[4], b2 = new byte[2];
             (new Random(0x2effe2140e00L)).nextBytes(b1);
             (new Random(0xc2f0097)).nextBytes(b2);
             System.out.println(new String(b1) + new String(b2));
         }
    }

Self wasn't sufficiently fast? Craig Chambers's compiler [0] had to be careful around recursive inlining* but it's not that bad, and the compiler definitely came around in less than 30 years of Self or Smalltalk existing (even if you start counting from Smalltalk-72).

A sibling comment mentions that Smalltalk-80 played tricks with inlining some block methods such as ifTrue: and whileTrue: in the bytecode, but Self pulled nothing like that.

[0] http://www.wolczko.com/tmp/ChambersThesis.pdf#page=72

*Although maybe too careful - the important parts are that you don't inline forever, so some degree of recursive inlining is okay (and would help in the factorial example), and that you have a good reason to inline.

It's a Smalltalk implementation written in Smalltalk, which is designed to survive its internals modified at runtime, which is the "live" part. The paper exhibits conventionally tricky bits to modify like the garbage collector and compiler, and describes some performance regressions they found which they fixed using the liveliness of the system.

Are they trying to bring back SIMD-within-a-register? Though that only gives you ~one order of magnitude doing packed 4-bit stuff with 64-bit GPRs. And perhaps fixed-point, sign-exponent and posits are unregulated.

What's odd about using vector intrinsics with GC and/or JIT? I did my capstone project for university with intrinsics for SBCL - testing hand-vectorised code at the REPL is rather funny (as it's an interactive environment for almost assembly) but it works fine. So long as you have arrays of integers you can load and store vectors, and the rest is all the same.

C11 has atomics and CAS, is C11 okay?

Looks like it's 10.7 kLOC whereas mimalloc is 8.8 kLOC, so it's not much more complex at that...amount of engineering, I guess. Also spotted that the mimalloc README says

> Free-ing from another thread can now be a single CAS without needing sophisticated coordination between threads

which may not be the worst thing in the world; depends on what your app does.

snmalloc batches up cross-thread frees, though generally any thread-local stuff is better than none.

> The standard library allocator keeps its state in global variables. This makes for a simple interface, but comes with significant performance and complexity costs

Thread local allocation buffers?

> Given that branches are, well, just branches in any language, what makes OO so special?

In principle you have calls to whatever method associated with a given object, which are indirect as there is not one statically-known target of the call, but in practise you can optimise a lot out <https://youtu.be/9epgZ-e6DUU?t=2543>.

If the allocator can't keep up with the code, then maybe the allocator simply is bad?

Rosetta on the M1 enables the total store ordering from x86, which has a stronger memory model than that of ARM. It also can compute the parity flag in hardware <https://bytecellar.com/2022/11/16/a-secret-apple-silicon-ext...>.

You have lighter context switches [0] and finer-grained security domains; consider e.g. passing a pointer versus de/serialising across process boundaries. (The former benefits the latter too, since there's less of a performance cost to cutting up software into more domains.)

[0] https://www.microsoft.com/en-us/research/publication/deconst...

WASIX?

Properties assigned to things which cannot have those properties. "Colourless green ideas sleep furiously" has many such errors for example.

If you insist.

"interpreted language" and "compiled language" are category errors.