Introducing bump_alloc - my new Rust crate

I’ve been continuing my foray into Rust, and one thing I’ve been interested in is global allocators - Rust’s builtin support for switching the allocator used by an application. One thing I’ve been wanting to try for a while is to see if a bump allocator used in conjunction with a short running application could result in performance gains. I couldn’t find while perusing any crate that added a global allocator that just bumps, so I’ve written my own - bump_alloc.

2018 Review

2018 has been a very busy year for me personally, and I thought for the sake of my own memory of the events I’d do a review of the things I’ve managed to achieve this year. Vulkan 1.1 / SPIR-V 1.3 & Subgroup Operations The single biggest item that I shipped this year was adding subgroup operations to Vulkan 1.1 and SPIR-V 1.3. It took just under two years of wrangling with all the hardware vendors to get a set of functionality that we could expose on all Vulkan 1.

Baby’s First Crate: cpp_new

So I’ve been playing around with Rust in my spare time for a few months now, and have been doing a lot of stuff that bridges C/C++ and Rust content. And one thing that has always bugged me is that I can use a super awesome allocator like jemalloc in Rust, but that the allocations being done via C++ were not being routed into this allocator. So as a tiny baby step into the Rust community, I’ve released my first crate cpp_new.

So long Codeplay, thanks for all the fish!

After 11 years since my first internship, and 9 years full time, I’m leaving Codeplay to join AMD. A Brief History of Codeplay and I I was a nineteen year old ned when I started my first internship at Codeplay, and was given the code-monkey job of hand optimizing shaders for an OpenGL ES 2.0 shader compiler, so that Codeplay’s compiler engineers could prove the capability of the compiler. Slated to take 10 weeks, I finished the task in 2 weeks and to stave off boredom in the remaining 8 weeks I ended up proving 100% code coverage of the compiler and writing a test generator to break it.

1.22x Performance Improvements in json.h!

I’ve been meaning to try out Intel’s VTune now that it has a permanent trial mode (you can renew the 30-day trial license every 30-days without paying!), as I’ve long heard people rave about it as a profiling aid. I decided to pick one of my open source C libraries and see what performance problems I could find in the code, and I choose my JSON parser json.h. I’ve long known that the recursive approach I used in the parser will limit the performance I can get out of the code as compared to some of my competitors, but I support a metric-ton of extensional functionality (simplified JSON and JSON5 to name two major extensions that my users love).