Raph Levien

Author Raphlinus has an incredible history of great, superb technical posts here, many which have spawned great discussions[1].

Referenced in this article are: Xi-Editor, discussed in Xi-Editor Retrospective[2] and Druid, discussed in Rust 2021: GUI[3], which follows closely after Principled Reactive UI[4] (describing a prototype for Druid called Crochet).

> I have long believed that it is possible to find an architecture for UI well suited to implementation in Rust, but my previous attempts (including the current Druid architecture) have all been flawed.

These have all been very very good & technical posts on what toolkits really support & enable ui (amid other great technical topics too). It's delightful seeing such an ongoing continuation, an evolcing refinememt of ideas & self-review from someone of such expert caliber.

Rarely do we get such an intimate view into what the real hunt for rightness is, see how we ever hunt for perfection. Personally I believe that hunt for better is one of the undertold aspects of hackerdom, a less visible less knowable reciprocal to fast-and-dirty. Tapping & enabling this creative, knowledge & intellect based capability is a core spring from where greatness emerges.

> I have studied a range of other Rust UI projects and don’t feel that any of those have suitable architecture either.

It's also notable how widely raphlinus travels to get the best persepctive available. This post begins with a a vast field survey of other ui libraries &…

To be clear before I respond, I believe there were some overzealous individuals that were concerned about unsafe usage in the project and did a very poor job of communicating with the maintainer. This follow up post drives at the heart of that: https://raphlinus.github.io/rust/2020/01/18/soundness-pledge.html

Now to your question. Rust is a language that allows you to express correct programs in a number of contexts. Memory safety and concurrent modification free code being two chief ones. What people are constantly proving is that unsafe escape hatches for performance reasons are not as regularly required as similar C implementations would make you believe.

In games and HFT, I would argue having correct programs is as important as any other area of development. That’s the gamble, that you no longer need to make the trade off of safety vs. correctness. But, for expediency of development I could understand why folks see this as a trade off that is required, but that’s really just about the maturity of the language ecosystem in those areas.

Ideally any unsafe code will be contained inside a crate and never be exposed to users of that crate. The crate says “I’m giving you these safe APIs and if you use them, then your code will be safe”, it’s a contract. The point being, for games and HFT, there are many cases where you’re interacting with hardware to improve performance, the big question then becomes, can those hardware abstractions offer safe APIs such that any code built…

I think architecture specific stuff is at best tedious and at worst boring - the general practice is: given some embarrassingly parallel algorithm, implement with the architecture-specific operations. google, read manuals, benchmark, and find out if your implementation is better/worse than sequential evaluation. You generally need the sequential fallback if the size of the input data set is not an integer multiple of the target SIMD lane width which is (usually) fixed and smaller than your data set. If it's bigger you just pad with garbage and move on with your life.

The more interesting problem is converting from non-embarrassingly (impressively?) parallel algorithm to an embarrassing one.

For that there are some standard tricks. Most are based on some theory. The first and very effective one is based on some abstract algebra: given a set of values A, define an operation * that is associative (for x,y in A, x * y = y * x) and commutative ((x * y) * z = x * (y * z)). Then define some unit value in A such that u * x == x. The existence of a binary associative operator and unit value is called a "monoid"

If your algorithm can be formulated as follows :

y[0] = x[0]
y[1] = x[0] * x[1]
y[2] = x[0] * x[1] * x[2]
...
y[N-1] = x[0] * ...* x[N-1]

Then you can recognize this as prefix sum (1) and convert to SIMD over N lanes using any of the standard decompositions. This is based on exploiting the algebraic properties of the operation * to reorder instances.…

> Where are you getting those numbers? I think situation is much more complicated, than your give it credit.

I explained this upthread.

Glibc apparently supports 4 distinct subsets of extensions for x64 according to this article about them removing a 5th one: https://www.phoronix.com/scan.php?page=news_item&px=Glibc-Dropping-SSSE3-Paths

Most code isn't glibc and would be fine supporting just 2 distinct subsets of SIMD extensions for x64.

> See https://raphlinus.github.io/rust/simd/2018/10/19/fearless-simd.html

I haven't looked into these Rust SIMD libraries much, but it sounds like they are doing worthwhile things. In 2022 you can also use Google's Highway if you are able to integrate template spaghetti into your code, but it's understandable if one cannot do this.

> It's still dropping down to assembly and having to worry about arcane details like endianess and byte alignment.

You don't have to write assembly. In Zig, you can just use binary and unary operators on vectors and get new vectors without using any intrinsics, but you'll still need to use more than 0 intrinsics for string parsing because you probably want pshufb. In the case of pshufb specifically, and this is representative of most of this stuff, the entirety of the complexity that you pay for having one AVX2 target and one SSE4.1 target is that the SSE4.1 target needs to get by with a half-as-wide pshufb. One way to do that (which might not be the best for all uses of pshufb on the SSE4.1 target) would…

I found the discussion on extensibility vs composability to be really fascinating. The author is right that extensibility gives you less freedom between tools. You can't take magit to vim or helix, because it is an Emacs extension. And each tool has it's own way of extending it, which means you need to learn essentially a new API (if not an entire language) to extend a tool.

However extensibility makes it much easier to move within a tool. The authors sample kakoune config for doing splits is a great example. Since Kak doesn't support splits natively, you have to learn 3 separate tools do the spliting in a WM. In something like Emacs there is only one thing to learn to manage splits on all platforms. And it is using the same extension mechanisms you use for everything else.

I found this the paragraph just before the conclusion to kind of an interesting demonstration of these trade-offs:

> All of that to say that, the take of Helix is pretty good here, because all of those UNIX problems are not there in that editor: everything runs in the same process, inside the same memory region.

The author spends a lot of time praising composability over extensibility, but then admits that Helix has some real advantages because it is not composed with tree-sitter or lsp, it has those built in. Essentially it was extended with those features, they become part of editor, instead of trying to interacte with them in a uniform way.

This reminded me of the xi-retrospective section[1] on…

It sounds like you've got something specific in mind when you say, "modeling". The term modeling is used in a lot of different situations to mean different things. For example, it could mean to make a 3d model in Blender, it could mean to pose for someone to paint you or to take a photo, with databases it's used to mean modeling the data, with statistics it's used to mean finding a way to simply represent and reason about the data (create a model of it).

The things you've listed out make me guess you want to write 2d or 3d image rendering software. Is that right?

If that's the case, there's no substitute for trying to recreate certain algorithms or curves using a language or tool that you're comfortable with. It'll help you build an intuition about how the mathematical object behaves and what problems it solves (and doesn't). All of these approaches were created to solve problems, understanding the theory of it doesn't quite get you there. If you don't have a good place to try out functions, I recommend https://thebookofshaders.com/05/ , https://www.desmos.com/calculator , or https://www.geogebra.org/calculator .

A good place to start is linear interpolation (lerp). It seems dead simple, but it's used extensively to blend two things together (say positions or colors) and the other things you listed are mostly fancier things built on top of linear interpolation.

https://en.wikipedia.org/wiki/Linear_interpolation

For bezier curves and surfaces here are some links I've…