A flag string copied from a Stack Overflow answer is not a build strategy. When teams weigh a native C++ inference build against a Pyodide/WASM path, the GCC command line is where the two paths stop being abstract — and where a misread argument quietly inflates the binary or disables the SIMD the workload was counting on. The reflex is to paste something with -O2 in it, watch the build succeed, and declare the artifact “optimized.” That reflex is exactly how a port decision ends up resting on numbers that were never comparable in the first place. GCC arguments are a set of deliberate choices, not boilerplate. Each one moves at least one of the three properties you actually care about when shipping an inference binary: its size on disk, how long it takes to reach the first inference (cold start), and how long each inference takes once it is warm. Read the flags that way — as levers on footprint, startup, and per-inference latency — and the command line becomes a tool for producing a defensible baseline rather than a lucky guess. How do GCC arguments actually work? GCC (the GNU Compiler Collection) takes source, applies a sequence of transformations governed by the arguments you pass, and emits an object file or executable. An argument is not a suggestion the compiler weighs; most are switches that either enable a transformation pass, set a code-generation target, or change the contract the compiler assumes about your program. The reason two builds of the same source can differ by a factor in both size and speed is that the arguments changed which transformations ran and what the compiler was allowed to assume. That last point is the one people underestimate. A flag like -ffast-math does not “make math faster” in a vacuum — it changes the rules, telling the compiler it may reorder floating-point operations and ignore certain edge cases. That is a semantic change, not a free speedup. Understanding an argument means understanding what it does to the size, startup cost, and per-inference latency of the artifact you ship, and understanding what it costs you elsewhere. We treat the compiler command line the way we treat any other part of an inference path: as something to measure, not assume. What do the optimization levels (-O0 to -Ofast) actually change? The -O family is the single most consequential argument, and it is the one most often set on autopilot. Each level enables a bundle of passes with a different bias. The trade-off is not “higher number is faster” — it is a genuine three-way tension between compile time, binary size, and runtime speed. Optimization level decision table Flag Optimizes for Binary size effect Startup / cold-start effect Per-inference latency When to reach for it -O0 Nothing (debug) Large, unoptimized Slow Slowest Debugging only; never ship it -O1 Modest speed, fast compile Moderate Moderate Better than -O0 Fast dev iteration -O2 Balanced speed Moderate Good Good Sensible default for most inference binaries -O3 Aggressive speed (vectorization, inlining) Larger (code bloat from inlining/unrolling) Can be slower to load Often best for compute-bound loops Hot numeric kernels — verify, don’t assume -Os Size Smallest Fastest to load Slightly behind -O2 Footprint- and cold-start-sensitive targets -Ofast Speed, relaxes standards Similar to -O3 Similar to -O3 Fastest — but changes math semantics Only when you have validated numerical tolerance The trap sits between -O3 and -Os. -O3 is not automatically faster than -O2 for a real workload: aggressive inlining and loop unrolling grow the instruction footprint, which can hurt instruction-cache behaviour and slow the very hot loop you were trying to speed up. In configurations we have profiled, -O2 and -O3 land within noise of each other for many inference paths, while -O3 produces a noticeably larger binary (observed pattern across porting engagements; not a published benchmark). If your deployment constraint is footprint and cold start — the same axes a Python-path profiling baseline captures before you commit to a port — -Os may be the correct answer even though it sounds like you are giving up performance. -Ofast deserves its own warning. It implies -ffast-math, which relaxes IEEE floating-point guarantees. For an inference binary that is often fine — model outputs already tolerate small numerical drift — but “often” is not “always,” and the only way to know is to check your outputs against a reference. Turning it on because it is the highest-sounding level is precisely the copy-paste failure this article is about. Which arguments control target architecture and SIMD? This is where compute-bound inference lives or dies. Modern CPUs execute single-instruction-multiple-data (SIMD) operations — AVX2, AVX-512 on x86, NEON on Arm — that process several float operations per instruction. A matrix-multiply-heavy inference kernel that uses AVX2 can move several times more data per cycle than the same kernel restricted to scalar or SSE code. The arguments that gate this are -march, -mtune, and the explicit feature flags like -mavx2 or -mfma. -march=native tells GCC to generate code for the exact machine doing the compile, enabling every SIMD extension that machine supports. It is the fastest option and the least portable: a binary built with -march=native on an AVX-512 build server will emit an illegal-instruction fault on a deployment host that only has AVX2. The naive failure here is silent in the opposite direction too — build on a modest machine, and you never emit the AVX-512 the target could have used, leaving performance on the table with no error to warn you. The relationship between instruction width and real throughput is worth understanding on its own terms; we covered it in what SIMD width buys a ported inference path. The defensible pattern for a shipped binary is to name the baseline you actually target — -march=x86-64-v3, for example, which requires AVX2 and FMA and runs on essentially any recent x86 server — rather than -march=native, which encodes your build host into the artifact. Get this wrong and you either crash on deploy or silently disable the SIMD the workload depends on. Both are the same class of mistake: an unread architecture flag deciding your throughput for you. How do linker and -flto arguments change footprint and startup? Compilation is only half the build. The linker assembles object files into the final artifact, and its arguments move the footprint and startup numbers as much as any -O level. Two matter most for inference binaries. -flto enables link-time optimization, which lets GCC optimize across translation-unit boundaries — inlining and dead-code elimination that a per-file compile simply cannot see. For a binary that links a numeric library, LTO often shrinks the artifact by discarding code paths nothing calls, and can speed hot paths by inlining across files. The cost is compile time, sometimes substantially. The link stage itself is worth attention too; choosing a faster linker such as gold or lld cuts iteration time on large builds, which we discussed in the context of faster GPU/CUDA build links on Linux. The second lever is what you drag along. Static linking (-static) folds dependencies into one self-contained binary — larger on disk but with predictable startup, no runtime symbol resolution against shared objects. Dynamic linking keeps the binary small but pays a cold-start cost resolving and mapping shared libraries on first run. If cold start is your constraint, that resolution cost is not a footnote; it is exactly the number your baseline measures. How do GCC choices compare to a Pyodide/WASM path? Here is the reframe that matters most for a port decision. On a native C++ build, the arguments above are yours to set — every -O level, every SIMD flag, every linker choice. On a Pyodide/WASM path, most of that control moves out of your hands. Native GCC vs WASM/Pyodide: what you control Control lever Native C++ (GCC) Pyodide / WASM Optimization level Full -O0…-Ofast Set by the toolchain build; you consume it Target architecture / SIMD -march, explicit AVX/NEON flags WASM SIMD only if the runtime enables it; no CPU-specific tuning Link-time optimization -flto, your choice Baked into the prebuilt Pyodide artifact Static vs dynamic linking Your decision Fixed by the WASM module packaging Binary / bundle footprint Tunable via -Os, LTO, stripping Dominated by the runtime + package payload you ship to the browser Cold start Link model + -O level WASM compile/instantiate cost, often the larger term The point is not that one path wins. It is that they are optimized on different axes, and a fair comparison has to account for that. A native binary tuned with -Os and -flto can produce a footprint and cold-start profile that a WASM bundle — carrying a full Python runtime — cannot match, but the WASM path buys you deployment reach the native binary does not have. This is the same set of profiling axes the Compiler Flags for WASM Inference breakdown examines from the WASM side, and it is the reason the compiler-argument conversation and the port-or-not conversation are really one conversation. The compiler-argument choices you make on the native side feed directly into an [inference cost baseline](GPU engineering) you can defend, rather than a number you hope holds up. The broader mechanics of how each -O level and vectorization flag reshapes an inference build are covered in our reference on optimization flags that shape inference builds; this article’s job is to connect those choices to the port decision they inform. All of this ties back to how we think about portable, cost-aware inference more broadly. Which arguments produce a defensible port-decision baseline? If the goal is a native baseline you can put next to a WASM path without hand-waving, the argument set is narrower than the full manual suggests. Start from -O2 as a neutral, well-understood default. Set -march to a named baseline architecture that matches your real deployment floor — not -march=native, which encodes the build host. Enable -flto if link-time optimization measurably shrinks the artifact or improves the hot path, and confirm it does rather than assuming. Add -ffast-math only after validating that your model outputs stay within tolerance. Strip symbols (-s or strip) before you measure footprint, because debug symbols distort the number you are comparing. Then measure the three things that decide the port: binary/footprint delta, cold-start time to first inference, and per-inference latency under realistic load. Those are the axes both paths get scored on. A build tuned this way gives the [inference-cost-cut pack](Inference Cost-Cut Pack) a native reference that means something — and compiler-argument choices map cleanly onto release-readiness gates like bundle size and cold-start, the same gates any [AI infrastructure readiness](AI infrastructure and SaaS) review checks before a ship. FAQ How does gcc arguments actually work? GCC arguments are command-line switches that control which transformation passes run, what target the compiler generates code for, and what assumptions it is allowed to make about your program. In practice, each argument moves at least one of three properties of the artifact you ship — its size, its cold-start time, and its per-inference latency — so they are deliberate engineering choices rather than boilerplate to copy. What do the common GCC optimization flags (-O0 through -O3, -Os, -Ofast) actually change about an inference binary’s size and speed? Each -O level enables a different bundle of passes: -O0 optimizes nothing, -O2 is a balanced default, -O3 pushes aggressive inlining and vectorization at the cost of a larger binary, -Os optimizes for the smallest footprint and fastest load, and -Ofast relaxes floating-point standards for extra speed. -O3 is not automatically faster than -O2 for real workloads because code bloat can hurt instruction-cache behaviour, and -Os is often the right call when footprint and cold start are the binding constraint. Which GCC arguments control target architecture and SIMD/vectorization, and why do they matter for compute-bound inference? -march, -mtune, and explicit feature flags like -mavx2 or -mfma decide which SIMD instructions GCC emits, and SIMD lets a compute-bound kernel process several float operations per instruction. -march=native enables everything the build host supports but crashes on hosts that lack those instructions and silently disables SIMD the target could have used if you build on a modest machine — so a named baseline like -march=x86-64-v3 is the safer choice for a shipped binary. How do GCC linker and link-time optimization (-flto) arguments affect final binary footprint and startup cost? -flto lets GCC optimize across translation units, often shrinking the artifact by removing unreachable code and speeding hot paths through cross-file inlining, at the cost of longer compile time. Linking choices matter too: static linking produces a larger but self-contained binary with predictable startup, while dynamic linking keeps the binary small but pays a cold-start cost resolving shared libraries on first run. How do GCC argument choices in a native C++ build compare to what you can and cannot control on a Pyodide/WASM path? On a native build you control every optimization level, SIMD flag, LTO setting, and linking model. On a Pyodide/WASM path most of that control moves into the prebuilt toolchain: WASM SIMD depends on the runtime, footprint is dominated by the Python runtime payload you ship, and cold start is driven by WASM compile/instantiate cost — so the two paths are optimized on different axes and must be compared with that in mind. Which GCC arguments should you set to produce a defensible profiling baseline for a port-or-not decision? Start from -O2, set -march to a named baseline matching your real deployment floor, enable -flto only if it measurably helps, add -ffast-math only after validating output tolerance, and strip symbols before measuring footprint. Then measure the three axes that decide the port: binary/footprint delta, cold-start time to first inference, and per-inference latency under realistic load. A last caution: the most expensive compiler mistake is rarely the flag you got wrong. It is the flag you never looked at — the -march=native that crashes on deploy, or the missing -Os on a target where cold start was always going to be the number that mattered. Read the arguments before you trust the binary, and the port decision rests on measurement instead of a paste.
