Reduce FormattingOptions to 64 bits #136974

m-ou-se · 2025-02-13T15:07:17Z

This is part of #99012

This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms).

This PR includes #136932, which reduces the width and precision options to 16 bits, to make it all fit.

Before:

pub struct FormattingOptions {
    flags: u32, // only 6 bits used
    fill: char,
    align: Option<Alignment>,
    width: Option<usize>,
    precision: Option<usize>,
}

After:

pub struct FormattingOptions {
    /// Bits:
    ///  - 0-20: fill character (21 bits, a full `char`)
    ///  - 21: `+` flag
    ///  - 22: `-` flag
    ///  - 23: `#` flag
    ///  - 24: `0` flag
    ///  - 25: `x?` flag
    ///  - 26: `X?` flag
    ///  - 27: Width flag (if set, the width field below is used)
    ///  - 28: Precision flag (if set, the precision field below is used)
    ///  - 29-30: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown)
    ///  - 31: Always set to 1
    flags: u32,
    /// Width if width flag above is set. Otherwise, always 0.
    width: u16,
    /// Precision if precision flag above is set. Otherwise, always 0.
    precision: u16,
}

m-ou-se · 2025-02-13T16:21:21Z

@bors try @rust-timer queue

bors · 2025-02-13T16:22:34Z

⌛ Trying commit c059377 with merge 47853a6...

Reduce FormattingOptions to 64 bits This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms). This PR includes rust-lang#136932, which reduces the width and precision options to 16 bits, to make it all fit. Before: ```rust pub struct FormattingOptions { flags: u32, // only 6 bits used fill: char, align: Option<Alignment>, width: Option<usize>, precision: Option<usize>, } ``` After: ```rust pub struct FormattingOptions { /// Bits: /// - 0: `+` flag [rt::Flag::SignPlus] /// - 1: `-` flag [rt::Flag::SignMinus] /// - 2: `#` flag [rt::Flag::Alternate] /// - 3: `0` flag [rt::Flag::SignAwareZeroPad] /// - 4: `x?` flag [rt::Flag::DebugLowerHex] /// - 5: `X?` flag [rt::Flag::DebugUpperHex] /// - 6-7: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown) /// - 8: Width flag (if set, the width field below is used) /// - 9: Precision flag (if set, the precision field below is used) /// - 10: unused /// - 11-31: fill character (21 bits, a full `char`) flags: u32, /// Width if width flag above is set. Otherwise, always 0. width: u16, /// Precision if precision flag above is set. Otherwise, always 0. precision: u16, } ```

bors · 2025-02-13T18:13:21Z

☀️ Try build successful - checks-actions
Build commit: 47853a6 (47853a630ac42e5c5ab5fcd1f07d37eef67f84e9)

rust-timer · 2025-02-13T19:31:14Z

Finished benchmarking commit (47853a6): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.7%, -0.2%]	5
Improvements ✅ (secondary)	-0.5%	[-0.7%, -0.2%]	2
All ❌✅ (primary)	-0.2%	[-0.7%, 0.6%]	6

Max RSS (memory usage)

