Monday, March 27, 2023


I've just recently completed an online course for Rust. I find Rust a very interesting language. I've always subscribed to the philosophy that the compiler should try as hard as possible to find errors for you. While I can appreciate an interpreted language like Python, in my experience Python requires an enormous amount of discipline to write a large Python program with many team members. In a language like Java, the compiler is doing so much tedious work by making sure you don't pass arguments or assign variables of the wrong type.

The interesting thing about Rust is that it doesn't have a garbage collector. Rust is a replacement for system languages like C or C++, where it is not always possible or desirable to have a garbage collector thread working away int he background.

While I'm not the best at C++, I have used it enough to realize that managing memory consumes a big chunk of mental overhead. I know about patterns like using the stack to free resources and I know all about memory pools, but I don't feel comfortable enough with C++ to say that I've fully assimilated all the patterns good C++ programmers use to keep themselves out of trouble. Rust is a window on that world.

Whenever you find people using a (good) pattern, other people will try to make a computer language that accommodates it. Using a stack while in assembly leads to things like procedures. The judicious use of goto leads to things like the break or return statement. Even recently, a style of programming that tries to make everything immutable leads to a type of programming called functional programing. Rust tells me about the types of patterns C++ programmers use to keep themselves from making mistakes.

Rust has this thing called the borrow checker. It's primary purpose it to make sure that only one chunk of code owns a variable or piece of memory. Without a garbage collector, every object must be manually freed exactly once. This functionally means that every object has an owner who's job it is to manage the lifetime of the object and free it when it's not used anymore.

The borrow checker essentially forces you to make clear which functions are merely using an object and which function owns the object. It works surprisingly well although I've heard complaints that for things like a tree structure with a parent back links you have to do some serious thinking to make it all work. Honestly, I remember writing a doubly linked list in C++ and felt it was like watching bender putting on his own arms.

In any case, I hope I have the privilege of working on a Rust code base at some point. At the very least it will make me a better C++ programmer.

Wednesday, February 22, 2023

Gave up on using a Ryzen 9 5950X with a B450 MSI Tomahawk motherboard - too unstable

 So after much time and effort trying to stabilize the Ryzen 9 5950X with the B450 Tomahawk, I gave up and just got a B550 Tomahawk motherboard. All the things that should have worked on the B450 motherboard now work on the B550 motherboard. Specifically, you can run it at default "auto" BPO settings. You can run it with PBO enabled. You can run the ram at the XMP-1 and XMP-2 profiles (3200Mhz). I can even max out the system's cooling at hit 90C on the processor. Nice.

So what went wrong with the B450? No idea. It's probably power/VRM related but it could also easily be electrical interference related as well. All I know is it it kept giving me the same error: black screen and it needed to be reset at the power supply switch because holding down the power on button didn't work.

Fun facts, if you run the 5950X with PBO explicitly disabled AND you set the ram to 2133Mhz, it runs reasonably stable but will sometimes crash after a sleep. Increasing the RAM bus speed or turning on PBO will make it more likely to crash. Weirdly setting the PBO power limits to the motherboard limits didn't seem to hurt stability that much. In fact there's a chance the stability was a little better. It makes intuitive sense at first glance but AFAIK the motherboard power limits are higher than if you simply disable PBO.. and setting higher limits should cause more instability.. so I'm a bit suspicious of my subjective stability experience.

Another interesting factoid involves the RAM compatibility list that MSI produces for that motherboard. Initially they didn't differentiate between the 5000 series and the rest but since then they've revised it so that the 5000 series had a different list with no ram listed as being compatible over 2666Mhz. Recently I can't even get MSI's website to produce a ram compatibility list for the 5000 series processors. I'm guessing this means MSI has noticed the board is flaky with 5000 series processors.

I'm putting this out there to save people a bit of time if they're having trouble with 5000 series Ryzen processors on the B450 Tomahawk board. You're not going to find stability nirvana with that board.