3 ms·

The 8GB M1 versions don't have enough RAM for a lot of dev work, doing pretty ordinary things created a lot of RAM pressure when I had one. I later bought Max w

The 8GB M1 versions don't have enough RAM for a lot of dev work, doing pretty ordinary things created a lot of RAM pressure when I had one. I later bought Max with 64GB, and that has been brilliant. I gave up on the idea of using Docker almost immediately. Early on there were major issues if you were targeting x86-64 systems code in C++. A lot of common tooling was broken for months on end. Time has solved some of these problems but ultimately I wrote code to support native ARM targets as first-class code citizens. There was a significant learning curve (I was not fluent in ARM64 ISA) but now that everything is ported, running native, and the tooling has finally started to catch up, it works pretty smoothly and I don't have much to complain about. The x86 emulation has limitations so native is the only way to go for many things, and you'll still want to test some code on real x86 server hardware. That said, the latest OS on (at least) the M1 is noticeably buggy. Lots of behavioral artifacts that I wouldn't expect. Not sure if it is the hardware or the software, or both. Nothing catastrophic, just annoying.

mmcnl 4y ago
Why did you give up Docker? How is that brilliant? Docker is brilliant, giving that up is not brilliant.
- jandrewrogers 4y ago
  I work on large-scale systems software, mostly high-performance database and analytics products. Docker's sole function in that kind of environment is easy replication of dev and functional test environments. No one deploys this type of software in Docker or similar due to the performance implications. Docker was a convenience, it wasn't providing anything critical. I replaced it with a small set of shell scripts and similar. For this type of development, the number of external dependencies you have is very small. Aside from the compiler, build system, and testing, the number of third-party libraries linked into a release can usually be counted on one hand. Again, for good reason. Basically, I am doing what I did before Docker, writing a small set of scripts that can perfectly reproduce the environment where I need it. This is made much easier because modern build systems have good dependency management built-in so writing those scripts is a lot less involved.
systemBuilder 4y ago
In my wife's case, the 16GB macs don't even have enough memory to drive a 4K display. Her mac goes crazy, overheats, fan at 100%, everything slows to molasses, piece of junk. And it's x86.
- sliken 4y ago
  Yes, well known, same here on an mbp-16" i9. For whatever reason the m1 mac's are crazy different. They feel like they have more ram (maybe a faster NVME for swap?), they run the fan crazy less, some don't even have fans (the mac book air). I've heard it speculated they use hardware assist for compression for swap. In any case don't assume that a 16GB M1 will feel like a 16GB x86-64.
- jandrewrogers 4y ago
  The x86 macs are noticeably inferior in a lot of ways to the new Apple Silicon macs. I have both. That is as much how macOS runs on x86 versus the M1 as it is the underlying silicon. There has long been an impedance mismatch between what Intel is optimizing for and what Apple wants their silicon to be optimized for, and I think the M1 is an expression of that gap. There are things that Intel is still better at, but Apple largely doesn't care about those things.

mmcnl 4y ago

Why did you give up Docker? How is that brilliant? Docker is brilliant, giving that up is not brilliant.

jandrewrogers 4y ago
I work on large-scale systems software, mostly high-performance database and analytics products. Docker's sole function in that kind of environment is easy replication of dev and functional test environments. No one deploys this type of software in Docker or similar due to the performance implications. Docker was a convenience, it wasn't providing anything critical. I replaced it with a small set of shell scripts and similar. For this type of development, the number of external dependencies you have is very small. Aside from the compiler, build system, and testing, the number of third-party libraries linked into a release can usually be counted on one hand. Again, for good reason. Basically, I am doing what I did before Docker, writing a small set of scripts that can perfectly reproduce the environment where I need it. This is made much easier because modern build systems have good dependency management built-in so writing those scripts is a lot less involved.

systemBuilder 4y ago

In my wife's case, the 16GB macs don't even have enough memory to drive a 4K display. Her mac goes crazy, overheats, fan at 100%, everything slows to molasses, piece of junk. And it's x86.

sliken 4y ago
Yes, well known, same here on an mbp-16" i9. For whatever reason the m1 mac's are crazy different. They feel like they have more ram (maybe a faster NVME for swap?), they run the fan crazy less, some don't even have fans (the mac book air). I've heard it speculated they use hardware assist for compression for swap. In any case don't assume that a 16GB M1 will feel like a 16GB x86-64.
jandrewrogers 4y ago
The x86 macs are noticeably inferior in a lot of ways to the new Apple Silicon macs. I have both. That is as much how macOS runs on x86 versus the M1 as it is the underlying silicon. There has long been an impedance mismatch between what Intel is optimizing for and what Apple wants their silicon to be optimized for, and I think the M1 is an expression of that gap. There are things that Intel is still better at, but Apple largely doesn't care about those things.