kprotty

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer std.debug.assert(gpa.deinit());
    const allocator = &gpa.allocator;

    const num_threads = std.math.max(1, (std.Thread.getCpuCount() catch 1) / 2);
    const epolls = try allocator.alloc(std.os.fd_t, num_threads);
    defer allocator.free(epolls);

B-Y-P

R. Alverson - Integer Division Using Reciprocals

For simplicity, this will just go over the unsigned case
Written for someone, such as myself, who isn't as quick to put together the same logical steps

Given $y \in \mathbb{Z}$ where $y > 0$
Find $a,sh \in \mathbb{Z}$ such that $\forall x \in \mathbb{Z} \ (\ \lfloor x/y \rfloor = \lfloor x \cdot a / 2^{sh} \rfloor)$
To motivate what we'll be doing, lets start by considering:

$$ \begin{align*}

ripatel-fd

Consider this an informal guide to reading the Solana snapshot format. This guide is written for Solana Labs versions v1.14 through v1.17.

You are probably reading this because you want to read the accounts in a snapshot without going through the pain of interfacing with the Solana Labs codebase.

Terminology

We assume general familiarity with the Solana ledger.

Rexicon226

// zig build-exe benchmark.zig -OReleaseFast -lc
// ./benchmark 4096
const std = @import("std");

const allocator = std.heap.c_allocator;

const iterations_per_byte = 1000;
const warmup_iterations = 10;

comptime {

kprotty

1. Every atomic object has a timeline (TL) of writes:

   • A write is either a store or a read-modify-write (RMW): it read latest write & pushed new one.
   • A write is either tagged Relaxed, Release, or SeqCst.
   • A read observes some write on the timeline:
     • On the same thread, future reads can't go backwards on the timeline.
     • A read is either tagged Relaxed, Acquire, or SeqCst.
     • RMWs can also be tagged Acquire (or AcqRel). If so, the Acquire refers to the "read" portion of "RMW".

2. Each thread has its own view of the world:

• Shared write timelines but each thread could be reading at different points.

kprotty

Currently, the std.Io interface isn't too optimizable:

1. All forms of concurrent execution goes through io.async/asynConcurrent(f) and io.await which can't be statically aware of when .await will be called, so it must dynamically allocate the context needed to run f.
2. The main api for blocking/unblocking on an arbitrary state is through Mutex & Condvar which require locking a mutex to wait (& wake correctly) + restrict implementors to only a usize with a biased representation for each state.
3. It ties cancellation to the task/concurrency model instead of to blocking operations (which are really the ones getting cancelled); To cancel a set of operations, they must be wrapped in a new spawned Future. It's also unclear, due to the racy nature of io.cancel, if a blocking operation consumes the stored cancellation request, or if it persists & causes all future blocking ops in that Future to return Cancelled.

I've thought of some ideas on how to address these + the all-encompassing nature of th

Rexicon226

const std = @import("std");

const el: u256 = 0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed;
const L = 1 * el;

fn heea(v: u256) struct { u128, u128 } {
    std.debug.assert(len(L) == 253);
    std.debug.assert(v < L);
    std.debug.assert(v > 0);