ENOUGH ALREADY! The shipping date on the Airs is slipping past mid December here in Europe. I can't stay that hyped for that long.
Apple Silicon M1: Black Magic Fuckery
581–590 of 1001 posts
Re: Apple Silicon M1: Black Magic Fuckery
#582Earlier quoted context omitted.
Does "Linux run stable" on existing Macs? Not that I know of, 15 years after the introduction of Intel Macs. You might have to wait forever.
Isn't this mostly about driver support? I'm not a hardware guy, but it's hard to understand why it's so difficult to reverse engineer something like the touchpad driver. Isn't it just a matter of measuring the IO and reproducing it? I mean how has MS done this for bootcamp?
Well, it doesn't seem to happen in practice so it's either hard or there are no incentives to do it, or both.
But that's the reality we live in.
Re: Apple Silicon M1: Black Magic Fuckery
#583Earlier quoted context omitted.
> I don't think this is an issue for Docker. They can run an ARM64 Linux VM instead of the current x86 one, and then use QEMU to run x86 Docker containers within it if they want. If youre at the point where you have to run a container running inside an emulator inside a VM on an ARM Mac then you should just get an x86 linux machine and enjoy performance and native support for containers.
This is not what running an ARM64 Linux VM means.
Are you just talking about using an ARM64 container your root container? This kind of breaks the point of docker if you're running on x86 in the cloud, doesn't it? You're no longer developing in your exact deployment environment, which is one of the key benefits of docker.
Re: Apple Silicon M1: Black Magic Fuckery
#584Earlier quoted context omitted.
It'll be interesting what happens in a couple of years if server side gets more mixed with ARM as well.
Unless AWS starts selling their graviton CPU, whose going to create chips for the arm server market? The volumes are huge and the margins are tiny, which is not something Apple was ever interested in.
AMD could still revive the K12 and apply their Zen 3/4/5 experience to it.
Re: Apple Silicon M1: Black Magic Fuckery
#585I'm typing this from a 2014 i7-4980HQ 15" MBP. This machine would have been replaced in 2017 but I wasn't impressed with that years model. I had planned to upgrade in 2020 but the announcement of the M1 basically quashed that. I've been on this planet long enough to know when Apple changes course like this the old architect is already obsolete. 68k -> PPC -> x86_64 -> ASi. The PPC G5 got exactly 1 OS upgrade (10.5) b…
> Apple users know you pay an Apple tax and a v1 tax
I expect the v1 tax this time around is that the externals are exactly the same as the Intel machines. Compared to what laptops like the Dell XPS 13 are doing with larger screens in smaller bodies, the current Air and 13" Pro designs are getting a bit long in the tooth now.
I expect next year we'll see new design for the iMac with the M1X, or whatever the bigger variant will be called, as the current version is absolute dinosaur at this point, but I also think we'll see an updated design for the Air and 13" Pro (maybe 14" like how the 15" went to 16"—it would certainly help differentiate the Air and Pro a little more).
Re: Apple Silicon M1: Black Magic Fuckery
#586PSA: however impressive the M1 hardware is, you're still going to be stuck using OSX, playing in Apple's walled garden and being subjected to their awful policies. I'll gladly join the groupie crowd once Linux runs stable on it.
I honestly can’t think of any Apple policy that restricts what I run on my Mac. I haven’t upgraded to Big Sur yet, and maybe I just don’t rely on anything yet that’s against their policies and will be mad when I hit that point. What concretely are the awful policies that are restrictive on Mac that you’re thinking of?
When a new "App" is installed on Big Sur (and I think this was on Catalina too), there is a check to see if the developer ID has been tagged as providing malware. When Big Sur launched, there was a glitch and the servers hung, leaving a lot of users in a bit of a lurch.
It's easy to disable the check and a lot of software never gets checked for other reasons.
Re: Apple Silicon M1: Black Magic Fuckery
#587Earlier quoted context omitted.
It'll be interesting what happens in a couple of years if server side gets more mixed with ARM as well.
Linus Torvalds was and is probably still right that unless developers have the same breed of processor (not just AArch64 but the actual chipset, for example) on the bench it'll probably never be particularly prevalent server-side. That and Apple presumably dream of not letting developers touch anything without going through their stack, so no touching the hardware for you. For example, I believe Apple expose Performa…
> The wider point being that Apple will probably never let you run Linux on their hardware, and your server will probably not be running MacOS either.
I agree the idea of running Apple Silicon in the cloud seems far-fetched, but at the same time, if Apple actually does achieve the best price/performance processors in the world, it almost seems like a failure of the market if they do not also serve the cloud market.
Re: Apple Silicon M1: Black Magic Fuckery
#588I don't quite understand how 'retain' and 'release' can be more memory efficient on Apple Silicon than x86.... I can understand how they can be more efficient from a performance standpoint in terms of more efficient reference counting, but I don't understand how that translates to less memory usage which is apparently what's being argued... ? Unless on x86 some of the 'free's when the ref counts hit 0 were being batc…
I believe the idea was that reference counting was more memory efficient than other forms of garbage collection, such as copy collectors and mark and sweep collectors which commonly make up generational garbage collectors. Languages like Java also do not yet support stack-allocated value types outside a few primitives like integers, and heap allocations are both slower and less space efficient due to the indirection…
You do get stack-allocated value types in languages like Go or C#, though, so these shouldn't be subject to the same limitations that Java is.
Re: Apple Silicon M1: Black Magic Fuckery
#589Earlier quoted context omitted.
If you don't have issues with paying a lot for hardware, why don't you buy Mac Pro?
A machine that wont outperform the new mini $6000 16 cores 32GB of ram least powerful gpu on the list 2GB of storage $8,799.00 28 cores 48GB of ram same gpu 4GB of storage $14,699 MSRP on a 2020 Toyota Corolla $19,600 AMD Ryzen Threadripper 3970X 32-Core 3.7 GHz Socket sTRX4 $2,629.90 Cost of the same basic GPU about $219 Cost of complete system equivalent to the almost car priced mac about 4200. 9k-15k isn't "a lot"…
Exactly this, I was fine with the Mac Pro until 2012, it was a little more expensive than PCs but not much outrageously so (maybe 30% more, that's a tax I was fine paying given the OS and that it was quite a well built machine).
The new Mac Pro is 3-4x the price of a machine built around AMD having equivalent performances. I'm building a Threadripper for exactly this reason. Most of the issue is Intel vs AMD and the fact that AMD's Threadrippers are an amazing deal when it comes to performance per dollar and that Apple has an aversion to offering decent GPUs
Re: Apple Silicon M1: Black Magic Fuckery
#590This is fascinating: > Retain and release are tiny actions that almost all software, on all Apple platforms, does all the time. ….. The Apple Silicon system architecture is designed to make these operations as fast as possible. It’s not so much that Intel’s x86 architecture is a bad fit for Apple’s software frameworks, as that Apple Silicon is designed to be a bespoke fit for it …. retaining and releasing NSObjects i…
Taking that as true for a moment, I wonder what other programming languages get a benefit from Apple's silicon then? PHP et al. use reference counting too, do they get a free win, or is there something particular about Obj-C and Swift?
Not the specific thing mentioned in the article. There is other hardware that optimizes Objective-C specifically, but it’s a branch hint.