Back in the old days, in the 70's and 80's when bitfields were good, memory was very expensive.  ....anything that touched memory was slow ... so if you could use multiple instructions that avoided a trip to memory you could see great performance improvements.  Using a bitfield, or in other words, having the compiler perform bit shifts followed by the compares or other operations you need followed by another bitshift back, was much faster than using a single byte of memory.

Today this is the opposite case.  Memory is cheap and plentiful.  On-die cache can contain more than the largest HDDs of that earlier era; there is practically no benefit to the space usage, and the compressed space may even result in cache alignment penalties.  With deep pipelines, the shift operations are expensive and will stall your CPU.  Using a bitfield in modern code is a huge performance penalty, and should only be used when you have specific reasons to take that penalty.

Are you sure about all of that? When you measure memory access times in terms of CPU-speed (e.g. CPU cycles or FLOPS per register<->RAM round trip time), then RAM is probably ^{[citation-needed, made up statistics]} about 10000x slower now than it was in was in the 80's. Optimising for memory is near-practically the only optimisation that actually matters these days -- surely there's cases where you cans "waste" 10 cycles on unpacking data to avoid a 1000 cycle cache-miss? A shift-by-constant and mask instruction shouldn't be harmful to the pipeline at all (unlike shift-by-variable, which might be microcoded, etc)...

Packing multiple values into a word/register via shifting/masking is a core idiom in systems-level code, taught to every computer science student, and this C/C++ feature is syntactic-sugar aimed at this demographic of systems programmers. To tie back in with what you were saying -- systems-level programming is a huge penalty in a modern applications programming environment, and such environments avoid should C/C++ altogether, unless they have specific reasons to take that penalty ;)

Back in the old days, in the 70's and 80's when bitfields were good, memory was very expensive.  ....anything that touched memory was slow ... so if you could use multiple instructions that avoided a trip to memory you could see great performance improvements.  Using a bitfield, or in other words, having the compiler perform bit shifts followed by the compares or other operations you need followed by another bitshift back, was much faster than using a single byte of memory.

Today this is the opposite case.  Memory is cheap and plentiful.  On-die cache can contain more than the largest HDDs of that earlier era; there is practically no benefit to the space usage, and the compressed space may even result in cache alignment penalties.  With deep pipelines, the shift operations are expensive and will stall your CPU.  Using a bitfield in modern code is a huge performance penalty, and should only be used when you have specific reasons to take that penalty.

Are you sure about all of that?

When you measure memory access times in terms of CPU-speed (e.g. CPU cycles or FLOPS per register<->RAM round trip time), then RAM is probably about 10000x slower now than it was in was in the 80's. Optimising for memory is near-practically the only optimisation that actually matters these days -- surely there's cases where you cans "waste" 10 cycles on unpacking data to avoid a 1000 cycle cache-miss? A shift-by-constant and mask instruction shouldn't be harmful to the pipeline at all (unlike shift-by-variable, which might be microcoded, etc)...

Packing multiple values into a word/register via shifting/masking is a core idiom in systems-level code, taught to every computer science student, and this C/C++ feature is syntactic-sugar aimed at this demographic of systems programmers. To tie back in with what you were saying -- systems-level programming is a huge penalty in a modern applications programming environment, and such environments avoid should C/C++ altogether, unless they have specific reasons to take that penalty ;)

Back in the old days, in the 70's and 80's when bitfields were good, memory was very expensive.  ....anything that touched memory was slow ... so if you could use multiple instructions that avoided a trip to memory you could see great performance improvements.  Using a bitfield, or in other words, having the compiler perform bit shifts followed by the compares or other operations you need followed by another bitshift back, was much faster than using a single byte of memory.

Today this is the opposite case.  Memory is cheap and plentiful.  On-die cache can contain more than the largest HDDs of that earlier era; there is practically no benefit to the space usage, and the compressed space may even result in cache alignment penalties.  With deep pipelines, the shift operations are expensive and will stall your CPU.  Using a bitfield in modern code is a huge performance penalty, and should only be used when you have specific reasons to take that penalty.

