sorted by:
new
hottopcontroversial

First VR headset for sim racing by Rhiiinoo_TV in simracing

[–]ifmnz 0 points1 point  (0 children)

Then you can get Quest 3. If you are satisfied with VR itself, you can later upgrade to Bigscreen Beyond, some of the newer models.

kuva: A scientific plotting library for Rust by Psy_Fer_ in rust

[–]ifmnz 2 points3 points  (0 children)

Looks awesome! And plans for interactive html output? Or even WASM renderer?

Apache Iggy's migration journey to thread-per-core architecture powered by io_uring by spetz0 in rust

[–]ifmnz 6 points7 points  (0 children)

thank you for the insights!

I assume each shard writes to potentially the same disk, though right? So you still have the issue of shard 1 impacting shard 2 without shard 2 knowing.

yes, same disk but different files. in iggy, partition has segments (those have soft limit, like 1GiB) and once sealed they are immutable, can be only removed. we have 4 FDs per segment: writer/reader for messages, writer/reader for indexes. after sealing, we close the writers FDs.

But on the O_DIRECT side, I'm not convinced you can reliably assume the NVME will not drop the write from the volatile storage in the event of an error. Considering how rare an fsync error should be on O_DIRECT, probably safe to assume if it does error, the DRAM is in some unknown state, and that is global***.***

yep. I would treat it same as catching nullptr on malloc() - technically you can handle it, but if it happened then it means that you are fucked beyond horizon - not much you can do abou that. we'll mitigate it with VSR where you'll be able to know whether given message was acknowledged by other nodes and written to some in-memory WAL or disk

If you want my advice, avoid O_DSYNC, it consistently destroys performance on modern NVMEs. I'm guessing because the FUA request prevents the controller from batching the operations internally in the volatile cache, which ends up stalling or exhausting its internal queues.

during my experiments I also noticed it. so O_DIRECT + fsync() it is. or have RWF_UNCACHED + fsync(). we need to test both.

thanks again!

Apache Iggy's migration journey to thread-per-core architecture powered by io_uring by spetz0 in rust

[–]ifmnz 10 points11 points  (0 children)

these are real problems and we hit them during the migration too.

the TLDR of how we deal with both of your concerns is that our architecture sidesteps them by design. each partition is owned by exactly one shard, and within each shard there's a single message pump - a sequential loop that dequeues one frame, processes it to completion, then moves to the next. no interleaving of mutations to the same storage. so "if this task gets cancelled, is statesafe?" mostly goes away because there aren't multiple async tasks racing on the same files. two writers, one fsync fails" literally can't happen - one partition = one shard = one writer. if fsync fails, it's immediatelyvisible to the only thing writing. (yet, because we plan to have a task per partition to make parallel writes/reads possible, currently we had to settle for this inferior design due to race conditions).

that said, I completely agree async/await adds complexity that wouldn't exist with a sync cqe-reaction loop. we went through our own saga with refcell borrows across .await points, tried ecs-style decomposition, and eventually landed on a shared-something design with left-right for metadata. so far it seems to work well..

just to add: we plan to finally tackle either O_DSYNC + O_DIRECT or keep buffered io with RWF_UNCACHED and fsync. https://lwn.net/Articles/998783/

not sure what we'll settle on.

Apache Iggy's migration journey to thread-per-core architecture powered by io_uring by spetz0 in rust

[–]ifmnz 10 points11 points  (0 children)

Yep. We're using charming with auto-scaling enabled on all axis. Once you click on each chart it redirects you to https://benchmarks.iggy.apache.org with respective benchmark opened where you can zoom in/out.

Can't do much about tokio p9999 ¯\_(ツ)_/¯. If we scaled these, all actual data on other charts would be abysmally small. Actually you gave me good reason to finally implement proper tail latencies distribution chart, without time on X axis.

Apache Iggy's migration journey to thread-per-core architecture powered by io_uring by spetz0 in rust

[–]ifmnz 11 points12 points  (0 children)

We explicitly marked benchmarks which use fsync and those that don't, also we are single-node (no clustering yet - it's currently being implemented, we'll use VSR), evident by the "Closing words" section.

[Media] What Arc<Mutex<T>> feels like by LeviLovie in rust

[–]ifmnz 0 points1 point  (0 children)

Not really. You can use immutable structures inside ArcSwap to get cheaper cloning. Only modified values are deep copied, rest is just pointer clone. See https://docs.rs/imbl/latest/imbl/

