401–410 of 661 posts
Cool! So now (or at least soon-ish) I can get my hands on some dirt cheap, practically never used M1 hardware on eBay to play around with? I wonder if Apple is familiar with the Osborne effect[1]. [1] https://en.wikipedia.org/wiki/Osborne_effect
Earlier quoted context omitted.
Apple isn't harnessing magic here. The opportunity for competition exists, but everyone else is just sitting on their asses while Apple's chip team puts in the work. If you want to beat Mx, you have to think outside the box, just like how Apple thought outside of x86. That being said, I do enjoy the shift to ARM as the dominant arch. x86 has far too many decades of cruft behind it. I don't think Apple will take over…
ARM also has some decades of cruft attached to it.
To my understanding, this is quite unlike AMD64 (ie, Intel's current 64 bit ISA licensed from AMD) - which extended x86.
Earlier quoted context omitted.
> Just imagine Apple releasing the Mx chips for server infrastructure. Intel ought to be sweating bullets now. As a developer, I'm sweating bullets. Imagine a future where Apple is the only serious platform left on mobile, server and desktop, then developers can forget about starting that next disruptive startup and instead they will become just second-class Apple "employees" with contracts similar to Uber drivers.
With all the respect in the world, I think the complete lack of that happening at all this century should make you pause and reflect on why you think it's even remotely possible. I'm happy to be wrong, but I think you're buying too much into the SV/media fearmongering on a handful of companies whose main business is actually just attention economics.
This would be quite an accelerated timeline if Apple ships its second-generation M-series chip only eight months after the first. Typically, they’ve followed a sort of six-month tick-tock pattern for the A-series, launching a new major revision in the fall with the new iPhone, and launching an “X” revision in the spring with new iPads. I think most observers have been expecting an “M1X” for Apple's first pro-oriented…
Earlier quoted context omitted.
Apple isn't harnessing magic here. The opportunity for competition exists, but everyone else is just sitting on their asses while Apple's chip team puts in the work. If you want to beat Mx, you have to think outside the box, just like how Apple thought outside of x86. That being said, I do enjoy the shift to ARM as the dominant arch. x86 has far too many decades of cruft behind it. I don't think Apple will take over…
I'm really hoping one of the other chipmakers jumps on the RISC-V bandwagon. There's substantial potential to do to ARM what ARM did to x86 here. If Intel/AMD/Qualcomm/Broadcom/whoever started talking about a significant RISC-V offering I'd be buying as much of their stock as I could.
Earlier quoted context omitted.
I've only read very rare workloads actually be constrained by 16GB on the M1, what use case do you have that you know will be hampered on a M1?
My current laptop has 64 GB. Could probably be fine with 32, but I'm seldom under 20 in usage. I run certain services locally in Docker, and then have 5+ instances of IntelliJ for various stuff open, some of them running a java server or node building the frontend, and others on my team may be running Android+iOS simulator at the same time as well. I could alter my usage patterns and work with less. But people not us…
As a data point: I am running node + iOS Simulator (along with XCode + VSCode + Chrome with 50+ tabs) setup on M1 16GB and it works fine, I also keep them running while I take a break to play a LoL match. Works great for me.
Earlier quoted context omitted.
The Apple's second version of everything is always the one to get. The first version is always exciting, but usually comes at some large expense. - iPhone 2 had 3G and was so much better than 1 - iPad 2 was about 3 X slimmer/lighter than 1 Lots of other examples if I though about it.
The original Intel MacBook comes to mind as well - released with the (32-bit) Core Duo processor in May 2006 - replaced with (64-bit) Core 2 Duo model in November 2006 It only was supported through to 10.6 Snow Leopard as 10.7 Lion went 64-bit only
Earlier quoted context omitted.
Apple isn't harnessing magic here. The opportunity for competition exists, but everyone else is just sitting on their asses while Apple's chip team puts in the work. If you want to beat Mx, you have to think outside the box, just like how Apple thought outside of x86. That being said, I do enjoy the shift to ARM as the dominant arch. x86 has far too many decades of cruft behind it. I don't think Apple will take over…
You would need to think quite far out of the box and hit it to be able to beat a vertically integrated, extremely well-funded, and successful company.
Earlier quoted context omitted.
Give Mac software a few years to "catch up" and everything will feel just as slow as usual (and I'm not even joking, so far, software was always excellent at undoing any advancements in hardware very quickly).
If you don’t run Electron apps, even an older Mac will fly. My 2015 is still astoundingly fast, it just doesn’t have Chrome bogging it down.
We have taken careful care in order to write fast and memory friendly javascript if possible, avoiding using slow features of the language (the list is long, but things like forEach loops, ineffecient data structures etc) and taking care to profile and optimize.
Result is an application that feels almost as fast as native and doesn't really consume so much memory even, although we are doing canvas based graphics realtime.
My suspection is that many web-developers (and thus, qualified to developer for Electron) just don't have the tenacity or background to write efficient code.
You can write slow-ass molasses javascript code very easily. Just take somebody who has done webdev for maybe like 2 - 3 years and doesn't have any other deeper CS background. Watch what kind of memory inefficient and slow code structures, especially with javascript where you don't really understand how heavy an operation like map() can be in worse cases, or where you are creating copies of your data multiple times for example, and voila, you have a slow-ass memory-hogging electron application.
Maybe I should do a blog post about how our Electron -application is performing just to show people that you can write fast code using javascript also. But it takes skill and time, and maybe in this current day what matters is just cranking out builds that work somehow.
Earlier quoted context omitted.
We don't even need to wait for that. Right now web developers are creating the new generation of web-based apps that will consume everything that M1 can give and more. In fact these apps already existed, they were just largely ignored because they're so power-hungry (just look at electron and similar stuff).
Where is that inefficiency supposed to come from though? I mean there are four big inefficiencies that came with JS. 1. Garbage collection and minimum runtime Garbage collection decreases memory efficiency, browsers need a certain minimum amount of resources to render a page, no matter how complicated leading to 500MB RAM text editors like Atom and worse once you open files. Similar problems plague Eclipse and Intell…
Look at multi-platform products like ms office and how slow they run on a Mac. I suspect because there is a translation layer to bridge win32 calls to Mac equivalents. And that seems like it would be point 5 on your list.