Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Patch typos in speed-vs-size.md #129

Merged
merged 5 commits into from
Feb 13, 2019
Merged

Patch typos in speed-vs-size.md #129

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
87e1520
Fix typo in c-tips ("varity" -> "variety")
krepl Feb 12, 2019
4f26bad
Fix typo in c-tips ("or" -> "of", and plural verb)
krepl Feb 12, 2019
a3d6241
fix typo in c-tips (duplicate "then")
krepl Feb 12, 2019
16817be
Fix typo correction ("then" -> "then the")
krepl Feb 12, 2019
90a88bd
Fix a few typos in unsorted/speed-vs-size.md
krepl Feb 13, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions src/c-tips/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ highlight how things you might already be used to in C are different in Rust.

## Preprocessor

In embedded C it is very common to use the preprocessor for a varity of
In embedded C it is very common to use the preprocessor for a variety of
purposes, such as:

* Compile-time selection of code blocks with `#ifdef`
Expand Down Expand Up @@ -52,7 +52,7 @@ pub mod iir;
```

You can similarly include code blocks only if a feature is _not_ enabled, or if
any combination or features is or is not enabled.
any combination of features are or are not enabled.

Additionally, Rust provides a number of automatically-set conditions you can
use, such as `target_arch` to select different code based on architecture. For
Expand All @@ -62,7 +62,7 @@ full details of the conditional compilation support, refer to the
[conditional compilation]: https://doc.rust-lang.org/reference/conditional-compilation.html

The conditional compilation will only apply to the next statement or block. If
a block can not be used in the current scope then then `cfg` attribute will
a block can not be used in the current scope then the `cfg` attribute will
need to be used multiple times. It's worth noting that most of the time it is
better to simply include all the code and allow the compiler to remove dead
code when optimising: it's simpler for you and your users, and in general the
Expand Down
10 changes: 5 additions & 5 deletions src/unsorted/speed-vs-size.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Optimizations: the speed size tradeoff

Everyone wants their program to be super fast and super small but it's usually
not possible to have maximize both characteristics. This section discusses the
different optimization levels that `rustc` provides and how the affect the
not possible to have both characteristics. This section discusses the
different optimization levels that `rustc` provides and how they affect the
execution time and binary size of a program.

## No optimizations
Expand All @@ -25,15 +25,15 @@ debug = true

No optimizations is great for debugging because stepping through the code feels
like you are executing the program statement by statement, plus you can `print`
stack variables and function arguments in GDB. When the code is optimized trying
stack variables and function arguments in GDB. When the code is optimized, trying
to print variables results in `$0 = <value optimized out>` being printed.

The biggest downside of the `dev` profile is that the resulting binary will be
huge and slow. The size is usually more of a problem because unoptimized
binaries can occupy dozens of KiB of Flash, which your target device may not
have -- the result: your unoptimized binary doesn't fit in your device!

Can we have smaller debugger friendly binaries? Yes, there's a trick.
Can we have smaller, debugger friendly binaries? Yes, there's a trick.

### Optimizing dependencies

Expand Down Expand Up @@ -117,7 +117,7 @@ profile which defaults to `opt-level = 3`.

Both `opt-level = 2` and `3` optimize for speed at the expense of binary size,
but level `3` does more vectorization and inlining than level `2`. In
particular, you'll see that at `opt-level` equal or greater than `2` LLVM will
particular, you'll see that at `opt-level` equal to or greater than `2` LLVM will
unroll loops. Loop unrolling has a rather high cost in terms of Flash / ROM
(e.g. from 26 bytes to 194 for a zero this array loop) but can also halve the
execution time given the right conditions (e.g. number of iterations is big
Expand Down