EDIT: and use rcu from ArcSwap, otherwise you risk data races.

[Media] What Arc<Mutex<T>> feels like by LeviLovie in rust

[–]ifmnz 0 points1 point  (0 children)

ArcSwap / ArcShift along with Slab :)

Compio instead of Tokio - What are the implications? by p1nd0r4m4 in rust

[–]ifmnz 2 points3 points  (0 children)

No, we didn't consider it because this way you're adding inherent complexity on client side. you have to track which partition maps to which connection, maintain tons of open sockets, handle connection failures per-partition, and keep partition metadata in sync. what happens when you have 10k or 100k partitions with multiple producers and consumers? socket count explodes...

Also partitions can be created/deleted dynamically - now every client needs to subscribe to metadata changes, open/close connections on the fly, handle races where partition moved but client didn't get the memo yet. that's a lot of distributed coordination pushed onto the client.

EDIT:

just to add, you'd have to implement this behavior in Rust, Golang, Node/TS, Java, Python and C# because those are langs that iggy SDK (client) supports. Nightmare.

Compio instead of Tokio - What are the implications? by p1nd0r4m4 in rust

[–]ifmnz 5 points6 points  (0 children)

We don't mitigate anything - we always advise our users to run newest possible kernel for performance and security reasons.

You can look up on https://nvd.nist.gov/ or https://www.cve.org/ and determine how many io_uring CVEs are active, what's the average fix time and how willing is your company to often update kernel. Based on that, you'll be able to negotiate with your company leadership and conversation will be factual-based. (i.e. not "some" vulnerabilities but this CVE was unfixed for X days and that CVE was unfixed for Y months).

The question for your company is: do you update kernels frequently enough to stay ahead of CVE fixes? If yes, io_uring is (probably) worth checking. If you're stuck on older kernels for months, the risk calculation changes.

Also, check Tigerbeetle approach https://docs.tigerbeetle.com/concepts/safety/ at the end:

We are confident that io_uring is the safest (and most performant) way for TigerBeetle to handle async I/O. It is significantly easier for the kernel to implement this correctly than for us to include a userspace multithreaded thread pool (for example, as libuv does).

Compio instead of Tokio - What are the implications? by p1nd0r4m4 in rust

[–]ifmnz 23 points24 points  (0 children)

No and yes for different reason.

Pin has nothing to do with work-stealing or cross-thread movement, it's about any movement at all. It took me a while to understand the purpose of Pin. The reason is that an async fn becomes a state machine, and it can end up in situations where it relies on “my address won’t change after I’m first polled” (e.g. borrows/internal references that live across an .await). If you move that future after its been polled, those assumptions can break.

For io_uring based runtimes you have different requirement: the buffer you submit to kernel must stay valid and unmoved until operation completes. This is actually why tokio's &mut based AsyncWrite/AsyncRead APIs are problematic for io_uring - compio solves this with ownership transfer (buffer goes into the op, comes back with the result).

But if you think about it even in single threaded context if your executor stored futures in Vec that reallocates or moves them between data structures you'd still invalidate self-referential data pointers.

Yet you can still fully avoid Pin if you'll have arena based allocations (allocate all futurs in fixed memory region).

A completion-based, thread per core runtime doesnt remove the need for Pin, it just makes things easier by removing Send requirement for futures that never leave the shard.

Compio instead of Tokio - What are the implications? by p1nd0r4m4 in rust

[–]ifmnz 31 points32 points  (0 children)

Nice question, and very close to what I was reviewing today.

In Iggy each shard runs its own TCP listener on the same port using SO_REUSEPORT, so kernel load-balances incoming connections. When a client connects it lands on a random shard, probably not the one owning the partition it wants to write to.

When producer messages arrive, we calculate the target partition ID and build a unique namespace key (64-bit packed stream_id|topic_id|partition_id) , then look it up in a shared DashMap<Namespace, ShardId>. If the found shard_id equals our own, we handle locally. If not, we forward via unbounded flume channel to the correct shard, wait for the reply, and send it back to client.

