back
user profile
raphlinus
13,685karma·1,846submissions·March 7, 2014
about
I do research on fundamental UI technology and 2D graphics, with a focus on Rust and fonts.
@raph@mastodon.online
recent activity (1,846 total)
comment
1. This is going to depend a lot on the app; doing an actual DAW is going to require some pretty heavy processing. It also depends on the performance goal. Truly pro audio would be a 10ms end-to-end l…
comment
I think things will get a lot better when the underlying enabling technology is in good shape. The audio engine needs to be running in a real-time thread, with all communication with the rest of the w…
comment
You don't need to convince me, but you'd be surprised some of the pushback I've gotten[0]. I don't have a lot of experience with GIS, but you're telling me that a linear scan …
comment
Looks pretty neat, thanks for the link. From a quick look, it seems like the performance characteristics will be pretty similar to a xi-style rope (it seems extremely unlikely to me that the time spen…
comment
If you really want to solve the problem, use a rope. The advantage of gap buffers is simplicity (accounting for the gap is a simple compare with a couple of numbers). Ropes are definitely more complic…
comment
The first part of the article is true; gap buffers are not a data structure particularly optimized for multiple cursor edits. The conclusion is ridiculous. Of course you can provoke noticeable slowdow…
comment
It's fine for a monospaced font to contain an "fi" ligature (to represent Unicode U+FB01), but it absolutely should not contain a "liga" feature to form it from "f" …
comment
Oops, yes, you're correct, I was typing from memory and didn't double-check. And yes, the Taylor series is pretty good but you can usually squeeze a bit more accuracy-over-range by, eg, usin…
comment
A bit OT but my favorite way to approximate tanh is to do g(f(x)) where f(x) is an odd polynomial and g(x) is 1/sqrt(1 + x^2). The recip sqrt can be computed very quickly using Newton approximati…
comment
Also not C, but closer: https://docs.rs/xi-rope/0.2.0/xi_rope/ This is a rope implementation in Rust with lots of features useful for text editors.…
comment
Graph isomorphism is a known NP-hard problem, but the vast majority of subgraphs in programs are reducible, so I expect that aligning two control flow graphs admits a good heuristic solution.
comment
Tada! That's very close to what I had in mind. The only difference: you can fizz on 4924, buzz on 4210, none on 34cb, then always \n. Also, you have 3 ops to calculate the rotation, and that can …
comment
Good candidate for most evil use of the assumption that char is signed. Incidentally, that's not going to be true on arm[0]. [0]: http://blog.cdleary.com/2012/11/arm-cha…
comment
Indeed, llvm is smart enough not to use a DIV instruction for modulo of a constant. Turns out you can compute x%3 == 0 with even fewer steps, it's (x*0xaaaaaaaab) < 0x55555556 (assuming wrappi…
comment
You're absolutely on the right track with a (wrapping) multiply and a shift right, but the constants aren't quite right.
comment
I see your point regarding pure cycle counting, but as I posed the puzzle it's still open :)
comment
I see your points; maybe I need to work on the storytelling in posing the puzzle. I do stand by the principle that avoiding branch mispredicts is worthwhile if you can replace the branch with 1 or 2 l…
comment
This is true, and I've thought about it a bit. If you were really optimizing, then maybe the goal would be stated as putting the completed answer into a memory buffer. But for now, shave as man…
comment
I should have stated extra constraints; you're not allowed to use either additional memory (memory accesses are slow) or an if statement to update your state (branch mispredicts are slow). Yes, t…
comment
I've just recently switched over to it for my day to day work. Admittedly there are rough edges, but I think it's fair to call it viable for sufficiently small values of viable. I expect to …
comment
Apologies if this is somewhat off-topic for the thread, but I suspect this will be a fun puzzle for fans of low-level optimization. The theme is "optimized fizzbuzz". The classic fizzbuzz wi…
comment
1. If you're using an Electron-based editor, I imagine you might not be entirely happy with performance. I can fix that. 2. Yes, have looked at Kakoune, and even have some plans to emulate its ke…
comment
The thoughts on commercialization are a hypothetical. As I said in my original comment, it's off the table (though I gave other reasons than being employed by Google). I'm just saying that …
comment
Right, I didn't write clearly. After a couple months of pushing to a 1.0, I'd expect maybe a few thousand users (this seems reasonable to me because it's the number of github stars). Th…
comment
A) I'll toss out 1M because you asked for a number. B) Because if I build out my full ambition, it would be better by most objective metrics (speed, features, integration with IDE-like capabiliti…
comment
I have a largish open-source portfolio, including a markdown parser, a regex engine, some music synthesis, and some more researchy stuff like a font renderer and a prototype of concurrent text editing…
comment
The Friendly C idea seems to be basically dead. For an update of what Regehr is pursuing now, see https://blog.regehr.org/archives/1520 (Undefined Behavior in 2017).…
comment
This is a really good question. Each language adopts its own philosophical stance on the matter. Java is an excellent example of a language that tries to minimize undefined behavior, as much as C maxi…
comment
This is excellent and I have no idea why the 5 or so previous submissions failed to gain any traction. The topic is fascinating, and the style of presentation (video coordinated with interactive 2D an…
comment
This has been discussed quite a bit, and there are very good reasons why not[0]. But I suppose things can always change. [0]: https://internals.rust-lang.org/t/crates-io-package-p…