support arrays of any size, don't require an initialization value, .. #4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
single producer single consumer support for ring buffer
|
Sorry for interrupting, but I'm curious, why did you decide to use usize for head and tail instead of atomics. Is it for making it work on armv6 which doesn't have atomics? If I understand correctly, volatile operations are only safe on single core CPUs. On multi core CPUs you need some kind of memory fence to share the data in buffer between cores. Best option is release-acquire synchronization using atomics. |
|
@japaric Not so long ago I wrote a similar spsc ring buffer and tested it using thread sanitizer https://play.rust-lang.org/?gist=4ebd95ec79757a7d2b625cb85d58300c&version=stable |
|
@pftbest yes and yes. I'm also mostly interested in using this crate with single core processors (microcontrollers) but it's a good idea to note that this won't work on multicore processors. We can revisit the atomic implementation if / when rust-lang/rust#45085 otherwise it's tricky to write an implementation for ARMv6-M. |
|
@homunkulus r+ |
|
📌 Commit da5757a has been approved by |
japaric
pushed a commit
that referenced
this pull request
Oct 31, 2017
support arrays of any size, don't require an initialization value, .. single producer single consumer support for ring buffer
|
💔 Test failed - status-travis |
|
@homunkulus retry |
japaric
pushed a commit
that referenced
this pull request
Oct 31, 2017
support arrays of any size, don't require an initialization value, .. single producer single consumer support for ring buffer
|
☀️ Test successful - status-travis |
japaric
added a commit
that referenced
this pull request
May 10, 2022
these changes optimize `Vec<u8, 1024>::clone` down to these operations
1. reserve the stack space (1028 bytes on 32-bit ARM) and leave it uninitialized
2. zero the `len` field
3. memcpy `len` bytes of data from the parent
analyzed source code
``` rust
use heapless::Vec;
fn clone(vec: &Vec<u8, 1024>) {
let mut vec = vec.clone();
black_box(&mut vec);
}
fn black_box<T>(val: &mut T) {
unsafe { asm!("// {0}", in(reg) val) }
}
```
machine code with `lto = fat`, `codegen-units = 1` and `opt-level = 'z'` ('z' instead of 3 to avoid loop unrolling and keep the machine code readable)
``` armasm
00020100 <clone>:
20100: b5d0 push {r4, r6, r7, lr}
20102: af02 add r7, sp, #8
20104: f5ad 6d81 sub.w sp, sp, #1032 ; 0x408
20108: 2300 movs r3, #0
2010a: c802 ldmia r0!, {r1}
2010c: 9301 str r3, [sp, #4]
2010e: aa01 add r2, sp, #4
20110: /--/-X b141 cbz r1, 20124 <clone+0x24>
20112: | | 4413 add r3, r2
20114: | | f810 4b01 ldrb.w r4, [r0], #1
20118: | | 3901 subs r1, #1
2011a: | | 711c strb r4, [r3, #4]
2011c: | | 9b01 ldr r3, [sp, #4]
2011e: | | 3301 adds r3, #1
20120: | | 9301 str r3, [sp, #4]
20122: | \-- e7f5 b.n 20110 <clone+0x10>
20124: \----> a801 add r0, sp, #4
20126: f50d 6d81 add.w sp, sp, #1032 ; 0x408
2012a: bdd0 pop {r4, r6, r7, pc}
```
note that it's not optimizing step (3) to an actual `memcpy` because we lack the 'trait specialization' code that libstd uses
---
before `clone` was optimized to
1. reserve and zero (`memclr`) 1028 (!?) bytes of stack space
2. (unnecessarily) runtime check if `len` is equal or less than 1024 (capacity) -- this included a panicking branch
3. memcpy `len` bytes of data from the parent
japaric
added a commit
that referenced
this pull request
May 10, 2022
these changes optimize `Vec<u8, 1024>::clone` down to these operations
1. reserve the stack space (1028 bytes on 32-bit ARM) and leave it uninitialized
2. zero the `len` field
3. memcpy `len` bytes of data from the parent
analyzed source code
``` rust
use heapless::Vec;
fn clone(vec: &Vec<u8, 1024>) {
let mut vec = vec.clone();
black_box(&mut vec);
}
fn black_box<T>(val: &mut T) {
unsafe { asm!("// {0}", in(reg) val) }
}
```
machine code with `lto = fat`, `codegen-units = 1` and `opt-level = 'z'` ('z' instead of 3 to avoid loop unrolling and keep the machine code readable)
``` armasm
00020100 <clone>:
20100: b5d0 push {r4, r6, r7, lr}
20102: af02 add r7, sp, #8
20104: f5ad 6d81 sub.w sp, sp, #1032 ; 0x408
20108: 2300 movs r3, #0
2010a: c802 ldmia r0!, {r1}
2010c: 9301 str r3, [sp, #4]
2010e: aa01 add r2, sp, #4
20110: /--/-X b141 cbz r1, 20124 <clone+0x24>
20112: | | 4413 add r3, r2
20114: | | f810 4b01 ldrb.w r4, [r0], #1
20118: | | 3901 subs r1, #1
2011a: | | 711c strb r4, [r3, #4]
2011c: | | 9b01 ldr r3, [sp, #4]
2011e: | | 3301 adds r3, #1
20120: | | 9301 str r3, [sp, #4]
20122: | \-- e7f5 b.n 20110 <clone+0x10>
20124: \----> a801 add r0, sp, #4
20126: f50d 6d81 add.w sp, sp, #1032 ; 0x408
2012a: bdd0 pop {r4, r6, r7, pc}
```
note that it's not optimizing step (3) to an actual `memcpy` because we lack the 'trait specialization' code that libstd uses
---
before `clone` was optimized to
1. reserve and zero (`memclr`) 1028 (!?) bytes of stack space
2. (unnecessarily) runtime check if `len` is equal or less than 1024 (capacity) -- this included a panicking branch
3. memcpy `len` bytes of data from the parent
bors bot
added a commit
that referenced
this pull request
May 10, 2022
290: optimize the codegen of Vec::clone r=japaric a=japaric
these changes optimize `Vec<u8, 1024>::clone` down to these operations
1. reserve the stack space (1028 bytes on 32-bit ARM) and leave it uninitialized
2. zero the `len` field
3. memcpy `len` bytes of data from the parent
analyzed source code
``` rust
use heapless::Vec;
fn clone(vec: &Vec<u8, 1024>) {
let mut vec = vec.clone();
black_box(&mut vec);
}
fn black_box<T>(val: &mut T) {
unsafe { asm!("// {0}", in(reg) val) }
}
```
machine code with `lto = fat`, `codegen-units = 1` and `opt-level = 'z'` ('z' instead of 3 to avoid loop unrolling and keep the machine code readable)
``` armasm
00020100 <clone>:
20100: b5d0 push {r4, r6, r7, lr}
20102: af02 add r7, sp, #8
20104: f5ad 6d81 sub.w sp, sp, #1032 ; 0x408
20108: 2300 movs r3, #0
2010a: c802 ldmia r0!, {r1}
2010c: 9301 str r3, [sp, #4]
2010e: aa01 add r2, sp, #4
20110: /--/-X b141 cbz r1, 20124 <clone+0x24>
20112: | | 4413 add r3, r2
20114: | | f810 4b01 ldrb.w r4, [r0], #1
20118: | | 3901 subs r1, #1
2011a: | | 711c strb r4, [r3, #4]
2011c: | | 9b01 ldr r3, [sp, #4]
2011e: | | 3301 adds r3, #1
20120: | | 9301 str r3, [sp, #4]
20122: | \-- e7f5 b.n 20110 <clone+0x10>
20124: \----> a801 add r0, sp, #4
20126: f50d 6d81 add.w sp, sp, #1032 ; 0x408
2012a: bdd0 pop {r4, r6, r7, pc}
```
note that it's not optimizing step (3) to an actual `memcpy` because we lack the 'trait specialization' code that libstd uses
---
before `clone` was optimized to
1. reserve and zero (`memclr`) 1028 (!?) bytes of stack space
2. (unnecessarily) runtime check if `len` is equal or less than 1024 (capacity) -- this included a panicking branch
3. memcpy `len` bytes of data from the parent
Co-authored-by: Jorge Aparicio <jorge.aparicio@ferrous-systems.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
single producer single consumer support for ring buffer