News for hackers. Stuff that matters.
Re:Apple Silicon M1: A Developer's Perspective by hmottestad on Saturday November 28, 2020 @12:22PM (#25238853)
Personally can’t wait to upgrade. The point about 16GB being on the low side was nice to get confirmed. There has been a lot of conspiracy on 16GB being plenty enough, but as a developer I know that to future proof my next machine I would really like 64GB. I already have 16GB of ram on my 8 year old MacBook Pro.
Re:Apple Silicon M1: A Developer's Perspective by samcheng on Saturday November 28, 2020 @12:37PM (#25238958)
I suspect there are a lot of us in that boat, with 5-to-8-year-old Macbook Pros. Apple really missed the mark with the intervening generation, by removing useful features and replacing them with features unattractive to developers.

Maybe this big leap in processor / thermal / battery life (and a revision back to proper keyboards) will be enough to get us to switch! I think 64GB (or at least 32GB) would be a nice sweetener.

Re:Apple Silicon M1: A Developer's Perspective by DrBazza on Saturday November 28, 2020 @01:08PM (#25239218)
I'm still running a late 2013 Macbook, now on Big Sur. The battery life is now about 3-4 hours even if I'm doing dev work, but otherwise it's still pretty good otherwise, for a 7 year old laptop. I had a Sony Vaio back in the early 00s, and it started with running XP 'ok', and then... Vista, which made it dog slow. My point being that I'm surprised that a 7 year old laptop is still "good".

A new laptop isn't critical to my work at the moment, so I'm happy to wait for an M2, if that's what it will be called. Looking at Apple timelines a new chip tends to be 1-2 years apart, and I'm fine with that.

I'm also reluctant to give up Magsafe, or at least have to buy a magnetic USB C connector.

Re:Apple Silicon M1: A Developer's Perspective by Tagbert on Saturday November 28, 2020 @01:51PM (#25239561)
With Apple moving forward rapidly on this architecture change, I expect them to upgrade the processors at a faster pace than normal. They are 6 months into a 2 year plan to migrate all of their systems. I would expect the next version of M chips in 6 to 12 months with higher RAM limits and faster GPU. That would be targeted at their other laptops and the iMac. It will likely take longer for them to get to something that can be used in the Mac Pro and maybe an iMac Pro where RAM and GPU needs are even greater.
Re:Apple Silicon M1: A Developer's Perspective by michaelmrose on Saturday November 28, 2020 @03:07PM (#25240096)
I wonder if they will simply provide a motherboard with more cpu slots for M1 v2 for higher end machines like iMac/iMac Pro/Mac Pro.
Re:Apple Silicon M1: A Developer's Perspective by glangdale on Sunday November 29, 2020 @01:33AM (#25243370)
It seems unlikely. There's a lot of extra complexity with multi-socket and there's no actual reason for them to do this. I'm not a CPU designer but they might do the equivalent of what you said with a chiplet design like AMD (Intel also has announced plans to eventually get to chiplets).
Re:Apple Silicon M1: A Developer's Perspective by potemkinhr on Saturday November 28, 2020 @05:45PM (#25241194)
The ages old AMD philosophy, shovel more cores at it? With such low TDP it might work
Re:Apple Silicon M1: A Developer's Perspective by samcheng on Saturday November 28, 2020 @02:24PM (#25239786)
I love Magsafe as well. However, if the new laptop battery truly lasts all day, then it won't be nearly as important. I'll just charge the laptop overnight, and treat it like my phone.

Maybe they will integrate wireless charging into the laptops soon?

Re:Apple Silicon M1: A Developer's Perspective by billti on Saturday November 28, 2020 @02:37PM (#25239872)
I would agree, with the exception that I’ve noticed really CPU heavy things like builds that take > 1 min still complete a lot faster when plugged in, even on a full battery. I assume they still need to throttle somewhat when only running on battery.
Re:Apple Silicon M1: A Developer's Perspective by macintux on Saturday November 28, 2020 @04:28PM (#25240714)
Air? Or do you have a fan?
Re:Apple Silicon M1: A Developer's Perspective by trynewideas on Saturday November 28, 2020 @06:17PM (#25241408)
It's not throttling, per se; the M1 prioritizes its efficiency cores when off mains power, and the performance cores when on mains power.

