💾 Archived View for skyjake.fi › gemlog › 2023-04_ryzen-swap.gmi captured on 2023-04-26 at 13:02:51. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
📅 2023-04-22
I don't often get to go spelunking in the innards of my PC. Yesterday, however, I got the opportunity to do so. This is quite a Special Occasion nowadays with all the ongoing time pressures of work and family life.
The task at hand was upgrading the CPU from a venerable Ryzen 7 1700 to a shiny new 5700X. The TDP is the same at 65W and the socket remains AM4, so it is pretty much a drop-in replacement.
A curious thing happened while waiting for the new CPU to arrive. I mostly run Windows on this PC, so the notion of an imminent hardware upgrade got me excited about working on some Windows programming. As a Mac guy, I normally tend to procrastinate and put off all things Windows, but the coolness factor of a significant speed bump got the better of me. This is a bit of "motivation hacking" to take note of: you can sometimes leverage excitement in one thing to make progress with an adjacent less-exciting thing.
I decided to tackle a long-standing issue in the_Foundation, my C library that underpins Lagrange and some of my other projects. What better way to pass the time? Being POSIX-oriented, the_Foundation has been lacking a native Windows implementation of some key functionality: network sockets, IP address lookup, pipes, and child process management. This is a sizable chunk of work, especially for someone who really tries to avoid dealing with the Win32 API directly if it can be avoided. The missing functionality is very central to an application like Lagrange, so I've been forced to rely on the MSYS2 environment to make a fully-functional Windows build. MSYS2 provides all of these features via the usual POSIX APIs, BSD sockets, etc. but at the cost of an additional runtime DLL to distribute and its associated overhead.
TECHNICAL ASIDE: One can build and run UNIX/POSIX programs on Windows using 3rd party environments like Cygwin and MSYS2. Cygwin is the traditional choice, and MSYS2 is a more modern solution that offers multiple different runtimes and toolchains. Some of these runtimes are directly compatible with Microsoft's tools. The downside with these additional layers is, of course, slower performance. Especially file access and multithreading are significantly slower when done via Cygwin or MSYS2. The slowdown is attributable to fundamental OS-level differences.
How does one make a native Windows build of an application like Lagrange? These are basically two approaches:
The path of least resistance for me is MinGW, but for that to be feasible, I needed to add the aforementioned missing functionality to the_Foundation.
Here's where I've been procrastinating for something like five years. I view Windows as a legacy platform and the Win32 API doubly so, which has made it difficult to justify investing time into this. But now, with an exciting hardware upgrade looming, I had the motivation to do something about it.
One problem still remained, though. I simply don't have the time to pore over reference documentation, BSD-to-Winsock porting guides, and StackOverflow answers to figure out how exactly the Win32 APIs work and how the new code should differ from the POSIX implementation. Fortunately, we have a new solution to this problem. You may have heard of it: large language models like GPT-3. The model presumably covers all of MSDN, porting guides, StackOverflow, and other relevant sources, so one only needs to start a discussion with ChatGPT to get the lay of the land. So that is exactly what I did, and a few days later, I had a fully-functional native Windows port of my library.
There's a lot of handwringing about what AI means for software development (and other professions). Naive fears and legitimate legal concerns aside, for me this demonstrated tangible value not available via any other means. GPT was able to quickly get me on the right track, and I could then cross-reference specific details in Microsoft's documentation and other authoritative sources. The possibility to make clarifying questions was vital when I was unsure about something. And to be clear, none of the code that GPT generated went directly into my library. A competent and diligent programmer is not going to directly copy code found online, but rather use it as a reference for their own implementation. (It also helps that I have a very particular coding convention so any new code has to be specifically crafted to fit in.)
Reactions to the use of GPT have been very mixed, which makes me feel a bit defensive here. In my experience, new tools of this caliber have potential to be truly transformative. However, it is crucial to understand how they are to be used correctly, and that will never happen if one turns their back on them. It is important to not trust GPT output as-is, but treat it like an unreliable narrator that is knowledgeable on many things, but (like a human) will be wrong sometimes. In the end, having functional code that may have a few bugs is much preferable to having no code at all. (And let's not forget, any new code is bound to have new bugs anyway.)
Getting back to the original topic, the new CPU finally arrived in the mail and I found a suitable time for installing it during the kids' afternoon nap.
I had new thermal paste, isopropyl alcohol, and a screwdriver prepared, so I opened up the PC and took a look inside. Yep, there was the Ryzen CPU under the AMD Wraith Prism cooler, just as I had left them some six years earlier when putting together this system. The plan was to reuse the same cooler, given the similarity of the processors.
As mentioned, I don't often do PC hardware stuff so I was feeling a bit apprehensive about the whole operation. The internet had given me a few tips and, on the whole, it seemed straightforward enough. As suggested, I had run the PC beforehand for some time to keep the CPU warm to facilitate detaching the cooler. However, after I had unplugged and unscrewed the Wraith Prism, I went in to carefully tug it off the processor. Lo and behold, the whole thing came off the socket, with the socket's locking arm still in the down position. The old paste had hardened suffiently to firmly glue the CPU to the cooler. No CPU pins had visibly been bent during the forced unseating.
I figured I might as well screw the whole thing in again and redo a heating run. At this point, though, I had forgotten all about the socket's locking arm, probably because it was hidden under the cooler. I just screwed the cooler and CPU combo back down, plugged in the power cables, and... nothing happened. The PC was not powering on at all.
Either the CPU had been damaged, or it was not being seated properly due to the locking arm being down. I then remembered another tip from the internet, unscrewed the cooler, and took it to the bathroom to be heated with a blow dryer. After all, enough heat should allow the old paste to release its grip. I was surprised by how quickly the dryer can heat up the metal structures of the cooler. Also, I had to find a way to stop the fan from spinning in the blowing air without burning my fingers in the process. The cooler's power cable jammed in the blades seemed adequate. Finally, I had to resort to shoving a kitchen knife under the corner of the CPU and gently prying it upwards. Eventually, the old paste had had enough and the CPU popped off, clanking into the sink. I wasn't too concerned about it as I had pretty much written it off at this stage, and didn't have further use for it anyway.
Sighing in relief, I then proceeded to clean the old paste off the cooler using a piece of microfiber cloth and the isopropanol. Note to self: put on some protective gloves when handling pure alcohol — my fingertips were getting mighty dry after a few rounds of scrubbing. A few minutes later, the cooler was sparkling clean and I was feeling more optimistic about the venture.
I then realized that I should've RTFM earlier, as I was wondering which way the new CPU should go into the socket. It was at this point that I realized the locking arm was pretty integral to the seating of the chip. Oh well. The AMD installation guide pointed out the correct orientation, and then it was just a matter of popping in the CPU, pushing down the arm, a quick squeeze of the new thermal paste, and the cooler could be screwed back on top. The final complication was trying to keep the cooler somewhat level while screwing in its four corners.
Finally, it was time to plug in the cables and try booting the PC. Fearing I had damaged the socket while unseating the old processor, I pushed the power button, and... everything was lighting up and the PC started booting! The first boot got me worried, though, as the fans started cycling between minimum and maximum, and the monitor remained black. I double-checked the monitor cables (one may have been loose) and rebooted the system. Again, the strange fan speed cycling, but now the BIOS screen came up and informed me about a hardware change. It had correctly detected the 5700X.
The desktop PC is somewhat unique in that this kind of thrilling adventures are even possible. Your laptop and certainly your phone likely will not be serviced by the end user. I wouldn't want to be swapping and upgrading parts on the regular, but the flexibility remains a great strength of the platform.
Running some benchmarks, the new CPU seems to be performing 60%–70% faster than the old one, so it has been a very nice upgrade indeed. Even bloated crapware like the Epic Games Launcher now opens reasonably quickly. Of course, my CPU cycles will be primarily spent on compiling code — faster build times are always welcome!
CC-BY-SA 4.0