1. 53
  1.  

  2. 11

    I wonder what they’re going to do for Mac Pro class of hardware.

    Trying to fit more RAM, more CPU cores, and a beefier GPU all into one package doesn’t seem realistic, especially that one-size-fits-all chip isn’t going to make sense for all kinds of pro uses.

    1. 7

      It’s going to be interesting to see what they do (if anything at all) with a 250W TDP or so. Like, 64? 128? 196 cores? I’m also interested in seeing how they scale their GPU cores up.

      1. 2

        There’s NUMA, though Darwin doesn’t support that right now I think.

        1. 2

          Darwin does support the trashcan Mac Pros, right? They have two CPUs, and that’s a bona fide NUMA system.

          1. 3

            Trashcan Mac Pros (MacPro6,1) are single CPU - it’s the earlier “cheesegrater” (MacPro1,1-5,1) that are dual CPU. I do believe they are NUMA - similar-era x86 servers certainly are.

            1. 1

              Ah, you’re right, sorry for the confusion.

        2. 2

          Trying to fit more RAM, more CPU cores, and a beefier GPU all into one package doesn’t seem realistic

          I have heard this repeatedly from various people – but I don’t have any idea why this would be the case. Is there an inherent limit in SOC package size?

          1. 1

            I’d assume they’ll just support non-integrated RAM - as there will be space and cooling available.

          2. 9

            M1 is apparently a multi-die package that contains both the actual processor die and the DRAM. As such, it has a very high-speed interface between the DRAM and the processors

            But it’s not like they’re using HBM on an interposer, this is basic dual channel (LP)DDR4(X) whatever, which doesn’t magically become much faster if you put it on the package. They could clock it a bit higher but no vendor is going full on overclock mode 4800MT/s CL16 out of the box :D

            The benefit of sticking to RC is much-reduced memory consumption

            But that’s only for regular app object junk. 8K video frames, detailed 3D scenes, machine learning matrices, and gigantic ELF files full of debuginfo won’t become smaller due to this difference, and on a big system machine with serious usage, memory is mostly occupied by that kind of stuff.

            uncontended acquire-release atomics are about the same speed as regular load/store on A14

            Ooh, that’s cool.

            1. 5

              this is basic dual channel (LP)DDR4(X)

              How do you know? After all, alternative memory interfaces like HBM exist, and Apple specifically claims “high-bandwidth, low-latency memory” memory.

              But that’s only for regular app object junk.

              Right, but it’s the “regular object junk” that’s problematic.

              8K video frames, detailed 3D scenes, machine learning matrices

              …tend to be nicely contiguous blobs of bytes that can be moved from the (2x faster) SSDs to memory really, really quickly. > 2GB/s on my current Intel MBP.

              ELF files full of debuginfo

              Mach-O, not ELF. Those binary files tend to not be all that large, and debug information is stored externally (and even if internal, it’ll be in a section that would at most be mapped, but not read into memory until actually needed).

              1. 1

                How do you know?

                First – the animation in the Special Event where they show a rendered mock-up of how the package is formed. Just checked again, the timestamp is 07:40. Even though it’s a mock-up, you can clearly see the standard shape of a DDR memory chip, itself already covered in its own black plastic with text on it. (HBM stacks look like bare silicon dies located within about a millimeter of the main die, connected by an interposer, not by a regular PCB. Look at an AMD Vega GPU, for example.)

                Also the fact that the price has not increased compared to the previous models. (HBM is really expensive.)

                Now let’s look at anandtech – of course, it is LPDDR4X indeed :) (upd: also the aforementioned slide is there, no need to open the video)

                (upd: also yeah “8x 16b channels” – same width as the typical desktop 2x 64b)

                Mach-O, not ELF. Those binary files tend to not be all that large, and debug information is stored externally

                I’m not on macOS these days, so I’m not talking about macOS specifics, I’m just giving examples of things consuming big memory on big computers.

                The Firefox debug build’s libxul.so requires >14G memory to link, and the result is >2G (which is larger than the WebAssembly address limit so the new symbolicator used in the Firefox Profiler can’t load it, haha).

                1. 1

                  From the anandtech article:

                  as well as doing a microarchitectural deep dive based on the already-released Apple A14 SoC.

                  The micro-architectural discussion is of the A14, not the M1. And even that doesn’t say that the memory is any kind of DDR, in fact the only mention of DDR I could find is in describing one of the comparison machines for the benchmarks.

                  Firefox

                  XUL is 110MB on macOS, and as I mentioned, debug information is kept to the side. I do remember running out of memory, a LOT, trying to link lldb on Linux (in a Docker container). There seem to be some pathologies in that neck of the woods, partly with code bloat and partly with linker performance. Friends helped me out with configuring the build and switching to a different linker (lld or gold), that solved the issue. Well, it was still “problematic”, but it did link.

              2. 4

                But that’s only for regular app object junk. 8K video frames, detailed 3D scenes, machine learning matrices, and gigantic ELF files full of debuginfo won’t become smaller due to this difference, and on a big system machine with serious usage, memory is mostly occupied by that kind of stuff.

                I currently run a Dell XPS 15 with 32 gb of RAM, and I would say that my app usage rarely contains anything you listed. Most of the RAM being used in my machine is regular app object junk, and seeing a large performance jump in managing these allocations would be very beneficial to me at least.

                While working, I almost always have these apps open:

                • 1-3 projects open in IntelliJ
                • 1-3 terminals
                • Slack or Telegram
                • TeamSpeak
                • 10-40 tabs open in FireFox

                On Fedora 32, these apps usually aren’t overtaking my resources, but I am very curious to see the performance difference with the shiny new M1.

                1. 1

                  IntelliJ is implemented in Java, which is equally memory hungry regardless of the OS. Similarly, Slack is an Electron app, which is Chrome under the hood (C++ and Javascript). Firefox also is C++/Javascript.

                  I’m assuming all of those apps use Objective-C APIs (though how they interact with system APIs is really a blind spot for me), so there’s some impact there but I suspect the bulk of their memory use comes from things (Java objects, JS objects) that are similar in size regardless of the platform.

                  Fwiw, both my work (Mac OS, 4 years old) and home (Linux 3.5 years old) laptops currently have 16GB, and it’s mostly ok. Even with 100 Chrome tabs, I have a gig or 2 free. When I’ve run into problems, it’s been analyzing a 8+GB java heap, or running Intellij + Docker DB + multi gig batch process. Optimizing “ordinary app junk” won’t help those use cases (they all manage memory in a way that has nothing to do with Apple’s optimizations to their libraries).

                  For a new laptop I’d plan on getting 32GB. I’m ok with what Apple released this week because I assume that something with 32GB will come sometime next year. But it doesn’t meet the needs of some developers.

                  1. 1

                    Really depends on what you’re doing, for me 16GB is a constant struggle and my buddy oomkiller annoys me to no end.

              3. 4

                The benefit of sticking to RC is much-reduced memory consumption. It turns out that for a tracing GC to achieve performance comparable with manual allocation, it needs several times the memory (different studies find different overheads, but at least 4x is a conservative lower bound). While I haven’t seen a study comparing RC, my personal experience is that the overhead is much lower, much more predictable, and can usually be driven down with little additional effort if needed.

                This is highly questionable: Yes, RC requires less memory, but it’s baseline is much slower than GC.

                Plus, if one created new GCed systems these days, one certainly wouldn’t go with a language in which ~everything (e. g. Java) is a reference to be traced and collected.

                GC is fine, but if references make up more than 20% of your memory consumption, you are doing it wrong.

                1. 7

                  I wonder if the “much slower” part applies when you have some measure of control over how long the operations take. Retaining and releasing an NSObject on the M1 is almost 5 times faster than on Intel, and even twice as fast when emulating Intel.

                  Certainly makes it harder to make performance comparisons when the CPUs behave so differently.

                  1. 2

                    I’d expect that these performance improvements to also benefit GC, though not that much and depending on the GC algorithm used.

                2. 3

                  Since I need to run a lot of x86_64 VMs, the M1 isn’t for me yet…but if and when it becomes a viable thing for me, my main concern is going to be thermals. I have a 2019 16” MBP and it just runs hot when plugged into an external monitor. The area above the touchbar is painfully hot to the touch and the fans go full blast at the slightest provocation.

                  I’d like something that isn’t going to melt and doesn’t sound like a jet taking off when I provide a moderate workload…

                  1. 2

                    It’s a bit of a painful one to work through, but this thread on the MacRumors forums has some hints on how to solve the excessive heat when using an external monitor.

                    1. 1

                      Do you need to run the VMs locally? Since we’re all in working-from-home mode, I’ve got my work laptop as my primary machine, but any engineering work is done on a remote VM (either on my work desktop, which is a nice 10-core Xeon, or in the cloud). I basically need a web browser, Office, and a terminal on my laptop. Neither my MacBook Pro nor my Surface Book 2 have particularly great battery life running VMs, so I tend to shut them down when I’m mobile, meaning that the places I’d actually run them are even more restricted than the places where I can connect to a remote VM.

                      1. 1

                        Unfortunately, yeah. The product we ship is itself sometimes shipped as a VM image, and being able to build and tinker locally is a huge timesaver. Maybe in the future, when we’re doing more business in the cloud, it will be different but until then, I’m pretty stuck on x86_64 hardware.

                        1. 1

                          Genuine question, why does it need to be local? I use entr and rsync to keep remote systems in sync on file saves/changes and setup emacs to just run stuff remotely for compile-command. Works a treat and the laptop never gets warm.

                          This lets you edit locally but “do crap” remotely, cloud or not. In my case the “cloud” is really just a bunch of servers I rsync to and then run stuff on via ssh. Yeah you could use syncthing etc… but damned if i’m going to sync my entire git checkout and .git tree when all I need is a few k of source that rsync can keep in sync easily if prodded.

                          1. 1

                            I mean, it’s not a law of the Universe or anything, but it’s significantly easier. These images are fairly huge and while we do have a beefy shared system running test VMs, it’s loaded down enough that there’s not a lot of spare capacity to run 4-6 VMs per user so that system is used for testing only.

                            And then, finally, there’s the issue that I don’t want to have to have two machines when I can make do with one. :)

                            1. 1

                              Gotcha, just curious. I try to keep vm’s off my laptop in general if i can get away with it. Lets me just chill in coffee shops (back when that was a thing) longer on battery power alone.

                              My goal is generally: be kind to the battery, plus with tmux+mosh i can have the remote thing run stuff and then move locations and have things happen in the bg. But if resource constraints is it that makes more sense.

                    2. 2

                      When the Geekbench scores were posted some wanted to see ”real” performance, and I suppose this is it. Seems pretty decent for an entry-level laptop.

                      1. 2

                        Anandtech has run at least part of the SPEC2017 suite on it and the numbers track there, as well. It’s really astonishing.

                        1. 1

                          Most comparable to the score of a Intel Core i7-10850H, with six cores (twelve threads) and a TDP of 45W.

                          1. 2

                            Seems very impressive considering the power draw.

                            Edit: My desktop computer (6700k) is much slower in the same benchmark, 1124 single-core and 5640 multi-core.

                            Sure, it’s a few years old but it’s a 91 W TDP desktop processor!

                            1. 2

                              Yeah, my big machine is a 6950x, and it remains faster in multicore, by a fair amount, but good lord the M1 is like 40% faster single threaded.

                              1. 1

                                Indeed. They’ve got a bit left to match the multi performance of the best Threadripper CPUs, so it’ll be interesting to see what they come up with for the Mac Pro and iMac Pro replacements. “Just” adding 60 more cores is probably not a workable solution…

                                1. 6

                                  This is a 24w SoC. That they’re even within spitting distance of a 250w desktop chip is just stunning.

                                  1. 4

                                    HEDT CPU’s are very different animals compared to these tablet CPUs. We’ll probably have to wait the entire transition period until we know how their desktop CPU’s will perform, but I could probably be convinced to go back to Mac if this level of performance is maintained. :)

                                    1. 4

                                      Note that there’s no requirement for them to build their own cores for desktops. They can easily license the latest Neoverse core from Arm and produce 128-core SoCs with all of their other stuff (secure element, ML coprocessor, and so on). This is one of the advantages of Apple going with Arm: they can license things for any market segments that aren’t their core business. Given how small Apple’s workstation business is in comparison to mobile, it may not be worth their while investing effort in producing a custom desktop CPU core. The N1 scales to 128 cores per socket and, judging from the benchmarks, the versions Amazon is buying are nice and fast. The V1 is announced, is faster, and supports dual-socket machines.

                                      A 128-core per Apple SoC using an Arm IP core would be pretty competitive with their Xeon offerings and Apple marketing would have a lot of fun selling a 256-core desktop.

                                      1. 2

                                        If Apple doesn’t make their own desktop cores, you know they don’t care about that product line at all.

                                        1. 2

                                          No, it means that the profit from that line doesn’t justify investment in a custom core. It makes sense for Apple to design custom low-power cores because they can tune them for exactly the thermal / power envelope that they want and for their workloads to get the best performance per Watt on Apple-specific workloads. What’s their motivation for building a custom desktop core? High-end desktops / workstations are closer to servers then to mobile devices. They depend heavily on NoC topology, cache coherence protocol, cache and memory controller design and so on - things that are much less important when you’re only building 4-8 or cores. Power saving on mobile is about turning off as much as possible and getting into suspend states to maximise battery life. Power saving on the desktop is more about staying within your thermal envelope. These are very different design constraints and Apple benefits a lot in their mobile cores from not having to try to address both.

                                          The Neoverse line has a very good set of IP cores that scale to 128 cores on a single SoC. The question for Apple is whether their in-house design team could beat that performance (and, for a Mac Pro, perf is the only thing that matters: no one buts a Mac Pro because of power efficiency) by a sufficiently large margin that it would increase sales by enough to pay for the cost of the core design. They can get the vertical integration benefits by building an SoC with their own accelerators, secure element, and so on with an off-the-shelf core.

                                          I would be absolutely shocked if the Mac Pro line sold enough to justify the existence of a custom core.

                                          1. 2

                                            If Apple doesn’t make their own desktop cores, you know they don’t care about that product line at all.

                                            You know only that they decided not to build a desktop core. CPU design resources are limited and it doesn’t make sense to target every price point. Apple’s desktops compete in the market against commodity CPUs with much larger volume; they may not be able to make the numbers work.

                                            John Mashey, a founder of MIPS, wrote a great post that explains the economics of CPU design. Search for “Microprocessor economics 101” on this page.

                                            1. 1

                                              I think that’s a given.

                                              Th question is largely “outsource or abandon?”.

                                              1. 1

                                                I am sure that they will have at least a 40-70w part, for the big iMacs. If they don’t replace the Mac Pro, that’s one thing, but I would be very surprised if they don’t roll something out in a year or so.

                                              2. 1

                                                I really doubt they’re going to license a core given how far ahead of the rest of the ARM market they are.

                                                1. 2

                                                  They are doing better than the rest of the Arm ecosystem for performance within a small power and thermal envelope. This is very different from the 200-300W envelope that a high-end Xeon operates in. Don’t assume that they could take their existing core designs and just scale them up. They have a great CPU design team, so I don’t doubt that they could make a custom core that would do well in this space, but I do doubt that the Mac Pro generates enough profit to justify having the team work on such a core.

                                    2. 2

                                      this further improvement is because uncontended acquire-release atomics are about the same speed as regular load/store on A14

                                      The folks working on Windows on ARM64 would do well to pay attention to this. Native Windows apps make heavy use of COM, including the COM-based WinRT, which is based on reference counting.

                                      Disclosure: I worked on Windows at Microsoft, but not on this type of low-level stuff. I regret that I didn’t get to share this article with my contacts on the ARM64 team while I was at Microsoft.

                                      1. 2

                                        This article helps my confidence. I still want more than 16GB in a Mac though (even though I’m content with the PS5 memory as cache, storage as memory story). I expect that by the time we see MacBook Pro 15” and iMac models running Apple SOCs they will be another chip model, M1X, where the memory options can be expanded for those. I hope the 13” gains that option but won’t hold my breath this time.

                                        1. 3

                                          My concerns are things like IntelliJ and Docker which I need for my work. The baseline memory load of either of these is nearly 3 GB.

                                          1. 1

                                            I use Docker for work too, which is a whole different problem given that container images are specific to a processor architecture.

                                            1. 3

                                              You can build cross-platform images with BuildKit/docker buildx.

                                              Also, you can do user-mode emulation of other architectures using qemu. Which is not full system emulation, system calls are translated to the native kernel: https://www.qemu.org/docs/master/user/main.html

                                              Of course, emulation is slower than running natively.

                                              That said, if you rely on Docker, I’d wait a while until the dust settles.

                                          2. 2

                                            Anecdata: My current MacBook Pro (2015 15”) has 16GB and I’ve never noticed that I’ve run out. Perhaps I have and there has been some swapping, but it’s never been something I’ve noticed.

                                            I run typical developer-tinkerer stuff, which means I have at least one DB server running (postgresql certainly), one of the JetBrains IDEs, plus DataGrip, VS Code, XCode, various chat apps speaking different protocols, Firefox with a few dozen tabs and a tree view for them as extension so I can handle that. Spotify and foobar2000. Also sometimes Docker, Inkscape, Acorn… a few things that run in the background and have icons in the menu bar. Little Snitch. I don’t quit apps, so most of these are just around somewhere (swapped out?) all the time.

                                            1. 2

                                              Opposite anecdote: I sometimes wonder if my 2016 15” 16GB macbook pro is just plain fubar’d. I run a similar setup… datagrip, vscode, sublime text, firefox (tons of tabs w/ tab killer and tree view extension), chrome, idle docker, spotify, iterm, and rambox (a chat aggregator, with 5 slack sessions). The machine is aggravatingly slow to use, and this is without running Intellij or minikube, which I often do as well.

                                              Current swap usage is 8GB, CPU ~15% usage, 20% disk free, and merely swapping tabs in activity monitor is sluggish.

                                              I use my desktop whenever possible with 32GB of RAM and a 3700X CPU and it’s 1000% times better w/ respect to performance (brushing aside linux desktop quirks :).

                                              1. 2

                                                That’s quite annoying. It’s hard to diagnose what’s causing this kind of slowness. Do you have any ‘anti malware’ or ‘endpoint security’ type things running? My work laptop has these and their combined ‘help’ kills performance at times.

                                                In case it helps, this is what htop looks like for me at the moment (I’ve just upgraded to Big Sur):

                                                https://i.imgur.com/Fbuc8XN.png

                                                There’s some CPU usage (I’m on battery… looks like I should kill off Discord!) and swap used, but everything’s snappy. In my dock I see I’m running Firefox, Spark, Safari, Activity Monitor, PyCharm, XCode with a small SwiftUI project, Terminal, VS Code (editing an Elixir project, so seems to be running the BEAM for language server purposes), Textual, Discord, Sublime Text, Annotate and Preview. In the menu bar there’s Karabiner Elements, JetBrains Toolbox, Backblaze, Alfred, OneDrive, 1Password, Dropbox, Annotate, AltTab, HookShot, Magnet and Itsycal.

                                                1. 2

                                                  I’m not running any anti-malware, etc software. If I can find the time it might be worth wiping the machine and starting from scratch… I’m sure if I start down that path I’d end up trying Windows+WSL2 (another anecdote - WSL2 runs really nice on a Dell XPS w/ 32GB RAM aside from a couple quirks, but again might be too painful on this 16GB machine).

                                                2. 2

                                                  IIRC, thermal performance tends to dominate for laptops. Do you have any active cooling (eg a fan pad) for it?

                                                  It’s also possible that the thermal paste connecting the heap pipes in your laptop has separated, causing components to run hot even if the laptop is cool.

                                                  1. 1

                                                    I lack any additional cooling. After running a few tests this morning there doesn’t appear to be much throttling going on according to the intel power gadget. The fan does kick into high gear under load but performance stays more or less the same.

                                                    The only time I’ve noticed it massively throttling is when outside in the sun on a warm day.

                                            2. 2

                                              The note about reference counting is something I’d never thought of before and kind of mind blowing if true. I’m not convinced it’s true: a language like Go uses traditional GC but is quite memory efficient also.

                                              1. 10

                                                a language like Go uses traditional GC but is quite memory efficient also.

                                                Not especially, it only seems so in contrast with Java, Python, and Ruby.

                                                1. 7

                                                  The main difference is that Go can reduce heap consumption because it also has a stack. Java, Python, and Ruby only have a heap. This removes a lot of pressure on the GC for smaller objects.

                                                  1. 4

                                                    The other responses seem to be people misinterpreting what your trying to say. I assume that what you’re trying to say is that go has value types in addition to heap allocate objects, which ruby, etc do not.

                                                    However once you get beyond low performance interpreters (ruby, python, etc) languages that are ostensibly based on heap only allocation are very good at lowering values. The core value types in Java, and some of the primitives on JS engines are all essentially lowered to value types that live on the stack or directly in objects.

                                                    Enterprise (ugh) JVM setups, the ones that have long runtimes, are very good at lowering object allocations (and inlining ostensibly virtual method calls), so in many cases “heap allocated” objects do in fact end up on the stack.

                                                    The killer problem with GC is that pauses are unavoidable, unless you take a significant performance, both in CPU time and memory usage.

                                                    1. 1

                                                      are very good at lowering object allocations […]

                                                      Escape analysis – while being an improvement – can’t save the day here, it works – if it works – for single values. No amount of escape analysis is able to rewrite your array-of-references Array[Point] to a reference-less Array[(x, y)] for instance.

                                                      killer problem with GC is that pauses are unavoidable […]

                                                      That’s not really a “killer problem”, not even with the qualification you attached to it. GCs – especially those you mention explicitly – give you lots of tuning knobs to decide how GC should run and whether to minimize pauses, maximize throughput, etc.

                                                      With reference counting pauses are unavoidable: when the reference count to the head of that 1 million element singly-linked list hits zero, things are getting deallocated until the RC is done.

                                                      (Note that things like deferred RC and coalesced RC refer to techniques that try to avoid writing the count, not to the deallocation.)

                                                      (And no, “strategically” keeping references alive is not a solution – if you had such a good track of your alive and dead references, you wouldn’t need to use RC in the first place.)

                                                    2. 5

                                                      Because the other replies try hard to misunderstand you: Yes, you are right about the main difference.

                                                      The main difference is that in Go most stuff can be a value type which mostly keeps GC out of the equation, while in Java, Python and Ruby the GC is pretty much involved everywhere except for a small selection of special-cased types.

                                                      And no, escape analysis – while being an improvement – can’t save the day here, it works – if it works – for single values. No amount of escape analysis is able to rewrite your array-of-references Array[Point] to a reference-less Array[(x, y)] for instance.

                                                      Go’s GC is decades behind e.g. Hotspot, but it’s not that big of an issue for Go, because it doesn’t need GC for everything, unlike Java.

                                                      1. 3

                                                        Java, Python, and Ruby only have a heap.

                                                        Java does have a stack. This is also part of the Java VM specification:

                                                        https://docs.oracle.com/javase/specs/jvms/se15/html/jvms-2.html#jvms-2.5.2

                                                        Some implementations even have stack overflows (though growable stacks are also in-spec).

                                                        1. 2

                                                          I meant in terms of allocations. I should have been more precise.

                                                          Most OOP languages only allocate on the heap. It’s a nice simplification in terms of language design, but it also means that more garbage gets generated. I am sure that advanced JVMs can use static analysis and move some of the allocations to the stack as well but it’s not a default feature of the language like in Go.

                                                          1. 1

                                                            Thanks for the clarification.

                                                            and move some of the allocations to the stack as well but it’s not a default feature of the language like in Go.

                                                            Sorry for being a bit pedantic ;), but it’s not a feature of the Go language, but the default implementation. The Go specification does not mandate a stack or heap (it never uses those terms). It’s a feature of the implementation and it only works if the compiler can prove through escape analysis that a value does not escape (when the value is used as a pointer or pointer in an interface value). This differs from languages which have specifications that separate stack and heap memory and have clear rules about stack vs. heap allocation.

                                                            When I last looked at a large amount machine code output of the Go compiler 3 years ago or so, escape analysis was pretty terrible and ‘objects’ that people would consider to be value types would be allocated on the heap as a result. One of the problems was that Go did not perform any or much mid-stack inlining, so it’s not clear to the compiler whether pointers that are passed around persist beyond the function call scope.

                                                            So, I am not sure whether there is a big difference here between Go and heavily JIT’ed Java in practice.

                                                            What does help in Go is that the little generics that it has (array, slice, maps) are not implemented through type erasure in the default implementation. So a []FooBar is actually a contiguous block of memory on the stack or heap, whereas e.g. ArrayList<FooBar> in Java is just an ArrayList<Object> after erasure, requiring much more pointer chasing.

                                                        2. 0

                                                          Ruby very much has a stack.

                                                      2. 1

                                                        much anticipated R23 Cinebench benchmark

                                                        Woah there’s an R23 already?! I still can’t get used to R20’s existence..

                                                        1. 1

                                                          With increased automation of those reference counting operations and the addition of weak references, the convenience level for developers is essentially indistinguishable from a tracing GC now.

                                                          Are weak references new in apple environments? Hassn’t that been table stakes for a refcounting system for some time?

                                                          1. 3

                                                            Weak references appeared alongside Automatic Reference Counting (ARC) in 2011. Before then you’d just omit the retain that the code which didn’t own the reference would normally have issued when it received it.

                                                            That was Objective-C, of course, but Swift’s ARC is essentially the same.

                                                          2. -1

                                                            Chrome.

                                                            1. 3

                                                              I might counter that it’s not an absolute that it use lots of RAM.

                                                              On my desktop (running a lightweight WM - ie no DE) with Chrome (with maybe 6-12 Tabs open), Emacs, Thunderbird and a couple of Shells (Kitty) running total system memory usage hovers around 1.2GB - 2GB (Depending on what the Chrome tabs are doing of course).

                                                              But then again I use a tab suspending chrome plugin which helps immensely :)

                                                              1. 1

                                                                Are you pointing to Chrome as a specific browser that eats a lot of memory, or to browsers / electron in general?