Results (primary 2.0%, secondary -1.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.0%	[1.9%, 2.1%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	2.0%	[1.9%, 2.1%]	2

Cycles

Results (secondary -0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.8%	[1.8%, 1.8%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.3%	[-2.3%, -2.3%]	1
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.2%, secondary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.3%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.5%, -0.0%]	70
Improvements ✅ (secondary)	-0.1%	[-0.3%, -0.0%]	56
All ❌✅ (primary)	-0.2%	[-0.5%, 0.3%]	76

Bootstrap: 792.804s -> 787.91s (-0.62%)
Artifact size: 347.85 MiB -> 347.86 MiB (0.00%)

m-ou-se · 2025-02-13T20:24:58Z

Looks fine. Binary size improvements looking good too: https://perf.rust-lang.org/compare.html?start=54cdc751df770517e70db0588573e32e6a7b9821&end=47853a630ac42e5c5ab5fcd1f07d37eef67f84e9&stat=size%3Alinked_artifact&tab=compile

m-ou-se · 2025-02-13T20:27:41Z

Marking this as blocked on #136932

bors · 2025-03-05T19:13:24Z

☔ The latest upstream changes (presumably #138058) made this pull request unmergeable. Please resolve the merge conflicts.

…=scottmcm Reduce formatting `width` and `precision` to 16 bits This is part of rust-lang#99012 This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision. By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see rust-lang#136974) and improve the in memory representation of `format_args!()`. (See additional context below.) This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated. This is a breaking change, but affects almost no existing code. --- Details of this change: There are three ways to set a width or precision today: 1. Directly a formatting string, e.g. `println!("{a:1234}")` 2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)` 3. Through the unstable `FormattingOptions::width` method. This PR: - Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.) - Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.) - Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead. --- Additional context for improving `FormattingOptions` and `fmt::Arguments`: All the formatting flags and options are currently: - The `+` flag (1 bit) - The `-` flag (1 bit) - The `#` flag (1 bit) - The `0` flag (1 bit) - The `x?` flag (1 bit) - The `X?` flag (1 bit) - The alignment (2 bits) - The fill character (21 bits) - Whether a width is specified (1 bit) - Whether a precision is specified (1 bit) - If used, the width (a full usize) - If used, the precision (a full usize) Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total). If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms. If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).

…cottmcm Reduce formatting `width` and `precision` to 16 bits This is part of rust-lang#99012 This is reduces the `width` and `precision` fields in format strings to 16 bits. They are currently full `usize`s, but it's a bit nonsensical that we need to support the case where someone wants to pad their value to eighteen quintillion spaces and/or have eighteen quintillion digits of precision. By reducing these fields to 16 bit, we can reduce `FormattingOptions` to 64 bits (see rust-lang#136974) and improve the in memory representation of `format_args!()`. (See additional context below.) This also fixes a bug where the width or precision is silently truncated when cross-compiling to a target with a smaller `usize`. By reducing the width and precision fields to the minimum guaranteed size of `usize`, 16 bits, this bug is eliminated. This is a breaking change, but affects almost no existing code. --- Details of this change: There are three ways to set a width or precision today: 1. Directly a formatting string, e.g. `println!("{a:1234}")` 2. Indirectly in a formatting string, e.g. `println!("{a:width$}", width=1234)` 3. Through the unstable `FormattingOptions::width` method. This PR: - Adds a compiler error for 1. (`println!("{a:9999999}")` no longer compiles and gives a clear error.) - Adds a runtime check for 2. (`println!("{a:width$}, width=9999999)` will panic.) - Changes the signatures of the (unstable) `FormattingOptions::[get_]width` methods to use a `u16` instead. --- Additional context for improving `FormattingOptions` and `fmt::Arguments`: All the formatting flags and options are currently: - The `+` flag (1 bit) - The `-` flag (1 bit) - The `#` flag (1 bit) - The `0` flag (1 bit) - The `x?` flag (1 bit) - The `X?` flag (1 bit) - The alignment (2 bits) - The fill character (21 bits) - Whether a width is specified (1 bit) - Whether a precision is specified (1 bit) - If used, the width (a full usize) - If used, the precision (a full usize) Everything except the last two can simply fit in a `u32` (those add up to 31 bits in total). If we can accept a max width and precision of u16::MAX, we can make a `FormattingOptions` that is exactly 64 bits in size; the same size as a thin reference on most platforms. If, additionally, we also limit the number of formatting arguments, we can also reduce the size of `fmt::Arguments` (that is, of a `format_args!()` expression).

m-ou-se added 3 commits February 12, 2025 17:32

Experiment: Use u16 for fmt width and precision.

8fec6a9

Update tests.

0f9dcd8

Fix rust-analyzer for 16-bit fmt width and precision.

ccb9429

m-ou-se added T-libs Relevant to the library team, which will review and decide on the PR/issue. A-fmt Area: `core::fmt` S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. labels Feb 13, 2025

m-ou-se self-assigned this Feb 13, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 13, 2025

m-ou-se removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 13, 2025

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Feb 13, 2025

This comment has been minimized.

Sign in to view

rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Feb 13, 2025

m-ou-se added S-blocked Status: Blocked on something else such as an RFC or other implementation work. and removed S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. labels Feb 13, 2025

This comment has been minimized.

Sign in to view

m-ou-se mentioned this pull request Feb 14, 2025

Reduce formatting width and precision to 16 bits #136932

Merged

m-ou-se force-pushed the fmt-options-64-bit branch from c4304cf to 4700995 Compare February 19, 2025 22:57

Reduce FormattingOptions to 64 bit.

dd37150

m-ou-se force-pushed the fmt-options-64-bit branch from 4700995 to dd37150 Compare February 19, 2025 23:04

m-ou-se mentioned this pull request Feb 19, 2025

Tracking issue for improving std::fmt::Arguments and format_args!() #99012

Open

50 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Reduce FormattingOptions to 64 bits #136974

Reduce FormattingOptions to 64 bits #136974

m-ou-se commented Feb 13, 2025 •

edited

Loading

m-ou-se commented Feb 13, 2025

This comment has been minimized.

bors commented Feb 13, 2025

This comment has been minimized.

bors commented Feb 13, 2025

This comment has been minimized.

rust-timer commented Feb 13, 2025

m-ou-se commented Feb 13, 2025

m-ou-se commented Feb 13, 2025

This comment has been minimized.

bors commented Mar 5, 2025

Reduce FormattingOptions to 64 bits #136974

Are you sure you want to change the base?

Reduce FormattingOptions to 64 bits #136974

Conversation

m-ou-se commented Feb 13, 2025 • edited Loading

m-ou-se commented Feb 13, 2025

This comment has been minimized.

bors commented Feb 13, 2025

This comment has been minimized.

bors commented Feb 13, 2025

This comment has been minimized.

rust-timer commented Feb 13, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Instruction count

Max RSS (memory usage)

Cycles

Binary size

m-ou-se commented Feb 13, 2025

m-ou-se commented Feb 13, 2025

This comment has been minimized.

bors commented Mar 5, 2025

m-ou-se commented Feb 13, 2025 •

edited

Loading