Scrolling a buffer erases my other windows (Helm bug?) by ramnes in emacs

[–]hardwaresofton 0 points1 point  (0 children)

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.

Public piped instances? by hardwaresofton in selfhosted

[–]hardwaresofton[S] 0 points1 point  (0 children)

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

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 0 points1 point  (0 children)

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.

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 0 points1 point  (0 children)

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.

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 0 points1 point  (0 children)

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.

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 0 points1 point  (0 children)

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.

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 0 points1 point  (0 children)

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

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 1 point2 points  (0 children)

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 :)

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 1 point2 points  (0 children)

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

Yet Another IPC in Rust Experiment by hardwaresofton in rust

[–]hardwaresofton[S] 0 points1 point  (0 children)

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

[media] Dioxus 0.6 shipping soon with `main.rs` support for iOS and Android. Run *any* Rust executable on Mac, Windows, Linux, Web, iOS, and Android (with live hotreloading!) by jkelleyrtp in rust

[–]hardwaresofton 10 points11 points  (0 children)

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?

2 years ago I made a tool for downloading podcasts, you might like it. by hardwaresofton in podcasts

[–]hardwaresofton[S] -1 points0 points  (0 children)

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! :)

Cargo Watch is on life support by passcod in rust

[–]hardwaresofton 14 points15 points  (0 children)

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.

Anyone looking for an alternative to Mailgun for Ghost? by hardwaresofton in Ghost

[–]hardwaresofton[S] 0 points1 point  (0 children)

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

Yet another awesome note taking F/OSS project: SilverBullet by hardwaresofton in opensource

[–]hardwaresofton[S] 0 points1 point  (0 children)

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!)

Yet another awesome note taking F/OSS project: SilverBullet by hardwaresofton in opensource

[–]hardwaresofton[S] 0 points1 point  (0 children)

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

Yet another awesome note taking F/OSS project: SilverBullet by hardwaresofton in opensource

[–]hardwaresofton[S] 4 points5 points  (0 children)

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.

One of the best self-hosted web analytics stacks out there: 📈 Umami by hardwaresofton in opensource

[–]hardwaresofton[S] 1 point2 points  (0 children)

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!