zackoverflow

This is kinda possible already today with the Kitty graphics protocol, I made a demo here of rendering 3D graphics[1] with kitty. The actual important missing thing (and which ratty seems to also not include) is vsync.

If rendering is not aligned then it's possible for the terminal emulator to read the framebuffer while the application is writing to it, causing visual artifacts.

[1] https://x.com/zack_overflow/status/2035921425341763756?s=20

I recently came across this style of interpreter which V8 and HotSpot use. It works by actually writing the bytecode op handlers in assembly (or some other low-level language) and generating them to machine code, and having a dispatch table mapping bytecode_opcode -> machine code to execute it

I was pretty intrigued. How does it compare to techniques which require way less engineering cost like switch+loop, direct-threaded, and only using tail-calls (https://blog.reverberate.org/2021/04/21/musttail-efficient-i...)?

The main reason seemed to be that both V8 and HotSpot have an optimizing JIT compiler, and having low-level control over the machine code of the interpreter means it can be designed to efficiently hop in and out of JIT'ed code (aka on-stack replacement). For example, V8's template interpreter intentionally shares the same ABI as it's JIT'ed code, meaning hopping into JIT'ed code is a single jmp instruction.

Anyway, I go into more implementation details and I also built a template interpreter based on HotSpot's design and benchmarked it against other techniques.

> Note that the context pointer came after the “standard” arguments. All things being equal, “extra” arguments should go after standard ones. But don’t sweat it! In the most common calling conventions this allows stub implementations to be merely an unconditional jump.

I didn't know this. Does this optimization have a name? Where can I read more about it?

Does anyone have any insight on why the PikeVM implementation is slower (it's based on the VM approach described here https://swtch.com/~rsc/regexp/regexp2.html)

I feel like compiling regex to bytecode and executing it should be faster than dealing with big graph like structures with NFAs/DFAs

Also, V8's regex engines are very fast because they get JIT compiled to machine code, so wouldn't bytecode just be one step higher in abstraction, and have worse but similar performance?

Most of the time you don't need to do this, usually its the solution for when creating a graph structure with cyclic references.

But when you do, and your data is mutable, generational indices are a legit and very useful strategy that is used in C/C++ too.

See this: https://floooh.github.io/2018/06/17/handles-vs-pointers.html

Hey HN, I got inspired by a recent hack someone did of creating flappy bird in MacOS Finder, so I tried to do the same with type-level Typescript.

If you don't know, Typescript's type annotations are Turing complete, allowing you to compute anything with some clever type trickery.

In order to render graphics from Typescript's types, I ended up creating a compiler that compiles Typescript's types into bytecode, and a custom VM that can execute that bytecode.

Each frame, the VM takes draw commands from type-level Typescript, and renders it using the configured graphics backend. It can run in the browser by compiling the VM to Wasm and using the web's Canvas API.

I don't do anything related to data science, but I feel like doing it in Rust would be nice.

You get operator overloading, so you can have ergonomic matrix operations that are typed also. Processing data on the CPU is fast, and crates like https://github.com/EmbarkStudios/rust-gpu make it very ergonomic to leverage the GPU.

I like this library for creating typed coordinate spaces for graphics programming (https://github.com/servo/euclid), I imagine something similar could be done to create refined types for matrices so you don't do matrix multiplication matrices of invalid sizes

> These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics.

I agree that this is mostly true, but maybe not for beginners in the field

When I was reading "Raytracing in One Weekend" (known as _the_ introductory literature on the topic), I was very surprised to see that the author designed the code so objects extend a `Hittable` class and the critical ray-intersection function `hit` is dynamically dispatched through the `virtual` keyword and thus suffers a huge performance penalty

This is the hottest code path in the program, and a ray-tracer is certainly performance critical, but the author is instructing students/readers to use this "clean code" principle and it drastically slows down the program.

So I agree most computer graphics programmers aren't writing "clean code", but I think a lot of new programmers are being taught them because of introductory literature

Can you elaborate more about the guarantees about no waste?

Can you explain why they're more complex? I've always heard the narrative that OT is harder to get right because of edge case

Interesting that the wiki says that the performance enhancing effect comes from a lower heart rate, which is something you can influence with practice.

You can lower your resting heart rate naturally through exercise over time, and meditation and breathing techniques with practice give you control of your heart rate in the moment.

The active ingredient acetaminophen is anti-inflammatory which is where the reduced anxiety effects come from, perhaps you're not suffering from inflammation enough for it to take effect

I haven't played much with live IO with ffmpeg. Tell me more about the difficulties of this usecase, I'd love to make it a better experience