Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: HyperLogLog in Zig

github.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: Show HN: HyperLogLog in Zig

#11

Post by kristoff_it »

kristoff_it wrote: post #8

One change to make this library more idiomatic would be to make HyperLogLog avoid forcing heap allocation on the user. So from this (simplified code): pub fn HyperLogLog(comptime p: u8) type { return struct { dense: []u6, const Self = @This(); pub fn init(allocator: Allocator) !Self { return Self{ .dense = try allocator.alloc(u6, 0), }; } } } To this: pub fn HyperLogLog(comptime p: u8) type { return struct { dense: […

Or alternatively one could make good use of the existing buffer and use that to encode the sparse representation, like Antirez did in Redis:

https://github.com/redis/redis/blob/unstable/src/hyperloglog...

Re: Show HN: HyperLogLog in Zig

#12

Post by seiflotfy »

kristoff_it wrote: post #8

One change to make this library more idiomatic would be to make HyperLogLog avoid forcing heap allocation on the user. So from this (simplified code): pub fn HyperLogLog(comptime p: u8) type { return struct { dense: []u6, const Self = @This(); pub fn init(allocator: Allocator) !Self { return Self{ .dense = try allocator.alloc(u6, 0), }; } } } To this: pub fn HyperLogLog(comptime p: u8) type { return struct { dense: […

This is awesome... question though: ```pub fn HyperLogLog(comptime p: u8) type { return struct { dense: [1
            const Self = @This();
            pub fn init() Self {
                var s = Self{};
                for (s.dense) |*x| x.* = 0;
                return s;
            }
        }
    }```
doesn't this allocate 1<<p upfront though. If yes then the HLL of size 16384 bytes upfront which kinda beats the purpose of having a sparse representation no?

Re: Show HN: HyperLogLog in Zig

#13

Post by kristoff_it »

seiflotfy wrote: post #12
kristoff_it wrote: post #8

One change to make this library more idiomatic would be to make HyperLogLog avoid forcing heap allocation on the user. So from this (simplified code): pub fn HyperLogLog(comptime p: u8) type { return struct { dense: []u6, const Self = @This(); pub fn init(allocator: Allocator) !Self { return Self{ .dense = try allocator.alloc(u6, 0), }; } } } To this: pub fn HyperLogLog(comptime p: u8) type { return struct { dense: […

This is awesome... question though: ```pub fn HyperLogLog(comptime p: u8) type { return struct { dense: [1 const Self = @This(); pub fn init() Self { var s = Self{}; for (s.dense) |*x| x.* = 0; return s; } } }``` doesn't this allocate 1<<p upfront though. If yes then the HLL of size 16384 bytes upfront which kinda beats the purpose of having a sparse representation no?

> doesn't this allocate 1Yes, it does. The idea (see the last code snipped in that post), is that the user delays the creation of the HLL until they are ready to switch to a dense representation. Before then, they just use a std.AutoHashMap directly.

Or, alternatively, the HLL could use the same buffer for both dense and sparse representation (see the Redis code).

Re: Show HN: HyperLogLog in Zig

#14

Post by shilldetector »

henry_viii wrote: post #6
eatonphil wrote: post #4

Awesome! Does Axiom use Zig? Most of your projects seem to be in Go. Why did you choose to do this in Zig?

I'm also very curious to know this. HyperLogLog is written in Go: https://github.com/axiomhq/hyperloglog I would expect V to be a more natural choice for a port than Zig.

As a notice to others reading this user's comments, they are a recently made account that seems to exist mostly to post about V and post negatively about Zig. Extremely suspect given the history of poor behavior from the V project.
Post reply on HN