3 ms·
So binary sizes are going to double?
by meindnoch 2y ago
So binary sizes are going to double?
- phkahler 2y ago>> 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 ;-)
- JKCalhoun 2y agoAnd 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.
- DaiPlusPlus 2y agoIts the static-linking of the Swift runtime - it’s incredibly inelegant.
- saagarjha 2y agoThe Swift runtime is not statically linked on Apple’s platforms
- kenferry 2y ago(Anymore)
- saagarjha 2y agoI don't think it ever was?
- saurik 2y agoI 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.
- DaiPlusPlus 2y agoRight; 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.
- georgeburdell 2y agoIME Mac binaries are much smaller than Windows for your average third party software. I don’t know why.
- ben7799 2y agoWindows 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)
- tonyarkles 2y agoFrom 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.
- Hamuko 2y agoThe most impressive I've seen has been four-arch support in a single bundle: PowerPC, 32-bit x86, 64-bit x86 and ARM64.
- pasc1878 2y agoOpenstep 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.
- HeatrayEnjoyer 2y agoHow so?
- fl0ki 2y agoThis 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.
- rbanffy 2y agoAnd, 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.
- dumbo-octopus 2y agoIn 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)
- parl_match 2y agoNo, 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.
- joshstrange 2y agoThere 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.
- hajile 2y agoARMv9 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.