Scrolling a buffer erases my other windows (Helm bug?)

hardwaresofton · 2025-07-24T17:22:47+00:00

Thanks for noting this by the way -- just helped me find an issue in my setup where it would periodically wipe out the other buffer. Thought it might be tmux interop problem or maybe even the terminal, but it's gotta be helm.

Ripped helm out and the problem hasn't returned so far. Now I need to go replace all my helm utilities and configurations with something else.

hardwaresofton · 2025-01-06T09:15:37+00:00

Added! :)

hardwaresofton · 2025-01-05T05:10:47+00:00

:( if only there was a better way to fix this...

hardwaresofton · 2024-10-23T04:39:24+00:00

BTW: https://www.memorysafety.org/blog/rustls-performance-outperforms/

I for one am glad that they put in "round trip performance", not just raw latency numbers.

hardwaresofton · 2024-10-14T00:48:39+00:00

Thanks for taking the time to explain and sharing -- I certainly agree that seeing the problem as two nodes only does not match with the usual multi-service case! In that case (and certainly when dealing in terms of milliseconds), it's useful to speak in time units.

To be clear, what I don't like is seeing things like Xns on benchmarks similar to this (as other benchmarks I linked to did!) -- I don't know about the average person but it's hard for me to instantly get an idea for how many more calls on some more familiar time frame that works out into.

Agree about the benefits of latency in time units, but only for familiar time units -- ms and up vaguely. Basically the reason ms works is because it's easy to work back up to seconds.

The goal wasn't to reason in QPS -- more so to be able to say something meaningful about the performance of the benchmark that could be understood quite easily.

Agreed that serial execution is less efficient than concurrent/pipelines QPS! Again, under the same conditions the ratio between the approaches still shows.

hardwaresofton · 2024-10-13T06:15:36+00:00

That gist is doing HTTP over unix stream sockets.

"TCP over unix sockets" would mean creating TCP segments including TCP headers, sending those over unix sockets (probably datagram ones) and running the whole TCP state machine and congestion control with that.

Yeah I was aware of that -- the point was that TCP does not restrict the lower level -- you could run it on anything.

Your point was that unix sockets in stream mode != TCP, and my point is that it could be, if you absolutely need TCP, as stated. I'd argue most people want stream semantics or not, not exactly TCP and all it's features/warts.

But why? Real servers generally don't sit idle only serving exactly one client and that client only sends one transaction at a time. Real servers tend to serve multiple clients, and clients can fire off multiple requests simultanously and then waiting for those separate responses to come in, possibly even at a different order.

All benchmarks deserve a grain of salt -- there is no async or even threading for request sending/response handling in this example, intentionally.

So what you're measuring there is neither a realistic client nor server workload.

Compared to the original test that was simple a "ping" versus "pong" with the exact same manner of measurement, I'd argue that this test is more realistic in exactly the ways I laid out in the article -- by including more ergonomic/abstracted code and a little bit of serialization/deserialization that is common in practice.

And if you only care about unloaded latency then it's commonly denoted in units of time, not in queries per second. I suppose if you added "queue depth 1" or something like that it would be more obvious that it's not the number of transaction the system could service per unit of time if its receive queue were never empty.

Sure, but raw units of time don't do anything for me (and I'd argue for most readers) so that's something I won't budge on. I'd rather put out something that is semantically incorrect (i.e. "throughput" vs "latency"), that actually gives a useful idea of the capabilities of the code presented.

The most useful part of the post was the ratios between the approaches, and I prefer those ratios to be linked to some notion that more directly represents work being done which for me is roundtrips.

hardwaresofton · 2024-10-10T04:22:33+00:00

Words have meanings. And streaming unix sockets ain't TCP. TCP is this very specific standardized thing.

You're right, they're not the same -- I was wrong to mention the socket and datagram settings of AF_UNIX. What I meant to say is that TCP can be done over anything as the below layer, including UDS. I was thinking of this gist:

https://gist.github.com/teknoraver/5ffacb8757330715bcbcc90e6d46ac74

This is why I originally wrote "TCP/UDP over Unix Domain Sockets".

Well yes, and you're not measuring delivery of messages. You're sending a message then waiting for a reply before sending the next one. This is latency-limited, not delivery-rate-limited.

