cryptocode

joined 2 years ago
MODERATOR OF
 

"Less than a week ago, we finally turned on the x86_64 backend by default for Debug builds on Linux and macOS. Today, we’ve got a big performance improvement to it: we’ve parallelized the compiler pipeline even more!"

See the post for more details and benchmarks

 

From the README:

Overview

conduit-z provides a flexible Object type that can store and stream data efficiently, automatically switching between in-memory and file system storage based on size constraints. It's designed for scenarios where you need to handle data of varying sizes without knowing the final size upfront.

Features

  • Automatic Storage Management: Starts with in-memory storage and automatically falls back to temporary files when size limits are exceeded
  • Stream Interface: Provides both reader and writer interfaces compatible with Zig's standard I/O
  • MD5 Hashing: Built-in MD5 hash computation during read/write operations
  • Memory Efficient: Configurable memory limits and dynamic growth
 

From the README:

FileDB is a Zig-implementation of Bitcask by Riak paper.

  • FileDB stores record metadata in a log-structured hashtable and parallely keeps 1 disk file open for inserting records in append-only mode. On restarts or MAX_FILE_REACHED, the disk file is rotated and all the oldfiles are kept open for reading only.
  • A compaction process running every config.compactionInterval seconds, reads all the disk files and combines them into one file while updating the metadata hashtable.
  • A sync process syncs the open disk files once every config.syncInterval. Sync also can be done on every request if config.alwaysFsync is True.

Read about internals in-depth at FileDb.

 

From the README:

An RFC 9562 compliant UUID implementation for Zig.

About

  • Version support: Implements all UUID versions including the latest v6, v7, and v8
  • Type safety: Use the Uuid union to accept any version, or Uuid.V7 to only accept V7 UUIDs
  • Thread safety: Generate time-based UUIDs from multiple threads without coordination or duplicate values
  • Packed structs: All UUID types can cast directly to integers and work with raw bytes without overhead
  • Compliant: Generates UUIDs with correct bit layouts, version/variant fields, and timestamp formats
  • Non-compliant: Represent UUIDs that don't follow RFC 9562 for interoperability
  • Flexible clocks: Configurable clock sources for time-based UUIDs with atomic and local implementations
  • Zero dependencies: Uses only Zig's standard library

The design is heavily influenced by the Rust uuid crate, with some Zig specific flavoring.

 

From the README:

Tase is a lightweight log management system written in Zig. It consists of a daemon running on a master server and lightweight agents deployed across multiple servers. With a single config.yaml, Tase allows centralized control over log file management, including deletion, rotation, and truncation.

Features:

  1. Master-Agent Architecture: The master server manages configurations and schedules, while agents execute log management tasks.
  2. YAML-Based Configuration: The master server reads a config.yaml file to determine agent behavior and scheduling.
  3. Cron-based Scheduling: The application uses cron-based scheduling to execute the log management tasks at predefined intervals.
  4. Delete Logs: The application can delete log files that are older than a specified number of days or exceed a certain size.
  5. Rotate Logs: The application can rotate log files, optionally compressing the archived files using the GZip algorithm. It can also delete archived logs older than a specified number of days or size same as delete action.
  6. Truncate Logs (Not yet implemented): The application can truncate log files that are older than a specified number of days or exceed a certain size.
 

From the READEM:

Heap with compile-time parameteric branching factor, also known as d-ary heap.

Note that there is a binary heap in the standard library if you do not want to use this module: std.PriorityQueue

Performance notes:

  • Heaps with higher branching factors are faster in inserting element and slower in removing elements. If you are going to insert and then remove all elements a binary heap is already quite fast and a branching factor higher than 5 is probably going to be less optimal. The optimal branching factor is usually around 4.
  • The branching factor here is compile time to enable the optimization of division by the compiler, see e.g: Montgomery modular multiplication.
  • If case you need to pop the top element and insert a new one, or vice versa, use the replaceTop member function to avoid paying the extra cost of "bubbling-up" the inserted element.
 

This looks like a great demonstration of using io_uring to minimize syscall overhead

 

This is a spec-compliant TOML parser for Zig. According to the README, the following parsers are available:

 

From the README:

A sophisticated test runner for zig, with extra features and modern aesthetics.

  • Colored output logs
  • Supports hooks like @BeforeAll and @AfterAll
  • Bail tests early
  • Time record for each test
  • Pluggable into any existing project
  • Comes with expect(...).equals(...) type matchers
 

From the README:

Zeppelin is a cross-platform 2D graphics and window library in pure Zig*. It features hardware-accelerated vector graphics (through Vulkan), built-in text rendering, and a window system integration for windows and linux (wayland only). Android support is planned.

 

From the README:

Zigft is a small library that lets you perform function transform in Zig. Consisting of just two files, it's designed to be used in source form. Simply download the file you need from this repo, place it in your src directory, and import it into your own code.

Here's one of the examples given:

const std = @import("std");
const fn_transform = @import("./fn-transform.zig");

fn attachDebugOutput(comptime func: anytype, comptime name: []const u8) @TypeOf(func) {
    const FT = @TypeOf(func);
    const fn_info = @typeInfo(FT).@"fn";
    const ns = struct {
        inline fn call(args: std.meta.ArgsTuple(FT)) fn_info.return_type.? {
            std.debug.print("{s}: {any}\n", .{ name, args });
            return @call(.auto, func, args);
        }
    };
    return fn_transform.spreadArgs(ns.call, fn_info.calling_convention);
}

pub fn main() void {
    const ns = struct {
        fn hello(a: i32, b: i32) void {
            std.debug.print("sum = {d}\n", .{a + b});
        }
    };
    const func = attachDebugOutput(ns.hello, "hello");
    func(123, 456);
}
[–] [email protected] 0 points 4 months ago

yeah I use jj daily myself and for the most part am very happy with it. I still find xit to be a interesting take - been driving it for a day and it seems solid.

[–] [email protected] 1 points 5 months ago

Yep, it's a good one and one to follow :)

[–] [email protected] 2 points 5 months ago

Good memories of Turbo Pascal 5.5 ;)

[–] [email protected] 1 points 5 months ago (2 children)

Dunno, I was just summarizing and linking the article. What is not mentioned in the article is Zig's upcoming incremental compilation which is bonkers fast. Either way I'll follow this effort with great interest.

view more: next ›