61–70 of 142 posts
Earlier quoted context omitted.
While we're at it, one should use “Mi”, not “M”. M is still 1000 * 1000, while Mi is 1024 * 1024. That amount of sloppiness in any other engineering discipline would just finish you off immediately.
After using many Unix tools that have this convention, I'm ok with 10 M referring to 10 1024 1024 bytes (10 MiB), contrasted with 10 MB meaning 10,000,000 bytes.
Earlier quoted context omitted.
I think you have a good point. The whole reason for standards (like SI units) is so that people don't need to guess or interpret. I don't get why this was downvoted.
A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…
So a 1 megabyte file (as reported by the file system) is actually 1048576 bytes, which technically - sorry, I mean pedantically - speaking, is 1 mebibyte.
To make matters worse, disk manufacturers use the decimal prefixes, so our nice 1 terabyte drive is 931 mebibytes, but is reported by the file system as 931 megabytes (not MiB).
Finally, memory manufacturers use the binary prefix, so 1 megabyte of RAM is actually 1 mebibyte (1048576 bytes).
A bit of a mess, no?
All the above is, IMHO, a consequence of imprecision. If we get used to being loose with our terminology, we risk carrying that attitude over into our work product, with sometimes regrettable results.
So I'll continue to strive to be pedantic (translation: precise).
Earlier quoted context omitted.
A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…
While we're at it, one should use “Mi”, not “M”. M is still 1000 * 1000, while Mi is 1024 * 1024. That amount of sloppiness in any other engineering discipline would just finish you off immediately.
Then again, maybe doing more simple math by actually using one's brain wouldn't hurt either. :)
Edit: And yes, I'm aware that you'll never get the converted speed of what is written on the network device's box. But sometimes it's nice to have an upper limit you can compare to at least.
Earlier quoted context omitted.
A bit isn't a divisible unit, so nobody is going to be confused as to whether "mb" stands for "millibits". As for the capitalization of "b", if we're going to be pedantic then we should say "Mo" for "megaoctets", since "byte" is, as far as IEEE standards are concerned, of ambiguous length. But I think we can trust people enough to not spend too long puzzling over whether "mb" means megabytes or megabits, just as we c…
While we're at it, one should use “Mi”, not “M”. M is still 1000 * 1000, while Mi is 1024 * 1024. That amount of sloppiness in any other engineering discipline would just finish you off immediately.
Earlier quoted context omitted.
I said explicitly in my comment that I don't think this is some grand conspiracy. I don't think Xcode makes big files to use up disk space. I think Apple just has little incentive across the entire ecosystem to use less storage or use storage more efficiently. Afaik bitcode is so that Apple can rebuild binaries for different target architectures (e.g. new models of phone, watch, et c) without source developer interac…
Bitcode does not allow cross-architectural builds. This is a common misconception. IR (& bitcode) includes architecture and platform-specific ABI. What it does allow is for better optimizations as the LLVM backend optimizer improves.
This appears to be bitcode. It probably means they just starting making use of more metadata or something that is now included in the bitcode. Bitcode also now deliberately trades off size vs speed and includes indexes used for LTO, etc. They could be including those. You should almost always expect bitcode to get beat by "llvm-dis|xz", because the goal of bitcode is not to be the most compact possible format, but in…
It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1
Specifically to those who don't use iTunes Connect, this page is titled "Estimated App Store file sizes for Build", and the (?) callout says "This is the amount of disk space the app will take up on the customer's device."
Earlier quoted context omitted.
It does seem to be affecting the end user binary size: http://imgur.com/a/FEgQY These numbers were all around 60mb on Xcode 8.2.1
No, that's the wrong side of the store you are looking at :) That's the size as uploaded by the developer, not downloaded to user.
Earlier quoted context omitted.
These numbers matched exactly to what is currently in the AppStore for the last release we have ready for sale
As it says below "You need to look at the download size on the end user device, not the binary size in iTunesConnect." Is that what you are doing? Because otherwise, it includes the bitcode size. (i don't pretend this makes sense. only that it is :P) In any case, i would still bet more heavily on it being displayed wrong than anything else. If i was to increase the binary size of first party apps at google by even 1%…
This appears to be bitcode. It probably means they just starting making use of more metadata or something that is now included in the bitcode. Bitcode also now deliberately trades off size vs speed and includes indexes used for LTO, etc. They could be including those. You should almost always expect bitcode to get beat by "llvm-dis|xz", because the goal of bitcode is not to be the most compact possible format, but in…
This appears to be bitcode. It probably means they just starting making use of more metadata or something that is now included in the bitcode. Bitcode also now deliberately trades off size vs speed and includes indexes used for LTO, etc. They could be including those. You should almost always expect bitcode to get beat by "llvm-dis|xz", because the goal of bitcode is not to be the most compact possible format, but in…