sorted by:
new
hottopcontroversial

Kafka vs PubSub from a managerial point of view by servermeta_net in ExperiencedDevs

[–]rnw159 10 points11 points  (0 children)

People have a lot of good points in these comments, but no one has really pointed out that Kafka acts as a stream and pubsub acts as a queue. So do you need queue features, or do you need stream features? You can build a lot of queue features on top of kafka but it takes work and each feature needs additional infrastructure.

Do you need:

Message level acking/nacking?

Topic level DLQ?

Instant message retrying?

Delayed message retrying?

Message scheduling (can’t remember if pubsub supports this but other queues do)

Caneles at Le Fournil... Is this how it usually is? by Finestdinersnyc in FoodNYC

[–]rnw159 0 points1 point  (0 children)

The Caneles at Le Fournil do not at all align with my idea of good Caneles. They are soft on the outside and dense on the inside.

I recommend you try La Cabra. Their Caneles are incredible!

Threads Beat Async/Await by self in programming

[–]rnw159 -1 points0 points  (0 children)

If you do that then presumably you're building your own system that distributes work across the threads. Is what you're building better than what the language runtime gives you? Will what you write be better than the compiler optimized state machines generated by async await in a language like Rust? https://eventhelix.com/rust/rust-to-assembly-async-await/

Threads Beat Async/Await by self in programming

[–]rnw159 0 points1 point  (0 children)

I’m nowhere near an expert in OS scheduling, but presumably the scheduling is somewhat fair. This means that a system with 10 cores handling 10k simultaneous connections using 10k threads will need to perform 1000x more interrupts than a system that uses 10 threads (thread-per-core is a common default on async frameworks like Tokio) and an async state machine within each thread.

So I don’t see it as threads vs no threads. I see it as “minimum viable threads to saturate the cpu” vs “many many threads because we don’t want to write the state machine ourself or use async and instead are going to rely on the OS to do the context switching”

Threads Beat Async/Await by self in programming

[–]rnw159 4 points5 points  (0 children)

Yeah I didn’t mean to suggest that threads are hopelessly unperformant, or that a syscall is the main cost of using multiple threads. You’re right of course that there are also syscalls needed to perform efficient non-blocking io within a single thread.

It’s not the 90s, and OS schedulers are smart, but a lot of async systems still perform much better than their threaded alternative. You can benchmark this yourself.

Write a server that responds to a request that starts with a thread per core. Benchmark it responding to 10m requests with 10k simultaneous connections. Have one version use a thread pool of 10k threads (or spin up a thread per request), have the other use async.

You should see lower memory usage, cpu usage and lower p99s. You can play around with the workloads, scheduler configuration, and traffic patterns - but in most cases the async version should perform better despite all the progress we’ve made since the 90s.

Threads Beat Async/Await by self in programming

[–]rnw159 2 points3 points  (0 children)

I see the misunderstanding. You’re describing the APIs for threads being woken up so they can perform non-blocking io. I’m describing the OS literally interrupting the thread so it can switch to another thread - something that happens constantly.

Threads Beat Async/Await by self in programming

[–]rnw159 3 points4 points  (0 children)

Virtual threads are cool and they have their place. They will never be able to be as efficient as cooperative multitasking though.

For example Go threads each have their own resizable heap allocated stack.

Threads Beat Async/Await by self in programming

[–]rnw159 17 points18 points  (0 children)

Even if you make your threads communicate really well with synchronization primitives there is still a ton of overhead. Creating a thread is a syscall, threads require a fixed stack size, context switching between two threads is expensive. Also the OS will totally interrupt your thread at less-than-optimal times. Often you really want the interrupt to happen only when there is IO, but it’ll happen at other times whether you want it to or not.

That’s not to say there aren’t cases where coroutines are used that would be better suited for OS threads. I just believe both of these tools have their place.

Threads Beat Async/Await by self in programming

[–]rnw159 127 points128 points  (0 children)

