Bit-twiddling optimizations in Zed's Rope

Post by erk__ » Thu, Nov 21, 2024, 8:31 AM UTC

karthink wrote: post #18

rgrmrts wrote: post #14

Earlier quoted context omitted.

Yeah this is one reason, or Emacs freezing for up to a minute when updating packages. Also when using an LSP I notice latency. I use Emacs GUI (outside of the terminal) and comparing performance for rending to something like Zed or Sublime is definitely noticeable. It’s great that Emacs is so resource efficient but sometimes I wish it used more of my beefy computer(s). Like I said I still love Emacs and it’s okay for…

Removing the interpreter lock for a few specialized tasks (without sweeping runtime changes to Emacs) would be enough to fix most of these issues -- parsing JSON from process output into lisp data in a background thread is one candidate. [1] Installing packages does not need to block either, there is no architectural limitation here. The Elpaca package manager for Emacs provides async, parallel package updates. Loadi…

Post by SuchAnonMuchWow » Thu, Nov 21, 2024, 11:32 AM UTC

akoboldfrying wrote: post #4

dmitrygr wrote: post #3

> // Parallel bit count intermediates > let a = v - ((v >> 1) & (u64::MAX / 3)); > let b = (a & (u64::MAX / 5)) + ((a >> 2) & (u64::MAX / 5)); > let c = (b + (b >> 4)) & (u64::MAX / 0x11); > let d = (c + (c >> 8)) & (u64::MAX / 0x101); That "parallel bit count" is almost certainly slower than using two POPCNT instructions on a modern cpu. Should just call __builtin_popcount() and let the compiler do it the most optim…

Which compilers support __builtin_popcount()? From memory, it's a gcc extension. If the compiler selects a CPU POPCOUNT instruction for it, are you sure it will work on all machines that you want to run it on? The above code is completely source- and binary-portable and reasonably fast -- certainly faster than naively looping through the bits, and within a small constant factor of a CPU POPCOUNT instruction.

Post by eliasson » Thu, Nov 21, 2024, 12:00 PM UTC

Post by ku1ik » Thu, Nov 21, 2024, 4:57 PM UTC

kevin_thibedeau wrote: post #35

seanw444 wrote: post #7

Earlier quoted context omitted.

> it does not take full advantage of how good computers are today, e.g. gpu rendering or multicore Why does Emacs need that though? I hear people say this all the time and I don't get it. Multicore kind of works against the structure that Emacs touts as a feature. And GPU rendering? In many applications, I totally agree with these complaints. But it's a text editor. I tried Zed myself, and it's good. But it doesn't d…

GPU rendering simplifies smooth text scrolling which used to be a thing on some dumb terminals and microcomputers like Amiga that supported it in hardware. Most emulators are locking character cells on a fixed grid and we miss out on such niceties.

Post by Validark » Thu, Nov 21, 2024, 5:02 PM UTC

akoboldfrying wrote: post #4

dmitrygr wrote: post #3

> // Parallel bit count intermediates > let a = v - ((v >> 1) & (u64::MAX / 3)); > let b = (a & (u64::MAX / 5)) + ((a >> 2) & (u64::MAX / 5)); > let c = (b + (b >> 4)) & (u64::MAX / 0x11); > let d = (c + (c >> 8)) & (u64::MAX / 0x101); That "parallel bit count" is almost certainly slower than using two POPCNT instructions on a modern cpu. Should just call __builtin_popcount() and let the compiler do it the most optim…

Which compilers support __builtin_popcount()? From memory, it's a gcc extension. If the compiler selects a CPU POPCOUNT instruction for it, are you sure it will work on all machines that you want to run it on? The above code is completely source- and binary-portable and reasonably fast -- certainly faster than naively looping through the bits, and within a small constant factor of a CPU POPCOUNT instruction.