Dr_Emann

Kinda: Early last year, I had done a little work with direct intrinsics first, then investigated std::simd, but ran into the issue of swizzle_dyn needing to re-compile std. It was actually when I ran across https://shnatsel.github.io/improving-std-simd-swizzle-dyn/ that got me back into it.

Have been really happy with Fearless simd, I used it to write [memchr-n][1], which searches for instances of an arbitrary set of bytes, with simd, which actually tends to [outperform][2] the rust memchr crate, even for sets of 1-3 bytes (what's supported by memchr)

[1]: https://github.com/Dr-Emann/memchr_n#performance [2]: https://github.com/BurntSushi/memchr/pull/241

It's a little unclear, but it's a live updating number, if you follow the directions, you'll see the second number decrease.

I don't think so, "while vacant" is an infinite amount of time, if you look infinitely far into the future.

"Participants got behind the wheel of a driving simulator equipped with everything you’d find in a real car – from the steering wheel to the pedals and dashboard. A large touchscreen, similar to those found in newer vehicles, allows for music to play and text messages to come through. Three oversized monitors provide 180 degrees of visual coverage to create a realistic, immersive driving environment."

Seems pretty clearly a simulator, they use that word several times.

To be even fair-er, it wasn't actually memory unsafety, it was "just" unsoundness, there was a type, that IF you gave it an io reader implementation that was weird, that implementation could see uninit data, or expose uninit data elsewhere, but the only readers actually used were well behaved readers.

Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)

Rust has access control. Fields are private by default.

Wow the comments are.. Bad. Not all single instruction operations are the same.

"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/

That doesn't sound like he's only talking about in his area to me

Hi, I think even the remaining benchmark isn't showing what you're trying to show:

https://rust.godbolt.org/z/r9rP6xohb

Rust realizes the vector is never used, and so never does any allocation, or recursion, it just turns into a loop to count up to 999_999_999.

And some back of the napkin math says there's no way either benchmark is actually allocating anything. Even if malloc took 1 nanosecond (it _doesn't_), 999_999_999 nanoseconds is 0.999999999 seconds.

It _is_ somewhat surprising that rust doesn't realize the loop can be completely optimized away, like it does without the unused Vec, but this benchmark still isn't showing what you're trying to show.

Rust optimizes factorial to be iterative, not using recursion (tail or otherwise) at all, and it turns `factorial(15, 1)` into `1307674368000`: https://rust.godbolt.org/z/bGrWfYKrP. As has been pointed out a few times, you're benchmarking `criterion::black_box` vs `benchmark.keep` (try the newer `std::hint::black_box`, which is built into the compiler and should have lower overhead)

And no: in the example with `&String` and `usize`, the stack isn't growing: https://rust.godbolt.org/z/6zW6WfGE7

Honestly feels like a very, very different use case from utf8-ish strings, at a quick read?

For simple cases, I'll do that, but for longer commands, I've taken to doing

rc=0 long command || rc = $? if (( rc == 0 ))...

Literally every file operation HAS to go through the kernel. This is implementing "what does it mean to read/write this special device file"

I believe they're asking for "this function returns a function of the same type (Fn/FnMut/FnOnce) as its first argument, but with different arguments. A generic way to write something like `fn bind<T, F: Fn(T,...) >(f: F, arg: T) -> Fn(...)`

Yes it does exactly that. It returns an iterator over the removed items, but when that iterator is dropped, it modifies the collection. See https://play.rust-lang.org/?version=stable&mode=debug&editio...

And for move to front, why not `a[..i+1].rotate_right(1);`, rather than moving to the back and then shifting everything?

Expand does actually exist in the standard library, but it's a bit of a strange incantation...

    vec.splice(i..i, std::iter::repeat(0).take(length));

This replaces the values in range `i..i` (an empty range starting at i) with `length` copies of `0`.

_Implementing_ a variadic function in rust requires nightly. I'm guessing that's what they meant. Calling one has been available for forever.

I would absolutely support something to replace ((((a).b).c).d).e with a->b->c->d->e, regardless of how much code had been written without that feature.

Do you not like the array subscript operator, either, since a[b] can be *(a+b)? How about a && b, you can replace that with (!!a) & (!!b), with an extra 'if' if you need the short circuiting.

Of course. There should never be more than one way to do something in c, even if it makes things easier or less error prone. This is why the -> operator would never be included in c. You can already use (*x).y, it would be SILLY to introduce a whole operator which isn't orthogonal to all existing features of the language.

Because there is no UB in the original program.

It constructs a pointer to the "one past the end" element, but that is fine, and the original program never dereferences that pointer. Again: there is no UB in the original program.

Your block of code can be (and absolutely is) optimized to output zero directly (in c, because the assembly is easier to read):

https://c.godbolt.org/z/qe3f4K

`*(&i+1)` dereferences the pointer "one past the end" which is UB.

Because echo-ing into a file will make a file with 1 byte in it: a single newline character.

The rules state you cannot die before the haunt.

Yes, if you use the escape hatch from the type system, the type system won't help you. Do you also avoid the use of strong types since you can always cast to a *char?