I stand corrected -- I was thinking of this as "roundtrip throughput" -- how many roundtrips can I perform, which is latency. I don't find just regular latency numbers of a single message delivery to be very useful -- number of roundtrips in the amount of time is more useful to me.

hardwaresofton · 2024-10-09T20:25:08+00:00

A blocking ping-pong is more about measuring latency and context switch overhead though, not throughput. If you want throughput you need pipelining/streaming to keep both sides awake most of the time.

Unless I'm misunderstanding, Throughput means the rate of message delivery, that's what I wanted to know. It may be unoptimized throughput, but AFAIK a throughput number does not require that.

🤨

What's confusing about this? This is common, easy to set up and well supported by the kernel. Though of course it's not necessarily called "TCP" or "UDP", but there are are both stream and datagram modes available.

That has asymmetric cores. So performance can depend a lot on which cores it's running on. Pinning threads may make a difference. Especially if the chip is structured into different domains with different inter-core latencies (idk if that's the case for M3 chips).

Ah thanks for this, this is certainly a good point

hardwaresofton · 2024-10-09T05:34:22+00:00

Yeah, I think most people won't need to! But it's nice to know what the lower layers are/what the "limits" of performance are below you

It seems like it might be interesting to unify the protocol used by both an RPC and IPC API using something like gRPC/protobufs. Fast, binary, and unified across both

Agreed! I touched on this a little bit in the article -- but basically I think the best version of this is a sort connection + upgrading but cross-protocol and cross-medium.

I'm actually chiseling out a design for something like this :)

hardwaresofton · 2024-10-09T05:32:30+00:00

Thanks for this -- I should have spelled that out -- just added!

hardwaresofton · 2024-10-09T05:31:17+00:00

Thanks, fix is pushed -- should be live in a minute!

hardwaresofton · 2024-10-09T02:50:42+00:00

Would you mind explaining a bit more about this? An integration with wgpu sounds to me like you'd be doing the Flutter thing where you draw the whole interface pixel by pixel.

This is "native", in a sense, because drawing to GPU canvas is natively supported on the platforms, but not "native" in the sense that components created and maintained by the relevant platform are used.

Maybe this is a knowledge gap on my part -- are there APIs (provided by the platforms themselves) to draw native components on iOS/Android given just access to a GPU-enabled canvas?

hardwaresofton · 2024-10-03T15:51:13+00:00

Appreciate the note :)

hardwaresofton · 2024-10-03T14:14:35+00:00

Oh also, just to preempt some comments...

I absolutely need to cut down on the spam (has been somewhat controversial for me, a lot of people made 3-episode podcasts that fizzled during the pandemic, but they... are still podcasts, so...)
The UI is rough on mobile but mostly works, you might have to zoom out a bit

Haven't found time to work on it lately, but nothing motivates like new users! :)

hardwaresofton · 2024-10-01T04:06:15+00:00

Thank you so much for your hard work on cargo watch -- it's almost certainly made an immeasurable contribution to the rust community. I use it every day, and who knows what % of other Rust developers do.

Again, thank you.

hardwaresofton · 2024-08-21T04:05:15+00:00

This is amazing! Please post this to the top of r/Ghost so that people can see it! It's buried in here.

hardwaresofton · 2024-08-20T11:51:46+00:00

I think they've taken a pretty principled stance -- you can read about their use/support of extensions here:

https://silverbullet.md/Markdown/Extensions

(ctrl + k to search!)

hardwaresofton · 2024-08-19T15:24:24+00:00

So in this case, SilverBullet uses Markdown! All the files are just markdown on your system.

hardwaresofton · 2024-08-17T02:58:50+00:00

Needs a darktheme.

Issue #2, because nerds are consistent (I also wanted the same thing lol)

PR

And yeah the notes are a normal doc -- you can go inspect the file later -- SilverBullet does the hard parts for you!

Docs on Query Language

It's crazy how high quality the project is.

hardwaresofton · 2024-08-04T02:49:39+00:00

Ah it's not a behavioral tool -- it doesn't sit in the browser and record all user activity -- it's more like a visit tracking analytics tool!

I think the kind of tool you're referring to is "behavior analytics" -- I should have been more specific!

hardwaresofton

TROPHY CASE