For the second benchmark I am going to explore the performance of .NET compilation and benchmark performance using an Avalonia ’s code base. As I wrote in this previous post I’m doing a series of benchmarks of .NET and JVM on Apple Silicon. While there are impressive native benchmarks the fact it will be some time before the .NET runtime has native support. I have to factor in the potential hit and problems with Rosetta. How much of a performance hit is there and will it be enough that applications targeting it will have problems? All code and results are published here .

For the second benchmark I am going to explore the performance of Java with a library I use on a regular basis for astrodynamics calculations: Orekit . There has been a change since I started this (see this previous post ) though. Azul , a company that specializes in Java and JVM infrastructure, has released a version of OpenJDK that is compiled for Apple Silicon. I have therefore run the benchmarks both using AdoptJDK Intel installation running under Rosetta as well as the Apple Silicon Native M1 one by Azul. Let’s see how Orekit runs in these three environments. The full project and results is documented here .

For the second benchmark I am going to explore the performance of .NET rendering using an Uno Platform benchmark. As I wrote in this previous post I’m doing a series of benchmarks of .NET and JVM on Apple Silicon. While there are impressive native benchmarks the fact it will be some time before these two runtimes natively support it, I have to factor in the potential hit and problems with Rosetta. How much of a performance hit is there and will it be enough that applications targeting it will have problems? All code and results are published here .

As I wrote in this previous post I’m doing a series of benchmarks of .NET and JVM on Apple Silicon. While there are impressive native benchmarks the fact it will be some time before these two runtimes natively support it we have to factor in the potential hit and problems with Rosetta. How much of a performance hit is there and will it be enough that applications targeting it will have problems? All code and results are published here . For the first benchmark we are going to explore the performance of JavaFX.

Apple Silicon is looking pretty impressive. I’m impressed enough to replace my 2018 MacBook Pro with the shitty keyboard with a new M1 MBP. All the benchmarks though are useless to me since I’m primarily a .NET and JVM developer who will be running under emulation in Rosetta for the foreseeable future. I intend to quantify the performance of the new Macs versus the old Intel ones with a suite of benchmarks specifically targeting .NET and JVM runtimes.

I worked out how to do basic string file input and output for Kotlin Native using their standard POSIX libraries. The code for these methods is at the bottom. This article explores it in more detail if you are interested.

As the weather gets cooler in lots of the world a nice hearty but healthy dish is so much more tantalizing. If you are a big fan of rustic sourdough breads then this is a perfect dish that captures all of the joyous flavors along with some healthy vegetables. I first discovered this recipe in this Guardian article but I’ve since made a few tweaks to it. My go to bread for this is either the Yohan Ferrant Do Nothing Bread or some Tartine bread.

I’ve always liked having a record of what I’ve done on a project and a place for notes. That’s often been a notebook, updates to GitHub/GitLab/JIRA issues/tickets, or maybe blog entries. Those all have problems. In reading Masters of Doom I came across a passage which described the intense environment around the development of Quake. John Carmack came up with a concise running log of what he was doing, called a “.plan” file. It provided a frictionless way for him to keep track of his progress, the things he wanted to fix later, notes he had to himself, etc. He used it for himself but also posted it to the internet to keep the gamer community informed. You can read the whole archive of them from 1996 through 2010 here , although after 1998 they were more like a blog. I decided to tweak the style of his 1995-1998 system slightly and have been using this modified process for tracking my development on projects since November of last year. I call these files DevLog (very creative I know) and find it works so well that I’d share my methodology here.

Yesterday I was following a Twitter thread John Carmack where he was talking about optimizations. Someone suggested he do some sort of a series on how to build game code et cetera. His response was to point to something I’ve never heard of before Handmade Hero . This is a project started by a small group of developers back in 2014. Their goal is to produce the whole game as live coding so people can see how they, professional developers, build a game. I’ve watched previous live coding videos before and enjoyed them. My first was this person writing a vim-like program for CP/M in assembly language, link here . Sounds very dry but I actually get a kick out of seeing how other coders work. I’m just through the first video and am pretty fascinated.

I’ve spent the last few days somewhat diligently playing around with Rust. That’s mostly been studiously reading The Rust Language Book and doing some of the examples. I’m quickly tiring of that and will have to move on to koans, tutorials, or just some projects. However each day I’m learning a bit more about rust. There is a little more insight each day, mostly positive, but one area I am having some concerns is the area of error handling. Specifically I’m concerned about their lack of any traditional exception handling and in its place only returning error objects or panicking (crashing) the whole program.