Are you sure about all of that?

When you measure memory access times in terms of CPU-speed (e.g. CPU cycles or FLOPS per register<->RAM round trip time), then RAM is probably about 10000x slower now than it was in was in the 80's. Optimising for memory is near-practically the only optimisation that actually matters these days -- surely there's cases where you cans "waste" 10 cycles on unpacking data to avoid a 1000 cycle cache-miss? A shift-by-constant and mask instruction shouldn't be harmful to the pipeline at all (unlike shift-by-variable, which might be microcoded, etc)...

Packing multiple values into a word/register via shifting/masking is a core idiom in systems-level code, taught to every computer science student, and this C/C++ feature is syntactic-sugar aimed at this demographic of systems programmers. To tie back in with what you were saying -- systems-level programming is a huge penalty in a modern applications programming environment, and such environments avoid should C/C++ altogether, have specific reasons to take that penalty ;)

Back in the old days, in the 70's and 80's when bitfields were good, memory was very expensive.  ....anything that touched memory was slow ... so if you could use multiple instructions that avoided a trip to memory you could see great performance improvements.  Using a bitfield, or in other words, having the compiler perform bit shifts followed by the compares or other operations you need followed by another bitshift back, was much faster than using a single byte of memory.

Today this is the opposite case.  Memory is cheap and plentiful.  On-die cache can contain more than the largest HDDs of that earlier era; there is practically no benefit to the space usage, and the compressed space may even result in cache alignment penalties.  With deep pipelines, the shift operations are expensive and will stall your CPU.  Using a bitfield in modern code is a huge performance penalty, and should only be used when you have specific reasons to take that penalty.

Are you sure about all of that?

When you measure memory access times in terms of CPU-speed (e.g. CPU cycles or FLOPS per register<->RAM round trip time), then RAM is probably about 10000x slower now than it was in was in the 80's. Optimising for memory is near-practically the only optimisation that actually matters these days -- surely there's cases where you cans "waste" 10 cycles on unpacking data to avoid a 1000 cycle cache-miss? A shift-by-constant and mask instruction shouldn't be harmful to the pipeline at all (unlike shift-by-variable, which might be microcoded, etc)...

Packing multiple values into a word/register via shifting/masking is a core idiom in systems-level code, taught to every computer science student, and this C/C++ feature is syntactic-sugar aimed at this demographic of systems programmers. To tie back in with what you were saying -- systems-level programming is a huge penalty in a modern applications programming environment, and such environments avoid C/C++ altogether.

Back in the old days, in the 70's and 80's when bitfields were good, memory was very expensive.  ....anything that touched memory was slow ... so if you could use multiple instructions that avoided a trip to memory you could see great performance improvements.  Using a bitfield, or in other words, having the compiler perform bit shifts followed by the compares or other operations you need followed by another bitshift back, was much faster than using a single byte of memory.

Today this is the opposite case.  Memory is cheap and plentiful.  On-die cache can contain more than the largest HDDs of that earlier era; there is practically no benefit to the space usage, and the compressed space may even result in cache alignment penalties.  With deep pipelines, the shift operations are expensive and will stall your CPU.  Using a bitfield in modern code is a huge performance penalty, and should only be used when you have specific reasons to take that penalty.

Are you sure about all of that?

When you measure memory access times in terms of CPU-speed (e.g. CPU cycles or FLOPS per register<->RAM round trip time), then RAM is probably about 10000x slower now than it was in was in the 80's. Optimising for memory is near-practically the only optimisation that actually matters these days -- surely there's cases where you cans "waste" 10 cycles on unpacking data to avoid a 1000 cycle cache-miss? A shift-by-constant and mask instruction shouldn't be harmful to the pipeline at all (unlike shift-by-variable, which might be microcoded, etc)...

Packing multiple values into a word/register via shifting/masking is a core idiom in systems-level code, taught to every computer science student, and this C/C++ feature is syntactic-sugar aimed at this demographic of systems programmers.