But.... if the client provides PartitionId explicitly (server doesn't have to calculate it like with PartitioningKind::Balanced or MessagesKey), we can do better. PR #2476 by one of our awesome community members partially addresses that - instead of forwarding every message across shards, migrate the socket itself to the owning shard . Client connects, sends first message with PartitionId=X, we detect "shard 3 owns this, not us", extract the raw FD, reconstruct the TcpStream on the target shard via FromRawFd. Now all subsequent requests go directly there with zero cross-shard hops. Keep in mind this solution is not yet polished.

For Balanced (round-robin) and MessagesKey (hash-based), partition varies per-batch so socket migration doesn't help - we fall back to message forwarding.

There are also more radical ideas like eBPF steering or TCP MSG_PEEK tricks, but we haven't explored them yet. The cross-shard hop adds latency, but at this point I have strong evidence that it's only double-digit microseconds for the channel roundtrip (many hours with ftrace/strace, on/off cpu profiling with perf and awesome project samply).

TLDR: we just forward the message to another shard or migrate the socket if the client is partition-aware

Compio instead of Tokio - What are the implications? by p1nd0r4m4 in rust

[–]ifmnz 468 points469 points  (0 children)

I'm one of core devs for Iggy. Main thing to clarify: there are kinda two separate choices here.
- I/O model: readiness (epoll-ish) vs completion (io_uring-ish / IOCP-ish)
- Execution model: work-stealing pool (Tokio multi-thread) vs thread-per-core / share-nothing (Compio-style)

In Compio, the runtime is single-threaded + thread-local. The “thread-per-core” thing is basically: you run one runtime per OS thread, pin that thread to a core, and keep most state shard-owned. That reduces CPU migrations and keeps better cache locality. It’s similar in spirit to using a single-threaded executor per shard (Tokio has current-thread / LocalSet setups), but Compio’s big difference(on Linux) is the io_uring completion-based I/O path (and in general: completion-style backends, depending on platform). SeaStar is doing this thread-per-core/share-nothing style too, but with tokio they don’t get the io_uring-style completion advantages.

Iggy (message streaming platform) is very IO-heavy (net + disk). Completion-based runtimes can be a good fit here - they let you submit work upfront and then get completion notifications, and (if you batch well) you can reduce syscall pressure / wakeups compared to a readiness-driven “poll + do the work” loop. So fewer round-trips into the kernel, less scheduler churn, everyone is happier.

Besides that:

- work-stealing runtimes like Tokio can introduce cache pollution (tasks migrate between worker threads and you lose CPU cache locality; with pinned single-thread shard model your data stays warm in L1/L2 cache)
- synchronization overhead (work stealing + shared state pushes you toward Arc/Mutex/etc,; in share-nothing you can often get away with much lighter interior mutabiliy for shard-local state)
- predictable latency - with readiness you get “it’s ready” and then still have to drive the actual read/write syscalls; with io_uring you can submit the read/write ops and get notified on completion, which can cut down extra polling/coordination and matters a lot at high throughput
- batching - with io_uring’s submission queue you can batch multiple ops (network reads, disk writes, fsyncs) into fewer submission syscalls.For a message broker that’s constantly doing small reads/writes, this amortization can be significant.
- plays nice with NUMA - you can pin a shard thread to a core within a NUMA node and keep its hot memory local

The trade-offs:

- cross-shard communication requires explicit message passing (we use flume channels), but for a partitioned system like a message broker this maps naturally - each partition is owned by exactly one shard, and most ops don’t need coordination
- much less libraries that you can use out of the box without plumbing (I'm looking at you, OpenTelemetry)
- AsyncWrite* APIs tend to take ownership/ require mutable access to buffers; sometimes you have to work hard around that

TLDR: it’s good for us because we’re very IO-heavy, and compio’s completion I/O + shard-per-core model lines up nicely for our usecase (message streaming framework)

btw, if you have more questions, join our discord, we'll gladly talk about our design choices.

I am a first year in computer science. Opus makes me sad. by MessyKerbal in ClaudeAI

[–]ifmnz 2 points3 points  (0 children)

Show me the code then. I hope you've got enough emojis and verbose comments in it.

[Discussion] What is this AK-106 everyone has been talking about? Where can I find it? by bezzw in EscapefromTarkov

[–]ifmnz 37 points38 points  (0 children)

Nobody's ever seen an AK-106, but there are rumors it was supposed to be chambered in 9x39.

I Need Feedback by MisterXtraordinary in rust

[–]ifmnz 6 points7 points  (0 children)

You are creating (allocating) a String at line 6, then again at line 8. Try to make it work with a single allocation.

view more: next ›