Hacker News Reader

Comment by meindnoch | Hacker News Reader

So binary sizes are going to double?

This is more like supporting AVX512 than a whole separate architecture. If you have to target both old and new devices from one binary, you do a runtime feature check and call the corresponding code.

That is certainly more code, but not double. You only need it for the parts of the code that are both (a) bottlenecks worth optimizing and (b) actually benefit by using the new instructions.

And, in modern desktop software, code is a tiny bit of the total size of the application - visual elements tend to occupy a lot more space than code.

In games, perhaps. In basically nothing else though. And I have 0 games on my M1, yet my apps folder is 23 GB. Docker, Edge, and SketchUp all 2+ GB, despite not having almost any UI to speak of.

(Edit to remove iMovie from the list, as it has GB's of "Transitions" and "Titles" that I really should just delete)

No, in pretty much everything.

All three examples you gave have substantial UI and other bundled assets. For example, the Docker Desktop app is about 2GB on my computer, yet included assets make up at least 1.2GB, and a further 600MB is a bundle containing the UI, which itself is about 100MB of binaries.

If you actually open those bundles (as they're called on macos) and take a look inside, you'll see that they don't even contain all of their assets, anyways, often linking to frameworks contained in ~/Library

This is a very layperson explanation, btw, but I assure you that "in modern desktop software, code is a tiny bit of the total size of the application" is a very true statement.

There are cases where the app icon is larger than the compiled code in some apps and if you include a couple images for things like “here is how you give my app access to record the screen” that can also account for a large part of your app bundle.

Yes, game assets really take it to another level but it’s been my experience that even apps without a lot of UI still have their images making up a lot of the app bundle size.

ARMv9 is just ARMv8.5 with 4 extra extensions. It's not a complete overhaul like the ARMv7 to ARMv8 change was.

It's more comparable to x86 chips with AVX-512 and chips without AVX-512. 99% of your code is the same, but the compiler will generate SSE, AVX, and AVX-512 variants and choose the correct one based on the CPU.

Are there any extensions that ARMv9 is required to have? I'm looking through the reference manuals and those 4 extra extensions are all marked as "OPTIONAL" for ARMv9.

I believe it requires the ARMv8.5 instruction sets (but maybe some of those are optional too?)

>> So binary sizes are going to double?

If you're already supporting 2 arch it will only increase by 50 percent to support a 3rd ;-)

IME Mac binaries are much smaller than Windows for your average third party software. I don’t know why.

Windows binaries often seem to have excess statically linked libraries.. even though they are called DLLs which is supposed to mean dynamic. They might be loading it dynamically but they still seem to have decided to include their own private copy.

I've even seen windows binaries have multiple different versions of the same DLL inside them, and it's a well known DLL that is duplicated multiple places elsewhere.

All OSes/Apps do this but maybe a lot of Mac apps do it a little less. (I don't even have any real statistical idea how common this is with windows apps either)

From having worked on Windows, OSX, and Linux desktop software over the years there's a few factors at play off the top of my head:

- Windows DLLs don't usually have strong versioning baked into the filename. On OSX or Linux, there's usually the full version number baked in (libfoo.so.3.32.0) with symlinks stripping off version components. (libfoo.so, libfoo.so.3, libfoo.so.3.32) would all be symlinks to libfoo.so.3.32.0 and you can link against whichever major/minor/patch version you depend on. If your Windows app depends on a specific version it's going to be opening DLLs and querying them to find out what they are.

- Native OSX software (not Electron) seems to depend much less on piles of external libraries because the OSX standard library is very rich and has a solid history of not breaking APIs and ABI across OS versions. While eg CoreAudio is guaranteed to be installed on an OSX install and be either compatible or discoverably-incompatible, the version of DirectSound you're going to have access to on Windows is more of a crapshoot.

- Windows apps (except for the .Net runtime sometimes) are often designed for longevity. A couple of months ago I installed some software that was released in 1999 on my Windows 11 machine and it just worked. Bundling up those DLLs is part of why they work.

- Linux apps can rely on downstream packaging to install the necessary shared libraries on demand, generally speaking. Linux desktop apps distributed as RPMs or DEBs can "just" declare which libraries they need and get them delivered during install.

On Windows isn't it possible to have the OS deal with the DLL version issue by using side-by-side assemblies? I believe in practice that's only ever used by DLLs provided by the OS, but I thought it was possible to apply the mechanism to other DLLs as well.

Maybe? I haven’t really done a deep dive into that. You’d still have to bundle them along with the installer though since there isn’t a good way to request 3rd-party DLLs (heck, there isn’t even a good way to request a specific version of MSVCRT…)

The most impressive I've seen has been four-arch support in a single bundle: PowerPC, 32-bit x86, 64-bit x86 and ARM64.

Openstep had as a default 4 hppa, sparc, i386 and m68k - I often built stuff on a HP for production use on Intel and 68000 boxes and I think they also had unreleased m88k as well at the same time so internally might have had five way binaries.

And you'd like to think the binaries are still not the largest component of an app contributing to the file size. But who knows these days.

Its the static-linking of the Swift runtime - it’s incredibly inelegant.

The Swift runtime is not statically linked on Apple’s platforms

(Anymore)

I don't think it ever was?

I do also believe it wasn't ever technically "statically linked", but the dynamic libraries were separately distributed as part of every app (and so I'd think the semantic slippage acceptable given the context). This has tons of advantages, but prevented Swift from being used in Apple libraries.

Right; I was using loose and casual language there; I meant "bundling", not literally statically-linked.

-----

I said "statically-linked" because the first thing that came to mind was go-lang's morbidly obese executable binary sizes, and mentally walked to iOS app sizes.

How so?

Reply on news.ycombinator.com