The MidVec was only faster than VecDeque when doing batch inserts and removals with my implementation.
https://gist.github.com/trueb2/9c0a23aa012f56d4c3d50afe8acf6...
227 karma · joined October 15, 2023
The MidVec was only faster than VecDeque when doing batch inserts and removals with my implementation.
https://gist.github.com/trueb2/9c0a23aa012f56d4c3d50afe8acf6...
I see plenty of examples like the one here that are on easier extractions. A PDF to HTML or Markdown converter will probably get it right with OCR.
There is something wrong with the IDE if an LLM has better response times.
Separately, Cursor Composer is awesome.
Same question for any language.
Also on cortex-m, you can put an executor on each cooperative priority but also you can put an executor on the main priority. That means you have one preemptive executor for blocking tasks and a couple cooperative choices.
I should add that I saw a huge reduction in RAM usage going to Embassy from Zephyr for a couple complicated applications. (on the order of 100KiB with all the stack and buffering reductions)
Only recently have I had some projects switching to stable after their required features stabilized.
Check out bioelectronics.northwestern.edu and rogersgroup.northwestern.edu
I have a lot of FFI code paths that end up easier to understand if you use the C-style instead of the Rusty approach.
Readability and comp time should be important even in FFI code paths
When I have work on a cooperatively scheduled executor for optimal timing characteristics. Sending work/creating a task on a preemptive executor is _expensive_. Furthermore, if that blocking work includes some device drivers with interactions with hardware peripherals, I can’t reasonable place that work on a new executor without invalidating hardware timing requirements.
Threads and executors can be infeasible or impossible to spawn. I have 1 preemptive priority and the rest are cooperative on bare metal. I can eat the suboptimal scheduling overhead with a blocking API/RTOS or I need the async version of things.
Separately, is Julia hitting a different LA backend? Rust's ndarray with a blas-src on Accelerate is pretty fast, but the Rust implementation is little slower on my macbook. This is a benchmark of a dot product.
```
const M10: usize = 10_000_000;
#[divan::bench]
fn ndarray_dot32(b: Bencher) {
b.with_inputs(|| (Array::from_vec(vec![0f32; M10]), Array::from_vec(vec![0f32; M10])))
.bench_values(|(a, b)| {
a.dot(&b)
});
}
#[divan::bench]
fn chunks_dot32(b: Bencher) {
b.with_inputs(|| (vec![0f32; M10], vec![0f32; M10]))
.bench_values(|(a, b)| {
a.chunks_exact(32)
.zip(b.chunks_exact(32))
.map(|(a, b)| a.iter().zip(b.iter()).map(|(a, b)| a * b).sum::<f32>())
.sum::<f32>()
});
}
#[divan::bench]
fn iter_dot32(b: Bencher) {
b.with_inputs(|| (vec![0f32; M100], vec![0f32; M100]))
.bench_values(|(a, b)| {
a.iter().zip(b.iter()).map(|(a, b)| a * b).sum::<f32>()
});
}
---- Rust ----
Timer precision: 41 ns (100 samples)
flops fast │ slow │ median │ mean
├─ chunks_dot32 3.903 ms│ 9.96 ms │ 4.366 ms│ 4.411 ms
├─ chunks_dot64 4.697 ms│ 16.29 ms│ 5.472 ms│ 5.516 ms
├─ iter_dot32 10.37 ms│ 11.36 ms│ 10.93 ms│ 10.86 ms
├─ iter_dot64 11.68 ms│ 13.07 ms│ 12.43 ms│ 12.4 ms
├─ ndarray_dot32 1.984 ms│ 2.91 ms │ 2.44 ms │ 2.381 ms
╰─ ndarray_dot64 4.021 ms│ 5.718 ms│ 5.141 ms│ 4.965 ms
---- Julia ----
native_dot32:
Median: 1.623 ms, Mean: 1.633 ms ± 341.705 μs
Range: 1.275 ms - 12.242 ms
native_dot64:
Median: 5.286 ms, Mean: 5.179 ms ± 230.997 μs
Range: 4.736 ms - 5.617 ms
simd_dot32:
Median: 1.818 ms, Mean: 1.830 ms ± 142.826 μs
Range: 1.558 ms - 2.169 ms
simd_dot64:
Median: 3.564 ms, Mean: 3.567 ms ± 586.002 μs
Range: 3.123 ms - 22.887 ms
iter_dot32:
Median: 9.566 ms, Mean: 9.549 ms ± 144.503 μs
Range: 9.302 ms - 10.941 ms
iter_dot64:
Median: 9.666 ms, Mean: 9.640 ms ± 84.481 μs
Range: 9.310 ms - 9.867 ms
All: 0 bytes, 0 allocs
```https://www.analog.com/media/en/technical-documentation/dsp-...