11–20 of 22 posts
In case you're like me and never heard of the Odin PL: https://odin-lang.org/docs/overview/
It's a systems programming language that syntactically feels similar to Go and Jonathan Blow's unreleased language, Jai.
It is meant to be a C replacement (or, on the same level as C), similar to Zig.
In case you're like me and never heard of the Odin PL: https://odin-lang.org/docs/overview/
On Safari/iOS, the webpage to the demo really doesn’t let me scroll down and keeps going back up :(
Earlier quoted context omitted.
Sure! So far, Odin has been awesome for doing custom allocation. Everything in the core library that allocates takes an optional allocator parameter, which means that you can use quite a few of the core libraries comfortably even in embedded contexts, and make it all sit on top of an arena in WASM's weird memoryland if you need to without an issue. Outside of the WASM context where Odin runs into some difficult frict…
Impressive work! Where is the net package getting worked on? Is it the "core_net" branch or do you have your own fork?
Very cool. JSON is clearly a terrible format for this though. I've had great success using SQLite instead. You mentioned binary formats in the video - what other formats are supported? Last I looked the whole chrome://tracing ecosystem was stubbornly stuck with JSON.
Very cool. JSON is clearly a terrible format for this though. I've had great success using SQLite instead. You mentioned binary formats in the video - what other formats are supported? Last I looked the whole chrome://tracing ecosystem was stubbornly stuck with JSON.
For everyone doing new things, there's a binary format which is pretty straightforward.
The binary side supports begin and end events, which are defined here: https://github.com/colrdavidson/spall/blob/master/formats/sp...
and the header library mirrors those structs, and chalks out the interfaces around here: https://github.com/colrdavidson/spall/blob/master/spall.h#L2...
Basically, it's a small header, and then events, plopped one after another into the file. Each thread gets a buffer to store events as they come in, and they get written as atomic chunks with fwrite/append, so threads never have to interact directly.
In practice, the overhead for tracepoints with the binary format is super low, depending on the machine on x86, we've seen somewhere between 12-20ns for begin+end trace overhead when compiled with clang (+ occasional disk flush overhead, if you're generating a ton of data). I believe I can get that overhead even smaller to get things nice and lightweight, it's a major goal of mine to be able to trace 10+ million events per second without impacting runtimes significantly, so that bigger projects can be comfortably fully auto-traced.
On Safari/iOS, the webpage to the demo really doesn’t let me scroll down and keeps going back up :(