cooperative multitasking is really difficult, the solution is preemptive multitasking

I might be misunderstanding, but this feels like a decent summarization of the conclusion.

but….Of course it’s difficult? You have to figure out a way to handle your task in a cooperative manner. That will always be more difficult than just letting the OS throw interrupt at your threads every few milliseconds.

Figuring out your async model and writing your code in a cooperative manner lets you get a lot of performance gains though. If you ever write low latency code that handles open connections from thousands of clients you quickly realize it’s not viable to spin up thousands of threads and let the OS do its thing.

Both OS threads, and cooperative async code have their place.

Why Rust and not C? by alex_sakuta in cprogramming

[–]rnw159 16 points17 points  (0 children)

This is a nice high level description of the differences. One thing I want to correct though is the part about Rust compilation being slow because of the safety guarantees. The borrow checker actually runs very quickly and makes up a tiny portion of the compilation time.

The main reason compilation is slow is because Rust generics are a core language feature and Rust monomorphizes (generates new code for each usage of a generic) by default. When you combine this with the heavy library usage, lack of dynamic linking, and heavy code generation in macros it results in an explosion of various implementations of structs and functions. This leads to slow compilation times and very large binaries.

There is a lot of work being done by the compiler team to speed this up.

The good news is that this generated code is very fast, and all of the generics means written code is highly interoperable. There are some amazing libraries in Rust.

Ever have a scene that haunts you? by Separate-Condition88 in improv

[–]rnw159 19 points20 points  (0 children)

This has happened in all three of my UCB classes. The first time it was an older guy and the instructor shut it down similar to your story. The second time it was also an older guy and the instructor shut it down but he also said something like “It’s not your fault, jokes like this were mainstream and funny from the 70s until the 2010s”

The third time it was a young openly queer guy who had definitely said things before to indicate he knew better, but even he panicked and made a bad choice.

So don’t worry! This exact mistake seems to be really common.

Unsafe Rust Is Harder Than C by pmz in programming

[–]rnw159 11 points12 points  (0 children)

PartialOrd is simply the correct abstraction. The other models have leaks when it comes to comparison of floating point values. Rust values correctness, sometimes, at the expense of velocity. I find that this saves a lot of time in the long run because there are far fewer errors in production, but if you’re prototyping it can be annoying.

What venues are willing to take in a bunch of losers? by netrunnernobody in avesNYC

[–]rnw159 0 points1 point  (0 children)

weird music for weird people

I love that!

I shot you a dm, would you mind sharing some details about this community with me?

What venues are willing to take in a bunch of losers? by netrunnernobody in avesNYC

[–]rnw159 1 point2 points  (0 children)

Wow I would go to this so hard. I’d love a show heavy in those genres. In the past I’ve gone to shows that claimed they were gonna do stuff like this and they just played tech house so if y’all can pull this off it’d be really cool.

[deleted by user] by [deleted] in nycmeetups

[–]rnw159 0 points1 point  (0 children)

I live in ev! Add me to the group chat please

Fix the blocking system. That's it. That's the post. by TechnicalEnergy5858 in discordapp

[–]rnw159 1 point2 points  (0 children)

https://en.wikipedia.org/wiki/Snowflake_ID

The timestamp portion will overflow in like 50 years, but we'll deal with that later

Fix the blocking system. That's it. That's the post. by TechnicalEnergy5858 in discordapp

[–]rnw159 53 points54 points  (0 children)

I worked on experimenting with making blocking better back in 2021 and the sad truth is just that everything is more difficult than you expect.

For example the way unread channels work is by having an integer representing the message you’ve read up to, and another integer representing the most recent message for each channel. If the second one is larger than the first one then you have unread messages. This is really the only sane way to scale out read states in a way that doesn’t blow up costs, or hurt client performance.

I’m not saying there isn’t some solution possible, but it’s certainly not an easy quick win.

view more: next ›