kprotty

7 ms·

31.
by kprotty 3y ago
Are there cheaper ways of getting elapsed time with sub microsecond precision? Interested as I've only ever heard of rdtsc at the lowest level in userspace for x86.
32.
by kprotty 3y ago
Invariant (Constant) TSC is detectable via `cpuid` and applies to `rdtsc/rdtscp` by default. In that aspect, there's no tradeoff being made there (observable to software) AFAICK.
33.
by kprotty 3y ago
You can `errdefer/defer if` inside the blk, then x = blk:{}; defer use(x)` outside the block.
34.
by kprotty 3y ago
Did you mean the `nosuspend` keyword? It only asserts nothing suspends rather than there being a "sync" mode.
35.
by kprotty 3y ago
Zig async doesn't change semantics of how things are called. If something is called sequentially, it will execute sequentially with respect to itself, with or without async.
36.
by kprotty 3y ago
Destructors don't seem to be the best place to implement cancellation for async functions: Rust async is going through a phase where the community is realizing it would be nice to have async destructors or non-cancellable async functio
37.
by kprotty 3y ago
Zig's async manages the coroutines intrusively: It generates the state machine type, you provide the memory for where an instance of one runs, and you manage resuming it until completion. Similar to Rust's Futures, it's prett
38.
by kprotty 3y ago
No, async functions still return an async Frame (the semantic equivalent of a Rust Future) which evaluates to the result, rather than the result itself. Zig's "colorless async" description comes from the implicit infectiousne
39.
by kprotty 3y ago
Do any of these count? https://www.uber.com/blog/bootstrapping-ubers-infrastructure... https://github.com/tigerbeetledb/tigerbeetle/blob/main/build... https://github.com&
40.
by kprotty 3y ago
libdispatch idea of using specific queues for serialized concurrency is nice, but its abstractions on top are unfortunately not as efficiently designed as it could be; `dispatch_source` doesn't allow for direct completion based IO sche
41.
by kprotty 3y ago
Vectors in Zig are SIMD types. Vectors in games are probably algebraic types. Using SIMD for the latter may not be that useful if 1) specific elements are accessed frequently 2) transformations involve a different operation happen on each e
42.
by kprotty 4y ago
FixedBufferAllocator is meant to minimally viable like in settings when there's no shared concept of "printing" or an OS for that matter. Check out LoggingAllocator which can take/wrap the former.
43.
by kprotty 4y ago
Yea, I think we're mostly on the same page. For higher level domains where unsafe isn't required and some runtime overhead is acceptable, I believe there's real cases to be made that Rust can be substantially better than the
44.
by kprotty 4y ago
> don’t count CVEs without looking at the context and content of those CVEs The CVEs are counted as they're memory issues (not only logical issues) that can technically surface in safe Rust code and are also considered UB in other l
45.
by kprotty 4y ago
> zero of these bugs will be due to buffer overflows or use after free or other memory bugs in safe rust buffer overflows [0] [1], use after frees [2] [3], and other memory bugs [4] [5] [6] can appear in safe rust from unsound unsafe int
46.
by kprotty 4y ago
> the actual rules for undefined behavior are the virtually same as in C 1. Creating a mutable reference when there's other references to the same memory around, even if you don't use/deref that mutable reference, is consi
47.
by kprotty 4y ago
Rust can't encode non linear lifetime at compile time. This means anything where ownership or access patterns can be self referential or "go up" statically. This includes things like intrusive data structures (linked lists, g
48.
by kprotty 4y ago
King from TigerBeetle here. One of the reasons is that libdispatch's I/O functions introduce extra dynamic allocations for internal queueing via `dispatch_async` ([0],[1],[2]) and from an API perspective of realloc-ing [3] an inte
49.
by kprotty 4y ago
1) Stage2 is intended as more than just fixes for stage1; It includes performance improvements, more codegen backends (direct x86/arm/wasm to avoid LLVM, C, etc.), will allow for incremental linking, hot reloading, and more. 2) Th
50.
by kprotty 4y ago
It's not expected to have miscompilation bugs like this by 1.0. These are bugs in the stage1 (original C++) compiler implementation, not language design issues as the poster claims. The language still has design issues that are being a
51.
by kprotty 5y ago
unsafe Rust has its own UB pitfalls that don't exist in C nor Zig, particularly in regards to the lifetimes of references [0] and preserving provenance through experimental apis [1]. [0]: the compiler is allowed to emit extra reads&#x2
52.
by kprotty 5y ago
The results will vary on different systems given how the combination of the CPU and OS handle thread synchronization + scheduling. On one of my desktops running Windows 10 with an i7-4790k, the Go qsort runs slower (~600ms) than the Rust qs
53.
by kprotty 5y ago
Id encourage you to try recording them yourself. The results can vary depending on your system, how much concurrent tasks it can make parallel, if scheduling resources are being used elsewhere, etc. The zig code contains an example of using
54.
by kprotty 5y ago
If you browse the source, the go scheduler has complexities to deal with that tokio doesn't as well. The thread pool is unified between worker threads & blocking threads. Go also does goroutine preemption via signaling/Suspend
55.
by kprotty 5y ago
This actually can be at the level of a missed optimization. A run queue with a lock-shared queue amongs all the threads scales even worse than the tokio version. Sharding the run queues and changing the notification algorithm, even while ke
56.
by kprotty 5y ago
First of all you, along with a few others, misunderstood the goal of the scheduler. I note in the post that it's primarily for async execution. See a previous comment of mine on how a fork-join optimized thread pool which hooks into th
57.
by kprotty 5y ago
I'm not sure how this implies it is flawed. It benchmarks thread pools so on a system which allowed more parallel concurrent tasks (i.e. 32t amd cpu) the throughput is expected to scale somewhat, and you see this in your results. Also,
58.
by kprotty 5y ago
I don't think tokio's slowness here is "to be expected". There isn't much reason for tokio tasks to have that much overhead over normal thread pools. The I/O driver shouldn't be called in such a benchmark
59.
by kprotty 5y ago
I'm aware that it's technically considered blocking due to a producer being preempted between swap and store causing the consumer to see an invalid link and report empty. I address this in the run queue section by noting that it&#