When unplugged, it engages the performance cores as little as possible. You should be able to run `powermetrics` on an interval while running a high-intensity task to confirm; the performance cores pin first when on mains, then ramp up the efficiency cores, and the opposite happens on battery.

It's a big difference because the efficiency cores max out at about 2W draw, and the performance cores max out at around 18W. There's a big incentive in battery life to rely on that behavior.

I'm not sure yet if it's tunable, macOS doesn't make that a transparent behavior where you can just tweak it at will.

The Air will throttle if under full load long enough, but it's still mostly just ramping down the performance cores to stay cool.

Re:Apple Silicon M1: A Developer's Perspective by Obi_Juan_Kenobi on Saturday November 28, 2020 @06:37PM (#25241537)
Magsafe seems less an issue now.

With a true 'all day' battery, you'll probably only plug it in at a desk where tripping or knocking things over isn't an issue. While travelling, you just charge it at night or when you aren't using it. Much more like smartphone usage.

How many people are aching for a magsafe phone charger?

Re:Apple Silicon M1: A Developer's Perspective by ldrndll on Saturday November 28, 2020 @01:56PM (#25239600)
If it’s any consolation the battery life on my 6 month old 16” MBP is also 3-4 hours when I’m doing work. The CPU is an absolute dog, and the fans kick in under the faintest of loads.
Re:Apple Silicon M1: A Developer's Perspective by desiarnezjr on Saturday November 28, 2020 @09:05PM (#25242361)
Same battery life here. :( Love the actual machine but the battery life is a disappointment.

Just got a 16MB 500GB M1 Air and so far everything is at least as snappy as the 16" Pro, and battery looks like a full 8 hour day + so far... it's a keeper I think. I also find the keyboard a bit nicer to type on personally than on the 16", so accuracy is up.

Re:Apple Silicon M1: A Developer's Perspective by square_usual on Saturday November 28, 2020 @11:39PM (#25242954)
Moving from a 2015 Air to a 2018 Pro felt like a downgrade since the battery life was much, much worse. I have to keep the power plug around if I want to work on the couch for any amount of time.
Re:Apple Silicon M1: A Developer's Perspective by dragonwriter on Saturday November 28, 2020 @11:42PM (#25242958)
Isn't the Pro line optimized for power, while the Air line is optimized for mobile utility (incl. battery life)?
Re:Apple Silicon M1: A Developer's Perspective by Rillen on Sunday November 29, 2020 @09:51AM (#25245389)
Thats crazy; Are you using it as your daily primarly work horse?

I can't imagine how you got used to the performance you have right now. Either you are not doing anything with your device or you would hugely benefit of upgrading at least every 3 years or so.

Re:Apple Silicon M1: A Developer's Perspective by z6 on Saturday November 28, 2020 @02:47PM (#25239944)
Yeah, maybe. It's still hard for me to envision giving up a 2014 and 2015 MBP. They both work flawlessly and don't compromise on any of the useful features, like having USB A ports, SD card slot, MagSafe, no touchbar, reasonably sized touchpad and so forth.
Re:Apple Silicon M1: A Developer's Perspective by novok on Saturday November 28, 2020 @08:33PM (#25242196)
My plan is to get a min spec M1 air as a personal laptop and then get the real 14"/16" M2 version with touch, more cores and more RAM later on. As one apple employee told me, you never really want to get a v1 with apple anything if you can.

With the 'touchification' of big sur, it seems pretty likely apple is going to release some sort of convertible macbook or maybe something iPad style. Or maybe iPads can start running macos?

Work laptop will get upgraded to an M1 one way or another anyway.

Re:Apple Silicon M1: A Developer's Perspective by alphabettsy on Saturday November 28, 2020 @01:02PM (#25239164)
I keep seeing this, but the performance gains and real-world, Docker and all, battery life are significant in the 16 inch MacBook Pro‘s more so than even my 2017 15”.
Re:Apple Silicon M1: A Developer's Perspective by smnrchrds on Saturday November 28, 2020 @04:13PM (#25240601)
I don't even want to imagine how expensive the 64 GB version is going to be.
Re:Apple Silicon M1: A Developer's Perspective by claudeganon on Saturday November 28, 2020 @12:56PM (#25239120)
I upgraded to a high spec MacBook Pro 16 after the M1 model was announced. I need solid virtualization support for Windows and Linux now, plus Big Sur seems kind of a mess from the design and privacy side of things. I'll probably wait 3-5 generations until everything with Apple Silicon is worked out to upgrade again, maybe get an Air as a device for travel if things look stable sooner.
Re:Apple Silicon M1: A Developer's Perspective by woahAcademia on Saturday November 28, 2020 @12:47PM (#25239043)
That's pretty much how I feel too.

Nothing enticing because my computer is lightning fast and this means having to use the Apple ecosystem.

It's almost like Apple has a culture of forcing people to do things the hard way, just so it feels rewarding when it's done. Gamifying the experience?

Re:Apple Silicon M1: A Developer's Perspective by heisenbergs on Saturday November 28, 2020 @01:39PM (#25239481)
The reason it has been stuck to 16GB is precisely because Intel mobile chips did not support any more than that up until a year ago. So rather than blaming Apple, it should rather be placed on intel.

I don't think expecting more than 16GB of ram for entry level Apple laptops should be expected.

The low amount of ram, energy inefficiency and plateauing performance are the exact reason why Apple is moving away from Intel and onto a platform where they can control their own destiny.

Re:Apple Silicon M1: A Developer's Perspective by Tuna-Fish on Saturday November 28, 2020 @01:57PM (#25239612)
The actual reason the M1 Macs cap out at 16GB is that they use LPDDR4, and that on a 128-bit bus caps out at 16GB. Assuming that they move to LPDRR5 as it becomes available (hasn't Apple generally been pretty quick on the uptake on new RAM standards?), that limit goes up to 64GB.
Re:Apple Silicon M1: A Developer's Perspective by DCKing on Saturday November 28, 2020 @02:22PM (#25239767)
It's a conservative spec for sure given the rest of the M1. Samsung has shipped their own LPDDR5 in the Galaxy S20 since February. Maybe production capacity is still too limited.
Re:Apple Silicon M1: A Developer's Perspective by Tuna-Fish on Saturday November 28, 2020 @04:36PM (#25240767)
I believe that Samsung co-designed the memory with their interface block, and then it was effectively codified as the standard. Most other companies had to wait for the standard to be formed before they could start work on their IP. This gave Samsung a huge head start.
Re:Apple Silicon M1: A Developer's Perspective by ustolemyname on Saturday November 28, 2020 @02:02PM (#25239635)
Intel's fault? Uhm, they've had some misses recently, but your statement about RAM support is incorrect.

The 7200u supports 32GB or RAM. That chip is over 4 years old and nothing special. Not sure how long that's been supported, I didn't feel like looking further back.

https://ark.intel.com/content/www/us/en/ark/products/95443/i...

Re:Apple Silicon M1: A Developer's Perspective by X-Istence on Saturday November 28, 2020 @02:22PM (#25239764)
It does not support LPDDR4... which is something Apple has been targeting because it uses less power.
Re:Apple Silicon M1: A Developer's Perspective by rgbrenner on Saturday November 28, 2020 @05:00PM (#25240929)
The just released 16" macbook pro has DDR4. They clearly aren't married to LPDDR.
Re:Apple Silicon M1: A Developer's Perspective by X-Istence on Saturday November 28, 2020 @07:27PM (#25241838)
Probably because they couldn't keep waiting. It also means the 16" MacBook Pro goes through battery life at high speed from experience.
Re:Apple Silicon M1: A Developer's Perspective by AzN1337c0d3r on Sunday November 29, 2020 @01:51AM (#25243418)
Apple switched to DDR4 when the 2018 Macbook Pros were released which allowed them to support 32 GB of RAM.

The rated battery life of the Macbook Pro didn't change between 2017 and 2018.

Re:Apple Silicon M1: A Developer's Perspective by X-Istence on Sunday November 29, 2020 @02:41AM (#25243621)
The rated battery life may not have, but the actual, real world experience battery life certainly has. Speaking as the user of a. 2019 MacBook Pro with the DDR4 that I use for work.

I find myself scrambling for a power supply way more often than I ever did with my 2017 15" MacBook Pro.

Even with the older battery in the 2017, with more cycles, I get a longer battery life out of it than the 2019.

Re:Apple Silicon M1: A Developer's Perspective by AzN1337c0d3r on Monday November 30, 2020 @01:36PM (#25257228)
And I have the complete opposite experience. Pinning this on the switch from LPDDR3 to DDR4 seems like a very weak conclusion. Especially when it is known that processors and displays are the largest consumers of energy and the 2019 MacBook Pro boosts way higher with more cores than the 2017.
Re:Apple Silicon M1: A Developer's Perspective by ustolemyname on Saturday November 28, 2020 @02:42PM (#25239909)
Huh, so they did. TIL.
Re:Apple Silicon M1: A Developer's Perspective by rgbrenner on Saturday November 28, 2020 @04:59PM (#25240919)
Apple sells the 16" macbook with 64gb of DDR4. It's their decision whether to use LPDDR or DDR. They choose LPDDR for some and DDR for others.

Pretty incredible to blame another company for a decision that was made inside Apple. Especially for a chip that was designed from scratch in apple, and therefore has no Intel constraints.

Re:Apple Silicon M1: A Developer's Perspective by ffggvv on Saturday November 28, 2020 @01:57PM (#25239605)
what do you mean entry level laptops? they don’t offer more than 16 and their base ram is only 8...

and how are the macbook pro or mac mini entry level laptops?

Re:Apple Silicon M1: A Developer's Perspective by djrogers on Saturday November 28, 2020 @04:36PM (#25240765)
The mini is their cheapest computer. The Air has been their entry level laptop for the last several generations. The 13” Pro has had 2 versions since 2016 - a low-end 2 port model, and a higher end 4 port model.

Every device with an M1 available today is Apple’s lowest-end (and least expensive) offering.

Re:Apple Silicon M1: A Developer's Perspective by krzyk on Saturday November 28, 2020 @02:40PM (#25239889)
> The reason it has been stuck to 16GB is precisely because Intel mobile chips did not support any more than that up until a year ago. So rather than blaming Apple, it should rather be placed on intel.

That is not true, example CPU I had in my old laptop: https://ark.intel.com/content/www/pl/pl/ark/products/78939/i...

Supports 32GB RAM, released in 2014.

The reason some older laptops didn't have more RAM was twofold: 1. Either the BIOS wasn't written with such support 2. There were no RAM sticks big enough (no 16GB in a single SO-DIMM) so you could have 2x16 - but there are currently since a year or two, SO-DIMMs with 32GB RAM, so you could easily reach 64MB in a laptop.

Re:Apple Silicon M1: A Developer's Perspective by npunt on Saturday November 28, 2020 @03:04PM (#25240076)
GP means LPDDR3 support which capped out at 16gb on intel, which was because their 10nm lines with LPDDR4 were delayed years. It was always possible to use regular DDR but for laptops the low power variant is important.
Re:Apple Silicon M1: A Developer's Perspective by FireBeyond on Saturday November 28, 2020 @05:21PM (#25241042)
... and yet they use DDR4 (not LP) on at least one of their laptop lines.
Re:Apple Silicon M1: A Developer's Perspective by npunt on Saturday November 28, 2020 @10:39PM (#25242758)
Yes they do on the 16”, after years of complaints from users who didn’t understand the constraint, and which they added the maximum allowable battery size to (~100wH), and it still only lasts 3-4h in moderate use.
Re:Apple Silicon M1: A Developer's Perspective by AzN1337c0d3r on Sunday November 29, 2020 @01:52AM (#25243423)
They switched it on the 2018 15-inch and it didn't change the battery life at all.
Re:Apple Silicon M1: A Developer's Perspective by saagarjha on Saturday November 28, 2020 @07:56PM (#25241983)
Seemingly out of necessity?
Re:Apple Silicon M1: A Developer's Perspective by krzyk on Sunday November 29, 2020 @07:56AM (#25244879)
GP didn't write about LPDDR3, just a vague statement that intel cpus didn't support > 16GB RAM, which I proved was wrong.
Re:Apple Silicon M1: A Developer's Perspective by Toutouxc on Saturday November 28, 2020 @01:00PM (#25239153)
I don't know. I did what I'm currently doing (Ruby on Rails dev) on a 4 GB MacBook Pro until last year and it was fine.

At the moment I have around 2 GB free on my 8 GB Linux machine with a webserver, MariaDB, a JetBrains IDE, Slack and Firefox running. It would be easy and dirt cheap to increase the RAM to 16 or 32 GB but I'm too lazy to even order it and open the machine up since I have never felt the need to have more.

I'm just saying this so that people like me remember that they're still professionals and their work is valuable even if they don't need 64 GB of RAM.

Re:Apple Silicon M1: A Developer's Perspective by lumost on Saturday November 28, 2020 @01:06PM (#25239203)
IDEs such as IntelliJ can easily consume 8GB of memory on a moderately sized project of 100k loc. If one has to open multiple such projects or work on a very large project in the million loc scope then you’ll run out of 16 GB really fast.

Folks working with data intensive applications often need to trade off writing code to page data in and out of memory during development with larger dev boxes.

Re:Apple Silicon M1: A Developer's Perspective by Jtsummers on Saturday November 28, 2020 @01:43PM (#25239516)
100k LOC would be, let's be generous, about 8 million characters (80/line average, which is high). 8GB of RAM for 8MB of input seems excessive to me. What's going on with that IDE that it needs so much for something so small? Even if that were 8 million distinct tokens/symbols in the input, that's still 1KB/token of memory consumed.
Re:Apple Silicon M1: A Developer's Perspective by CapsAdmin on Saturday November 28, 2020 @01:57PM (#25239613)
I would assume code analysis.

8gb still sounds a bit excessive but given how long java stack traces can be maybe it's not so strange.

Re:Apple Silicon M1: A Developer's Perspective by aledalgrande on Saturday November 28, 2020 @07:14PM (#25241763)
Except that is only what an IDE does at the very minimum. An IDE loads plugins, provides intellisense, documentation, potentially loads documentation of all the libraries, watches files, displays Git status, parses your code for syntax highlighting etc. etc.

You're not opening a TXT file with 100K lines in it.

Re:Apple Silicon M1: A Developer's Perspective by z3t4 on Saturday November 28, 2020 @03:14PM (#25240155)
For every key stroke a new immutable string is created with the content of the file/state. Plus data structure for AST/static analysis of every file in the project including dependencies. Plus another copy of the file for rendering with syntax highlight. One would think all this copying of data is very inefficient, but computers are good at moving data around. The most costly is rendering the glyphs.
Re:Apple Silicon M1: A Developer's Perspective by wulfklaue on Sunday November 29, 2020 @09:17PM (#25250114)
> IDEs such as IntelliJ can easily consume 8GB of memory

Sound more like a Jetbrain ( IntelliJ company ) problem. Used to develop on PHPstorm ( another Jetbrain ) product ( same software in the background ) and the slow startup's, 2GB+ memory eating for relative small projects, crashes way too much, expensive as hell for what it does ( especially with the license change years ago ) ...

Eventually switched to Visual Studio Code and while people whine how Electron is memory inefficient, its like 1/6 the memory usage of PHPstorm, with only a few features missing.

Even on a 32GB PC system, i barely use 16GB ( and WSL2 is eating up a lot with a lot of docker images. And its not really docker, just Linux cache eating up memory ). Not a issue on a Mac that does not need a VM like layer.

Its about priorities sometimes. If people keep upgrading their memory, developers/companies simply push the responsibility to the clients and do not bother with spending time on optimizing.

If people start leaving software product on the way side for being just horrible inefficient messes, then maybe a bit of focus will come back to actually optimizing products! You will see Jetbrain change tune, when VSC etc keep eating its market share.

Re:Apple Silicon M1: A Developer's Perspective by fayten on Saturday November 28, 2020 @06:18PM (#25241419)
I have worked on a large 10 year old Spring application with well over 300k loc for 3 years. I don't recall Intelij ever exceeding 3gb of ram. Intelij reminded snappy on my Macbook Pro 2015 with 16gb of ram and an i7.
Re:Apple Silicon M1: A Developer's Perspective by CapriciousCptl on Saturday November 28, 2020 @03:01PM (#25240048)
Same experience here. My Ubuntu laptop accidentally doubled-down on 16gb RAM because I forgot to give it a swap partition (whoops). It hangs maybe once a month under a VS Code, PostgreSQL, FastAPI/Python, React workload. Basically, not annoyingly frequently enough for a lazy person like me to change the partition table. The same workload on my 7 year old Ubuntu desktop with a swap partition on a fast SSD very rarely ever hangs.

Certainly some devs need more than 16gb, but they know who they are. And you know who they are because, well, they love telling you :).

Re:Apple Silicon M1: A Developer's Perspective by CraigJPerry on Saturday November 28, 2020 @03:55PM (#25240464)
You could create a swap file rather than a dedicated partition:

    $ dd if=/dev/zero of=/swap bs=1M count=8192
    $ mkswap /swap
    $ swapon /swap
    $ echo "/swap swap swap defaults 0 0" >> /etc/fstab
Re:Apple Silicon M1: A Developer's Perspective by laurencerowe on Saturday November 28, 2020 @05:35PM (#25241131)
You don’t need to reparation, just configure it to use a swap file. If you set swappiness to zero it will only use it when out of ram.
Re:Apple Silicon M1: A Developer's Perspective by barkingcat on Saturday November 28, 2020 @04:39PM (#25240790)
you can always add a swap file ... that makes your life easier so you don't have hangs, and you don't need to repartition.

I use swap files all the time with things like raspberry pi's and such because I don't want to mess with the sd card partitions, but still from time to time it's good to have that swap fallback since the memory onboard is limited.

Swap files are super easy to set up, take up no "brainpower" and disk space is cheap these days.

Re:Apple Silicon M1: A Developer's Perspective by matwood on Saturday November 28, 2020 @01:49PM (#25239552)
I think it really depends on if your development workflow requires VMs/Docker or not. It seems crazy to me to have a bunch of containers running using 4-8gb each, but for many that is how they develop.
Re:Apple Silicon M1: A Developer's Perspective by e12e on Saturday November 28, 2020 @01:29PM (#25239407)
Curious - why intellij for ruby on rails? (I'm quite happy with (neo) vim (qt) and a slew of (mostly) tpope's plug-ins.
Re:Apple Silicon M1: A Developer's Perspective by leipert on Saturday November 28, 2020 @03:26PM (#25240236)
Not GP, but RubyMine (the Ruby IDE from JetBrains) has decent support for refactoring things, type interference, executing single tests with a debugger, etc.
Re:Apple Silicon M1: A Developer's Perspective by notreallytrue on Saturday November 28, 2020 @01:11PM (#25239239)
The system is swapping a lot but the SSD is giving you the impression that 8GB are enough
Re:Apple Silicon M1: A Developer's Perspective by Wowfunhappy on Saturday November 28, 2020 @01:24PM (#25239358)
> but the SSD is giving you the impression that 8GB are enough

If it works, is it impression or reality?

Re:Apple Silicon M1: A Developer's Perspective by robgibbons on Saturday November 28, 2020 @01:45PM (#25239528)
Swap isn't great for SSD lifespan. Probably not a drastic loss, but nonetheless not helping its longevity.
Re:Apple Silicon M1: A Developer's Perspective by notreallytrue on Saturday November 28, 2020 @01:46PM (#25239532)
Impression is in the realm of reality, it's simply deceptive

Jetbrains that fits in 8GB of memory with slack and Firefox leaving 2GB free it's not happening

I used to code on 800×600 monitors professionally

If I say today that they are more than enough to work, I expect to be taken to a mental institution

Re:Apple Silicon M1: A Developer's Perspective by spyridonas on Saturday November 28, 2020 @02:55PM (#25240002)
Until the SSD dies. It's recommend to disable swap if you have an ssd
Re:Apple Silicon M1: A Developer's Perspective by rsynnott on Saturday November 28, 2020 @01:11PM (#25239246)
I mean, it depends what you do. I have 16GB on my personal laptop, and essentially never swap, but the 16GB on my work machine is painful for large Scala projects.

As always, for some people 16 GB will be fine, for some it won’t.

Re:Apple Silicon M1: A Developer's Perspective by wsc981 on Saturday November 28, 2020 @02:32PM (#25239842)
8 GB when using Android emulator and Xamarin has been a pain for me, but my iMac doesn't have a SSD drive (it's got an Apple Fusion drive). The machine was swapping all the time, e.g. when alt-tabbing between Android emulator and Xamarin.

After upgrading to 24 GB the machine became very usable.

I wouldn't ever want to go back to 8 GB. Perhaps 16 GB might be usable for iOS and Xamarin development, especially if the Android emulator can run in some kind of HAXM [0] mode, but for ARM processors ... not sure if that's possible right now. I'm sure the SSD also makes a big difference compared to my Fusion drive right now.

Still it feels safer (more future-proof) if the machine has a bit more memory than 16 GB.

---

[0]: https://github.com/intel/haxm/wiki/Installation-Instructions...

Re:Apple Silicon M1: A Developer's Perspective by jmnicolas on Saturday November 28, 2020 @03:22PM (#25240209)
FWIW on Windows a simple Flutter project in Android studio + the emulator + a couple browsers open and I'm hovering around 14 to 16 GB of ram.

There's no way I'm buying a 16 GB computer now, 32 GB is a minimum to be future proof.

Re:Apple Silicon M1: A Developer's Perspective by megablast on Saturday November 28, 2020 @04:09PM (#25240569)
An ssd would have made a bigger difference. And xamarin?? I’m so glad I don’t have to use that anymore.
Re:Apple Silicon M1: A Developer's Perspective by wsc981 on Saturday November 28, 2020 @08:55PM (#25242304)
Honestly Xamarin is pretty nice these days if ones’ aim is to share a lot of code between iOS and Android projects while still being able to provide a native experience.
Re:Apple Silicon M1: A Developer's Perspective by melling on Saturday November 28, 2020 @01:25PM (#25239367)
I bought a 16GB MacBook Pro in 2013. I can’t imagine that I wouldn’t want more in 2021. I might have my next laptop until 2028.

As always, more RAM extends the usefulness of a computer.

Re:Apple Silicon M1: A Developer's Perspective by Abishek_Muthian on Saturday November 28, 2020 @01:23PM (#25239353)
If Virtual Machines are essential part of the workflow then 16GB is out of question IMO, could get away with Tiny Core Linux/Lubuntu on a VM to some extent but when getting some serious work done on both host and guest; 16GB would be a bottleneck for VM.
Re:Apple Silicon M1: A Developer's Perspective by cataphract on Saturday November 28, 2020 @12:35PM (#25238944)
64 GB is already the minimum for building big projects like V8 on 16 cores (e.g. on the 3950X)
Re:Apple Silicon M1: A Developer's Perspective by aledalgrande on Saturday November 28, 2020 @12:39PM (#25238978)
I'm curious about this, because I read some posts e.g. https://medium.com/computed-comparisons/garbage-collection-v... that say memory management and bandwidth are so fast, you actually need a lot less memory than on Intel.

Edit: not my opinion, just what I found on the internets, not sure why the downvotes if it invites discussion.

Re:Apple Silicon M1: A Developer's Perspective by fulafel on Saturday November 28, 2020 @12:47PM (#25239049)
That article seems confused and/or misinformed on many points, on many levels.

As for the GP cited use case, there's no plausible way in which the compilers involved in the V8 build process would start using less memory due to their memory management machinery getting magically transformed by the hardware from tracing GC to refcounting GC, even assuming LLVM had been using tracing GC in the first place.

(Also the tracing GC memory overhead claims originating in Apple's marketing copy are way hyperbolic, modern tracing GCs don't require double storage used in "mark and sweep" GCs)

Re:Apple Silicon M1: A Developer's Perspective by aledalgrande on Saturday November 28, 2020 @12:54PM (#25239099)
Makes sense yeah! I guess anything non native would work like that.
Re:Apple Silicon M1: A Developer's Perspective by fulafel on Sunday November 29, 2020 @03:15AM (#25243744)
Many memory hungry apps on Apple - Web browsers, compilers, photo/video editing, games, dev tools like vscode/electron/Jave IDEs/emacs/databases - are in this category.
Re:Apple Silicon M1: A Developer's Perspective by steipete on Saturday November 28, 2020 @12:40PM (#25238994)
I’ve read the reports but I’m not seeing this. Normal workflow and already over 11 GB that swaps.
Re:Apple Silicon M1: A Developer's Perspective by chongli on Saturday November 28, 2020 @12:50PM (#25239065)
I think the point is that memory bandwidth and SSD bandwidth and latency have improved so much that M1-based Macs are really fast at swapping. Combine that with compression (which macOS has done for a long time) and I could imagine iPadOS-like performance.

For normal users (such as people not compiling V8), swapping may be virtually unnoticeable.

Re:Apple Silicon M1: A Developer's Perspective by kllrnohj on Saturday November 28, 2020 @02:28PM (#25239818)
Macs have had fast SSDs for a while and as you say compression has also been done for a long time. M1 made no difference whatsoever to memory usage. The posts similar to above seem to just be an attempt to fanfic-justify what's an actual regression for some.

For many people 16GB is absolutely enough, and Apple had to start somewhere. But if 16GB wasn't enough for you yesterday, it isn't enough for you now.

Re:Apple Silicon M1: A Developer's Perspective by chongli on Saturday November 28, 2020 @04:49PM (#25240846)
The reviews of the M1 MacBook Air and Pro show a dramatic increase in SSD read/write speeds over the 2020 Intel models.
Re:Apple Silicon M1: A Developer's Perspective by kllrnohj on Saturday November 28, 2020 @06:48PM (#25241605)
Do you have a link? MKBD just said it was "slightly faster" than his comparison system and the numbers for the M1 appear to be around 3GB/s reads and 2.7GB/s writes in disk speed test, which is pretty typical of a last generation NVME drive (current pcie gen4 drives are hitting 7GB/s reads & 5GB/s writes)
Re:Apple Silicon M1: A Developer's Perspective by chongli on Sunday November 29, 2020 @08:27AM (#25245003)
which is pretty typical of a last generation NVME drive

Those numbers are about 2-3x as fast as what my 2020 Intel-based MacBook Air gets.

Re:Apple Silicon M1: A Developer's Perspective by kllrnohj on Sunday November 29, 2020 @10:12AM (#25245538)
Then sounds like Apple put some really garbage SSDs in the 2020 Intel-based Air, not sure what you're looking for here?

But 2-3x won't change swap from grinding to a halt to perfectly smooth, either. It's still over 20x slower than RAM.

More significant for swap usage though is random reads and read latency, neither of which are going to be particularly impressive on the M1's SSDs. You need something like Optane to make that a compelling case.

Re:Apple Silicon M1: A Developer's Perspective by foldr on Saturday November 28, 2020 @03:11PM (#25240133)
It's possible that M1 has enabled the use of better memory compression algorithms.
Re:Apple Silicon M1: A Developer's Perspective by rsynnott on Saturday November 28, 2020 @01:16PM (#25239287)
I do wonder if it’s taking advantage of the cheap CPU power and memory bandwidth to be much more aggressive about memory compression. That could reduce swapping for some workloads, though probably not a v8 build.
Re:Apple Silicon M1: A Developer's Perspective by shawnz on Saturday November 28, 2020 @04:22PM (#25240663)
What do you mean exactly? It is normal for swapping to happen even if you are using less than the physical memory, so as to trade rarely-used RAM for frequently-used disk cache which improves overall throughput
Re:Apple Silicon M1: A Developer's Perspective by aledalgrande on Saturday November 28, 2020 @12:44PM (#25239016)
Thanks for reporting! Bummer, for me I think I will have to wait for an M2.
Re:Apple Silicon M1: A Developer's Perspective by jcelerier on Saturday November 28, 2020 @02:30PM (#25239828)
> There has been a lot of conspiracy on 16GB being plenty enough

I bought a computer with 16GB in 2011 and around 2015 it was already lagging quite a bit due to swap - switching to 64GB in 2016 was day and night, I don't have to fear launching arbitrarily many jobs anymore.

Re:Apple Silicon M1: A Developer's Perspective by beowulfey on Saturday November 28, 2020 @05:32PM (#25241110)
RAM speeds have also increased quite a lot since 2011. Do you find yourself hitting 64GB of memory use often?
Re:Apple Silicon M1: A Developer's Perspective by jcelerier on Saturday November 28, 2020 @05:45PM (#25241193)
not 64, but I'm regularly hovering in the 40-45 gigs pool
Re:Apple Silicon M1: A Developer's Perspective by square_usual on Saturday November 28, 2020 @11:44PM (#25242966)
That seems like a very specific use case. I've had 8GB until 2016 and 16GB since and I've never had to deal with that much memory use.
Re:Apple Silicon M1: A Developer's Perspective by AzN1337c0d3r on Sunday November 29, 2020 @01:54AM (#25243431)
Anyone who runs a couple of VMs or a ton of docker containers is going to run into memory problems.

And that's not an uncommon use-case amongst the developer crowd which has a lot of overlap with HN.