How to make smaller C and C++ binaries
ptspts.blogspot.com
ptspts.blogspot.com
If you're in an situation where binary size is absolutely critical, then sure. But most people should avoid most of these suggestions.
I'd much rather use CSS instead of Javascript or going back to the days of hacking <table> to get a certain layout.
"Write in C instead of C++" is also clearly not the same as "remove all your code"...
This is in contrast to python or Swift for example, their standard libraries are more “throw-prone”. Building off the previous example Swift’s String.init(contentsOf:encoding:) throws on error on failure.
So in practice, IMO it is usually safe to disable exceptions in C++. Though, I have run into tricky ABI breaks when you link multiple libraries in a chain of exceptions->noexcept->exceptions and so on! You’re of course at the mercy of nonstandard behavior so buyer-beware. I definitely wouldn’t advocate for turning them off -just- for a binary size reduction.
You're just going to end up with an insane amount of error handling only to discover that in the real world, there's likely nothing you can really do anyway.
Using memory that's been allocated but not committed seems like a recipe for disaster.
It can greatly accelerate sparse datastructures.
Also, in a real-time system context, exceptions can be undesirable since they might cause non-deterministic behaviour.
Catching an exception can be surprisingly costly. Did some benchmarking a while ago on the embedded, real-time system I work on and saw that throwing and catching a std::runtime_error had about the same execution time as a rather slow CRC32 calculation (no pre-calculated tables, no special instructions) of a 256 bytes input array. (Of course, this depends a lot of the CPU architecture, compiler, etc.)
* No exceptions, ever
* No RTTI, ever
* Compile with -Os
* Limit STL to the non-allocating, non-throwing parts
* Don't allow heap usage
* Link against the C standard library so you don't get accidental heap allocations from lambdas with large capture specs and static construction and destruction fail to link
* Use alternatives to std::function (which while easy is very large and very slow)
* Limit the use of virtual functions (some people suggest eliminating them altogether but I feel like that's a bridge too far).
* Avoid inlining functions if you're not sure that they reduce down to something trivial. I've saved a kilobyte or two by moving some particularly large, commonly used functions into separate translation units so that the compiler couldn't inline them.
* Look at and track your space utilization commit by commit. If the data segment goes up unexpectedly, revisit what you're doing. You may have unwittingly allocated a big block for something. Similar for the code segment.
You get used to the constraints. Type safety, templates, and compile time programming make it 10 times better than C for the purpose in my experience. The only reason to use C is if your C++ compiler is garbage (which is often true for the tiny low powered processors). But if it's ARM you probably have access to a modern compiler and the only reason to stick with C is inertia.
I've been programming with embedded C++ for ten years and every time I have to poke into the C part of the codebase I end up hating life.
Lambdas themselves never require heap allocation. I guess you meant std::function?
With exceptions disabled you still get a panic (e.g. the program immediately terminates) in places where an exception is thrown, this should be at least as safe as having exceptions enabled.
If people were to listen to your advice, no one would ever post any kind of article on how to achieve certain specific goals, all we'd ever discuss are very generic topics and constantly rehash the same content over and over again. It's good to be able to learn how certain developers manage to accomplish various goals without having someone come along and call that advice terrible.
What are your targets? This was my experience 10 years ago, but today with modern (last 5-6 years) MSVC, GCC and Clang (and even on modern Xbox and Playstation toolchains) my experience has been that it's close enough.
I have been working with small embedded devices so this may be an outlier here compared to the rest of the C/C++ world.
> If you don't need IEEE-conformat floating point calculations, use -ffast-math .
I mean… if you know enough to know whether you need standard floating-point calculations, you probably know about the -ffast-math flag.
Someone who is more into system specific stuff might correct me, but I believe fast math produces a binary which can flip bits in the MXCSR if it wants. So, you’ll have to make sure that none of your libraries make any assumptions about floating point behavior, not just your code…
If you just want physics engine go brr and a small binary, though, maybe you don’t.
I find the FP advice suspect for a different reason: I’ve seen some no good, very bad, seriously terrible, really horrifyingly awful codegen from Clang for x86-64 things involving `long double`, and without checking first I wouldn’t assume that it doesn’t extend to all x87 stuff in general.
(Clang’s preferred optimized way to copy a naturally-aligned 16-byte union with a `long double` being the longest member is... to copy the first ten bytes with FLD/FSTP, then the following two bytes of padding by a word-sized MOV, then the final four bytes, also of padding, by a doubleword-sized MOV. Apparently it forgot its MOVAPS at home.
When it spills onto the stack a `long double` temporary it itself invented to implement an atomic operation’s inner loop, though, it first clears the padding using a bleeding XORPS+MOVAPS pair before FSTPing it there—inside the loop, twice, to two identical temporaries, because apparently it belongs to the offshore oil rig school of register spilling.
And so on. I lack the words to describe how bad Clang’s codegen is for anything that might have ever briefly brushed against a `long double`.)
Also take care with -Os; while clang’s -Os is generally sane, gcc -Os will e.g. implement division by a constant with IDIV instead of magic multiplication, giving you code that’s maybe three times shorter and easily a dozen or two dozen times slower. (I think I remember Torvalds saying years ago that he gave up on gcc -Os.)
Is that still true? Might warrant a bug filed on clang/llvm.
So I’d need to do some work to make a small reproducer; then I’d have to figure out how to get access to their bug tracker, because apparently letting people register their own accounts is too easy, let alone just send mail to an address. I don’t know if I have that in me.
(On a more positive note, do you know that sometimes, if you add `default: __builtin_unreachable();` to your switch-threaded interpreter loop, Clang will look at it and replicate the dispatch at the end of each bytecode instruction, like in the standard technique for better branch prediction in handwritten assembly-language interpreters? When I noticed that I couldn’t stop imagining it going “It looks you’re writing an interpreter. Would you like some help?”.)
Templates and operators overloading are also quite often frowned up.
https://gist.github.com/raizr/c08922b11b33477a1157156e424342...
It would be terrible advice if it were framed as "do all these things."
Also don't go too far with the build flags or you risk waking the sleeping horrors lurking in the seldom tested dark corners of the compilers and linkers we all rely on e.g. accidentally changing the effective ABI through tricks like smaller enums. Some of those bugs may only trigger on certain architectures e.g. exception handling works differently on amd64 and aarch64. On one of the two uses special an extra section to locate the unwind helpers. Do you know the all implications of removing a section from an executable? sigh
Please keep bloat down, but eager developers shouldn't too far beyond the point of quickly diminishing returns within a given ecosystem they're targeting.
Not really, the STL is an accumulation of mediocre design decisions (mostly because it needs to be "everything to everybody"), which can't be fixed because of backward compatibility requirements. In many situations it's actually better to write your own specialized helper classes.
The only time in my entire career i've ever used the STL was in college. Since most C++ jobs are not Appdevs. All those have moved to C#, Go, or some other higher level language. Or again, just rely on the built in suite like RTL, Posix, Unreal
- How a 64k intro is made [1]
- in4k site creation of demoscene 1kb, 4kb and 8kb intros [2]
- SizeCoding.org is a wiki dedicated to the art of creating very tiny programs [3]
[1] http://www.lofibucket.com/articles/64k_intro.html
For 64k: kkcrunchy or squishy
For 1-8k: crinkler, which is both a packer and a linker
For 256b or less: not enough space for a packer, use 16-bit x86 assembly and DOS .COM files
And of course, find a way to get interesting music and visuals with very little data, usually, it means maths.
First thing, you are usually not allowed to use libraries that are not included in a fresh install of the chosen OS. A fresh install will be done and only your executable which must be within the size limit will be copied to the "compo machine".
Often, the only library functions being used are related to hardware access. A modern PC is not an Amiga, you can't just write at some address and expect the GPU to understand that it needs to set some pixel, you can't setup a DMA for your sound card to read some sound, you have to use some kind of libraries and drivers even if the only thing you want is show a dot on the screen. After setting up your display and sound, often, your code is doing all the work, with fonts being the only external asset typically used, if needed.
There used to be more OS-related tricks. Like CAB-droppers for decompression, but now, you have context modeling based unpackers that are way better than the compression used in CAB, and take a few hundred bytes at most. Extremely slow, but we are talking 64k or less files here. For sound, you now have 4klang, a tiny soft synth that will generate code for interesting music in 1k or less, and that can interface with a DAW as a VST for composition. No need to mess with MIDI or whatever the OS has to offer besides "play wav".
There are also talks of work on just brute forcing the inlining for size problem for embedded releases for smallish applications. It's definitely feasible if the problem is important enough to you to throw some compute at it [2].
- build all of your dependencies yourself (including standard libs) and ensure they're built with LTO, and link everything statically. Everything you don't actually need will be removed.
- link everything dynamically. The total image size is huge, but technically it's not part of your binary, and can be shared with other binaries as well.
Perhaps it should be possible use profiling data to keep human-managed {un,}likely or {hot,cold} annotations up to date? How valuable are PGO’s frequencies compared to these discrete-valued labels? (I know GCC allows you to specify frequencies in the source, but that sounds less than convenient.)
nm -B -l -r --size-sort --print-size -t d ./path/to/compiler/output{.so} | c++filt > /tmp/by_size
Just a lot of flags that show you size by symbol in decimal with unmangled symbols. Run it before you run `strip` in your CI pipeline or whatever preps a build for proper release.
When I worked on Matter a couple years ago, we had the problem that its backend http://www.capstone-engine.org/ did not support Xtensa, and produced some Python tools that could take output from bloaty or similar data from readelf or elftools, and produce several kinds of report.
https://github.com/project-chip/connectedhomeip/blob/master/...
In C++, use as few template types as possible
> In C++, use -fno-rtti if your code doesn't use RTTI (run-time type identification) or dynamic_cast.
Note that "your code" here generally must encompass "your code" and all of your C++ archives/shared object dependencies (and their dependencies).
And I wonder what happens if your code creates a class which inherits from a base class defined in a library and that library expects anything which inherits from that base class to have runtime type info.
And if a template or inline function depends on catching an exception, you're right that your app unexpectedly crashing due to std::terminate isn't "fun or interesting" but it's not really great either.
An inline function that depends on RTTI will fail to compile when -fno-rtti is enabled.
There is also nothing unexpected about an application immediately terminating due to an exception. That's the most expected outcome in an application that has made an explicit choice to not handle exceptions and is what happens in any application that does not have a try/catch handler.
> There is also nothing unexpected about an application immediately terminating due to an exception. That's the most expected outcome in an application that has made an explicit choice to not handle exceptions and is what happens in any application that does not have a try/catch handler.
If I call a function from a library, and that library function depends on catching and handling exceptions (maybe it uses a stdlib function which throws, such as vector::at), it's unexpected that my application crashes due to that exception. Yet, if that library function happens to be in a header, calling it will crash my program (or, again, you have an ODR violation and anything could happen).
This doesn't make any sense. If a function from a library depends on catching and handling an exception then it can continue to do so. Using -fno-rtti doesn't change the semantics of functions that were compiled without that flag, they can continue working as usual.
All -fno-rtti does is treat your program as if any exception thrown goes unhandled, which in C++ means that std::terminate is called.
If you're saying you have a function that throws an exception and that function expects someone else to catch it, then the problem isn't with -fno-rtti, the problem is with your function's expectations. That means your function is using exceptions as a form of control flow, which is not a recommended practice. The primary goal and intention of exceptions is that the function that throws it is agnostic about how the exception is handled, or whether the exception is handled at all.
A function fails to meet its post-condition can throw an exception. If that exception gets caught then the receiver of that exception makes the decision on to proceed (not the thrower), if that exception does not get caught then std::terminate is called. All -fno-rtti does is guarantee that any exception thrown goes uncaught.
This is the least surprising behavior one can expect. What possible alternative behavior would you want from a function that throws an exception that goes uncaught?
It's very hard to understand someone who is repeatedly making false claims but doesn't realize it.
If you don't know how something works, please avoid making claims about it as if you did know such as:
>Yet, if that library function happens to be in a header, calling it will crash my program (or, again, you have an ODR violation and anything could happen).
That's a false claim and saying it does nothing but create confusion and spread misinformation. Especially since you're referencing ODR violations which to someone who doesn't know better might be fooled into thinking your claim is more credible than it really is (there is no ODR violation).
Maybe we could've gotten to this point faster though if you didn't keep responding as if I wasn't talking about library functions defined in headers.
>An inline function that depends on RTTI will fail to compile when -fno-rtti is enabled.
Note that you completely ignored that point.
>You will only have fun unexpected behaviors on some compilers.
I made it very clear, as did OP, that we were discussing the use of -fno-rtti. There is not a single compiler where that flag does not behave the way as I described.
You are discussing MSVC which does not have an -fno-rtti but instead uses a /GR- which behaves differently from -fno-rtti.
When discussing detailed matters involving C++ compilers and toolchains, precision matters. Especially since clang has a compatibility mode with MSVC where it too implements both /GR- and -fno-rtti and treats them as separate flags with different behaviors.
#if defined(__cpp_rtti)
Some ABI- or ODR- breaking code
#endif
std::terminate won't call any destructors further up the chain, but if all you're doing in destructors is deallocating memory and releasing handles to system resources, this shouldn't matter.
Note that closing system resources is often abortive. On the other hand, object destructors might wait for a flush.
That "if" is doing some heavy lifting. C++ places a lot of stock in RAII, so failing to call destructors could cause lots of interesting failure modes. I don't think it's fair to dismiss this fundamental part of the language so easily.
My personal opinion is that using RAII to do anything that you wouldn't trust the OS do for you in the event of an early termination is setting yourself up for disaster.
Simply instantiating a pointer to class using new uses exceptions.
Without exceptions all constructors that fail turn into undefined behaviour. The caller will never know that the instance they are using is filled with random bytes.
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_except...
the c++ standard does not allow for disabling exceptions, so at best this would be implementation-dependent behaviour, at worst UB.
in other words, using -fno-execptions, and similar on other compilers, raises compatibility problems.
And this "C++ with exceptions disabled" language defines that exceptions terminate the program.
There is no UB anywhere here, everything is well-defined.
You're right again though that there are compatibility problems, you could hypothetically use a compiler whose '-fno-exceptions' option actually defines throwing exceptions to be UB. No compiler would do that since it's obviously insane, but it is a possible alternate "C++ with exceptions disabled" language. Make sure to not use such compilers.
And it's probably a good idea to keep your code valid C++ anyways, meaning a standard C++ compiler will terminate the program due to an uncaught exception while GCC and Clang with -fno-exceptions will terminate the program by calling abort(). This way, GCC and Clang's -fno-exceptions behavior is just an optimization for when compiling on those compilers.
not a language standard i was previously aware of.
Except that's not a language that is standardized, so there's nothing that defines anything here. GCC and Clang may call std::terminate() when exceptions are disabled and some library/dependency throws, but unless your build process aborts when a compiler other than GCC or Clang is used, you can't rely on that behavior in general.
Correct! It's a language defined ad-hoc by GCC and Clang. GCC's man page describes its behavior with '-fno-exceptions' to be essentially: act like a normal C++ compiler, except produce code which calls abort() where it would otherwise have engaged the exception throwing machinery. That defines a kind of "C++ with exceptions disabled" language, but it's not a standard.
The first affects the layout of object files. The second affects the optimizations done when linking.
It can also eliminate unused data and functions, as it basically treats most entites as internal linkage, and that's one of the optimisations applied there. The mechanism is rather different to GCing sections at link time though. I assume LTO has something similar.
It's useful to combine it with unity builds. It's poor man's LTO in a way.
But you're right, it's also possible to use it for single-translation-unit build-and-link.
Regarding compression, demoscene tools like kkrunchy, Squishy (https://logicoma.io/squishy/), and Crinkler can give much better results than UPX. They come with their own downsides, e.g. made for Windows, decompression can be slow, outputs might trigger antivirus systems, etc.
Another important advice is to check the binary size regularly. It can be difficult to predict how a code change will affect the binary (especially after compression!), so you need to test it often.
> If it's feasible, rewrite your C++ code as C.
Many C++ features are just free syntactic sugar, so I've decided to use them (e.g. namespaces, classes without virtuals).
Using upx can also make a significant difference, but unfortunately not every OS likes the result. Mac OS just immediately killed my program when it was compressed like that.
If your program is too large, you get more cache misses when branching around. Frequent cache misses have a _huge_ effect on your code's overall performance, and can completely negate any of the wins you get from loop unrolling or other optimizations.
This effect is very pronounced on small armv7l/aarch64 CPUs, which usually have much smaller caches than a desktop CPU. You can even see it on laptop CPUs too.
It's impossible to know where exactly your size cutoffs are, because they depend a lot on what else is running in your system (and CPU core allocation, etc). But they 100% exist, for any program on any system. If your whole program can fit into your CPU cache, you'll see a big performance difference vs having to fetch it from RAM all the time.